MIME-Version: 1.0
From: Sangam Das <info@sangamdas.com>
Date: Mon, 21 Sep 2026 21:28:37 +0530
Message-ID: 
 <CAHCJH6GRiDqptH8v-w7tgjLG2UHVbeKz8eJBeMfbdds7Qr5=0Q@mail.gmail.com>
To: web-bot-auth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000081da21065c005367"
Message-ID-Hash: 5YESHVMXHEXOQDG4HV4INESEE4MMIKUU
Precedence: list
Subject: [Web-bot-auth] =?utf-8?q?An_Authenticated_AI_Browser_Agent_Can_Still_Execute?=
	=?utf-8?q?_the_Wrong_Act_=E2=80=94_Where_Is_the_Handoff=3F?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/web-bot-auth/Plgv-Ef4X1FawP6P7-4amuwbMag>

--00000000000081da21065c005367
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear WebBotAuth Working Group,

Consider a browser-using AI agent that is successfully authenticated
through WebBotAuth.

A user instructs it to upload tax-return.pdf to the user=E2=80=99s accounta=
nt
portal. The agent reaches an authenticated website, but before submission:

=E2=97=8F the destination changes through a redirect;

=E2=97=8F the DOM is modified;

=E2=97=8F the selected attachment changes;

=E2=97=8F a sharing option becomes =E2=80=9Cpublic=E2=80=9D; or

=E2=97=8F a downstream worker delivers the file to a different account.

WebBotAuth may still be working exactly as designed: the website knows
which bot or operator made the request. But the authenticated bot has
produced the wrong externally effective act.

The same issue applies when an AI agent purchases an item, publishes
content, changes an account setting, sends a message, or releases data
through a human-facing website.

This leads to three concrete questions:

1. What exactly is cryptographically authenticated?
Is WebBotAuth intended to authenticate only the bot/operator, or can its
proof also bind the HTTP method, target and selected request content?

2. Where does the authenticated identity hand off to final action
enforcement?
How should a website preserve the bot/operator identity and request binding
through redirects, browser state, form transformation, queues and
downstream services until the purchase, upload, publication or SEND
actually becomes effective?

3. How should implementations distinguish an authenticated request from an
authorized final consequence?
Should WebBotAuth operational guidance state explicitly that authenticating
an AI agent does not prove that the final semantic action matches what the
user or origin authorized?

The architecture I am examining keeps the proposed action non-effective
until the website component controlling the consequence:

=E2=97=8F reconstructs the actual final action;

=E2=97=8F compares all consequence-relevant fields with current authorizati=
on;

=E2=97=8F checks freshness, revocation and replay state; and

=E2=97=8F atomically couples the decision to the state change.

I call that component a =E2=80=9CFinality Sink,=E2=80=9D but the terminolog=
y is secondary.
If an existing website component already performs these functions at a
non-bypassable boundary, it is functionally equivalent.

The key distinction is:

> WebBotAuth answers: =E2=80=9CWhich bot or operator is interacting with th=
is
website?=E2=80=9D
> Execution finality answers: =E2=80=9CMay this exact action by that authen=
ticated
bot become effective now?=E2=80=9D

I am not proposing that WebBotAuth become a general transaction or
authorization protocol. I am asking whether the WG should define the secure
handoff from authenticated bot identity to application-specific
final-action enforcement=E2=80=94or at least identify that boundary clearly=
 so
implementers do not treat bot authentication as proof of action validity.

The architectural analysis is here:

https://datatracker.ietf.org/doc/draft-das-execution-finality-deployment/

Title: =E2=80=9CExecution-Finality Architecture for AI and Autonomous Criti=
cal
Systems=E2=80=9D

I would particularly value feedback from engineers implementing browser
agents, computer-use systems, HTTP message signatures, and agent identity
infrastructure.

Regards,

Sangam Kumar Das
Independent Researcher

