Spec & generalize agentInvoked: signal events an agent originates #365

When an agent accepts terms or dismisses a disclosure on the user's behalf, the user is bound to something they never saw — steps that were there to protect them. When it presses Confirm, Submit or Pay, the user is committed to an action and its consequences, monetary and often irreversible — a decision that was theirs to make. The page cannot tell who took either.

An agent acting for a user should disclose that it is acting, at the point of action. If it operates the page's UI, the events it produces say so. If it calls the page's tools, the tool can hand the step back to the person (#165) — and the person's step is then an ordinary, attributed event. One rule, two surfaces; they meet at the human's click. This issue is the first surface.

Chromium exposes SubmitEvent.agentInvoked and a WPT asserts it, but it is defined only in the declarative explainer, not in the spec, and only for agent-submitted forms. Imperative tools have no equivalent (#96). Agent form-fills dispatch no input or change at all (#104), so a consent checkbox an agent ticks runs none of the page's logic and leaves no trace. #288 shows the consequence end to end: a UA that invokes tools and also drives the page pressed the page's own Approve, and the receipt said "approved by you."

Ask: when the user agent produces input on an agent's behalf — for its built-in agent, for a caller of executeTool, or when filling a form for an agent — it should dispatch the same events the user's own input would, and mark each one as agent-originated:

partial interface Event {
  readonly attribute boolean agentInvoked;
};

Simplest placement is Event; UIEvent/InputEvent/SubmitEvent if we prefere narrower. The line is agent- vs user-originated, not synthesized vs physical: switch, voice and screen-reader input are the user's and are never marked. isTrusted is not this bit.

What it enables: a page accepts agent input everywhere by default and, on the few steps that must be the person's, declines it: the handler sees agentInvoked, cancels the event, and asks the person to take the step. That decline is the intended behaviour, and it is feedback. The UA dispatched the event, so it can see the page cancelled it and surface that to the agent as the cue to hand the step back — the DOM-path equivalent of a tool calling requestUserInput (#165). The person acts; the event arrives with agentInvoked false; the flow continues. The same bit lets the page record whether a step was the user's or the agent's, which is what makes a receipt that says "approved by you" true. Later, a separate signal can carry authorization — the UA attesting that the user confirmed this specific action in the agent's own UI — so a page can accept agent-originated-but-user-authorized input on medium-risk steps and reserve a direct human action for the highest. Origination is the bit to land first because it is deterministic and true today; authorization needs the UA to mediate a confirmation and should never be inferred from the origination bit.

This does not identify the agent, block it, or change activation. Without it, a page that must keep a step human has only guesswork — bot detection, isTrusted checks, hold-to-confirm gestures, CAPTCHAs. That taxes the site operator, misfires for real users, and turns well-behaved agents into suspects. Everyone loses. A one-bit disclosure lets the page keep three steps human and hand the agent the rest — the only posture under which a site/business can reliably expose consequential tools.

When the agent calls the page's tools instead of operating its UI, there is no event to mark — the tool is the page's own code running at the agent's request, and the step that must be the person's happens somewhere the tool cannot see. The counterpart is the tool handing the step back: a person must take this step; here is where. The UA brings the person to the document, or hands them the tool's URL if they are not at this browser, or reports that no person is reachable; the step the person then takes on the page is an ordinary event, agentInvoked false. That primitive is #165/#204, open since June on a scope question; a ladder shape that lets interactive ship now with url and form additive is in #165. Neither surface is complete without the other: without #165 a tool that needs the person has no way to get them; without this issue, the step the person was brought to can be taken by the agent.

This is probably better treated as new scope/deliverable for the proposed Agentic Web WG than WebMCP spec (cc @plehegar): it is about how an agent acts on any page, not about how tools are registered. Filing here because this is where the discussion already lives — #96, #104 and #288 are all in this repo — and raised on w3c/strategy#576 for the charter. If we agree on the direction, happy to help draft the text and tests.