[Web-bot-auth] An Authenticated AI Browser Agent Can Still Execute the Wrong Act — Where Is the Handoff?

[Sangam Das <[e-mail]>]

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’s accountant
portal. The agent reaches an authenticated website, but before submission:

● the destination changes through a redirect;

● the DOM is modified;

● the selected attachment changes;

● a sharing option becomes “public”; or

● 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:

● reconstructs the actual final action;

● compares all consequence-relevant fields with current authorization;

● checks freshness, revocation and replay state; and

● atomically couples the decision to the state change.

I call that component a “Finality Sink,” but the terminology 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: “Which bot or operator is interacting with this
website?”
> Execution finality answers: “May this exact action by that authenticated
bot become effective now?”

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—or 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: “Execution-Finality Architecture for AI and Autonomous Critical
Systems”

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