--00000000000081da21065c005367
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-size:inherit">
<div style=3D"font-size:inherit">
<p>Dear WebBotAuth Working Group,</p>
<p>Consider a browser-using AI agent that is successfully authenticated thr=
ough WebBotAuth.</p>
<p>A user instructs it to upload tax-return.pdf to the user=E2=80=99s accou=
ntant portal. The agent reaches an authenticated website, but before submis=
sion:</p>
<p>	=E2=97=8F	the destination changes through a redirect;</p>
<p>	=E2=97=8F	the DOM is modified;</p>
<p>	=E2=97=8F	the selected attachment changes;</p>
<p>	=E2=97=8F	a sharing option becomes =E2=80=9Cpublic=E2=80=9D; or</p>
<p>	=E2=97=8F	a downstream worker delivers the file to a different account.=
</p>
<p>WebBotAuth may still be working exactly as designed: the website knows w=
hich bot or operator made the request. But the authenticated bot has produc=
ed the wrong externally effective act.</p>
<p>The same issue applies when an AI agent purchases an item, publishes con=
tent, changes an account setting, sends a message, or releases data through=
 a human-facing website.</p>
<p>This leads to three concrete questions:</p>
<p>	1.	What exactly is cryptographically authenticated?<br>
Is WebBotAuth intended to authenticate only the bot/operator, or can its pr=
oof also bind the HTTP method, target and selected request content?</p>
<p>	2.	Where does the authenticated identity hand off to final action enfor=
cement?<br>
How should a website preserve the bot/operator identity and request binding=
 through redirects, browser state, form transformation, queues and downstre=
am services until the purchase, upload, publication or SEND actually become=
s effective?</p>
<p>	3.	How should implementations distinguish an authenticated request from=
 an authorized final consequence?<br>
Should WebBotAuth operational guidance state explicitly that authenticating=
 an AI agent does not prove that the final semantic action matches what the=
 user or origin authorized?</p>
<p>The architecture I am examining keeps the proposed action non-effective =
until the website component controlling the consequence:</p>
<p>	=E2=97=8F	reconstructs the actual final action;</p>
<p>	=E2=97=8F	compares all consequence-relevant fields with current authori=
zation;</p>
<p>	=E2=97=8F	checks freshness, revocation and replay state; and</p>
<p>	=E2=97=8F	atomically couples the decision to the state change.</p>
<p>I call that component a =E2=80=9CFinality Sink,=E2=80=9D but the termino=
logy is secondary. If an existing website component already performs these =
functions at a non-bypassable boundary, it is functionally equivalent.</p>
<p>The key distinction is:</p>
<p>&gt; WebBotAuth answers: =E2=80=9CWhich bot or operator is interacting w=
ith this website?=E2=80=9D=C2=A0 <br>
&gt; Execution finality answers: =E2=80=9CMay this exact action by that aut=
henticated bot become effective now?=E2=80=9D</p>
<p>I am not proposing that WebBotAuth become a general transaction or autho=
rization protocol. I am asking whether the WG should define the secure hand=
off from authenticated bot identity to application-specific final-action en=
forcement=E2=80=94or at least identify that boundary clearly so implementer=
s do not treat bot authentication as proof of action validity.</p>
<p>The architectural analysis is here:</p>
<p><a href=3D"https://datatracker.ietf.org/doc/draft-das-execution-finality=
-deployment/">https://datatracker.ietf.org/doc/draft-das-execution-finality=
-deployment/</a></p>
<p>Title: =E2=80=9CExecution-Finality Architecture for AI and Autonomous Cr=
itical Systems=E2=80=9D</p>
<p>I would particularly value feedback from engineers implementing browser =
agents, computer-use systems, HTTP message signatures, and agent identity i=
nfrastructure.</p>
<p>Regards,</p>
<p>Sangam Kumar Das<br>
Independent Researcher</p>
</div>
</div>

--00000000000081da21065c005367--