Repository navigation
Threat(?): no visibility into the criteria for invoking explicit user confirmation #356
Description
It is my understanding that the criteria for invoking user consent/confirmation before finalising a consequential operation are set separately by the page and by the agent implementer. They might not match, and they are not disclosed to the user. The user's lack of visibility into what exactly triggers their consent to be requested represents a possible threat, since the user may delegate a sensitive consequential operation expecting confirmation that neither the page’s criteria nor the agent's criteria ever trigger.
Activity
kenchris commentedon Oct 20, 2026
I think this is a real gap, and there is one more place the criteria come from. A confirmation can be triggered by what the page declares (
consequentialHint), by what the agent implementer decided, and by the host's own policy. In the engine we use, a call that follows untrusted content is held for a decision even if the tool says nothing about being consequential, so for us the page's hint is one input and not the rule. The user can't see any of those from the page's side, as you say.It's also likely to get less visible. Claude Code now starts in an auto mode by default, where a classifier model reviews the actions instead of asking the user, because people accept 93% of the prompts anyway (their number) and stop reading them. Other agents may well do the same. Then there is often no confirmation to see at all, only a decision. That classifier sees only the user's messages and the agent's tool calls, and not the tool results, so that hostile page content can't steer it. I don't know if it is also given a tool's description and annotations, but if it is, then for a page tool those are written by the page (#353).
I don't think the spec can or should define the host's criteria, because that is host UX and will differ. But a few things seem within reach. The spec could say that the absence of a hint isn't a statement that confirmation is unnecessary (#353 and #355), and be careful with the wording in 6.4.5, which says clients can use
consequentialHintto enforce confirmation prompts, since a user may read that as a guarantee. And it could recommend that a host tells the user what its rule is, for example in its settings, and why it asked when it does. A user who knows "this agent asks before anything that isn't read-only" can delegate with the right expectations.A page that needs a confirmation to happen regardless of the host can ask for it in the tool itself, with the user input work in #165, which is modelled on MCP's elicitation and so maps onto an approval (accept, decline or cancel). That only helps if it is the user who answers. A host that approves automatically should not answer on the user's behalf, and the page should be able to tell a real decline from "nobody was asked" (see my comment in #165).