Repository navigation
Proposal: [Section 3] Address agent-to-tool trust — identity, scoped permissions, and delegation context #96
Description
The security-privacy companion doc covers prompt injection, misrepresentation, and over-parameterization — the right threats for the tool-to-agent direction. But it doesn't address the trust model in the other direction: when an agent invokes a tool, the tool has no way to know which agent is calling or what scope of access the user granted.
Traditional web auth assumes two parties: the user and the service. WebMCP introduces a third — the agent — which acts on behalf of the user but is neither the user nor the service. The community wiki identifies agent identity, permission scoping, and audit distinguishability as known gaps. This issue proposes specific requirements for the normative security section, building on the discussions in #54, #44, and #87.
1. Agent identity shouldn't be deferred
#54 raised this at TPAC 2025, and the group resolved to defer: "no clear need to address this in WebMCP atm" since the first iteration is limited to browser agents. I think that resolution deserves revisiting for two reasons.
First, even with only browser agents, tools can't make trust decisions per-caller. A banking site exposing a getBalance tool has no mechanism to reject a call based on caller identity. SubmitEvent.agentInvoked tells you an agent acted, but not which.
Second, deferring identity blocks #44. @khushalsagar identifies agent identity as a prerequisite for persisted consent state in #44: "we need to give authors a unique identifier to namespace state associated with each Agent." The permission model #44 is exploring can't be fully resolved without identity primitives in place. @khushalsagar also outlined two classes of identity — opaque identifier vs origin-associated agent ID — in #54. The spec doesn't need to ship both in v1, but it needs to ship at least one.
Proposed requirement: ModelContextClient should carry browser-attested agent identity, enabling both the consent persistence #44 needs and per-caller trust decisions by tools.
2. Permissions are binary, not scoped
#44 is actively exploring how to manage action-specific permissions, including whether the browser or site should own consent state, how to handle ephemeral tools, and the plumbing-vs-controls distinction @jandrieu raised. This issue overlaps with that discussion but focuses on a specific gap in the current spec surface.
A tool that reads account data and a tool that initiates a wire transfer have very different risk profiles. There's no mechanism for tools to declare required access levels, for the browser to mediate granular scopes, or for agents to request only the permissions they need.
destructiveHint is explicitly advisory — the spec states the browser or agent can ignore it. For tools handling sensitive operations, an advisory hint isn't sufficient. This is the same gap that led to granular camera/microphone permissions replacing binary allow/deny.
Proposed requirement: tools should declare required access levels. The browser should mediate scoped permissions with deny-by-default semantics.
3. Delegation context doesn't flow to imperative tools
SubmitEvent.agentInvoked provides agent-vs-user distinction for the declarative form path. But for imperative tools registered via navigator.modelContext.registerTool(), the execute() callback's ModelContextClient parameter exposes only requestUserInteraction() — no agent identity, no scope information, and no invocation identifier for audit correlation.
#87 proposes session and authentication context for tools, addressing how tools access credentials and manage token refresh. The gap here is adjacent but distinct: even with session auth solved, imperative tools handling sensitive data can't enforce access control policies or meet compliance requirements for audit trails without knowing who called and what they were authorized to do.
Proposed requirement: ModelContextClient should provide delegation context — at minimum, agent identity, granted scopes, and a correlation ID.
Why the browser layer
The browser mediates the connection between agent and tool. That's an advantage server-side MCP doesn't have — identity, permissions, and consent can be enforced at the platform level instead of being left to each tool author.
Activity
Starborn commentedon Feb 20, 2026
- agent-to-tool trust, identity, scoped permissions, and delegation context
From a knowledge representation and AI agent interoperability angle, two further gaps emerge that sit just underneath these."
Gap 1: The permissions vocabulary problem
Section 2 proposes that tools should declare required access levels, which is exactly right. But it implicitly assumes a shared vocabulary for what those access levels mean. Who defines that vocabulary, and how do tools from different publishers declare equivalent access levels in interoperable ways?
This is not just a security problem -- it is a knowledge representation problem. A getBalance tool and a fetchAccountSummary tool may have identical risk profiles but no formal mechanism to declare this equivalence. Without a shared semantic layer, scoped permissions will fragment by publisher rather than converge on meaningful categories that agents can reason about consistently.
The W3C AI Knowledge Representation Community Group (which I chair) has this coordination squarely in scope. It may be worth an early liaison to avoid baking in assumptions that become hard to change once implementations proliferate.
Gap 2: Capability semantics vs. capability identity
Section 3 correctly identifies the need for delegation context including a correlation ID for audit. But an audit trail that records who called without recording what the agent believed the tool would do is forensically incomplete.
There is a meaningful difference between an agent having permission to invoke a tool and an agent having an accurate model of the tool's behavior, preconditions, and side effects. The latter is what makes audit actionable and what allows meaningful consent -- a user granting permission to "read my email" needs the agent's understanding of that operation to match what the tool actually does.
This points toward tool capability representation as a first-class concern, not just metadata. The invocable contract needs to include declared behavior, not just declared identity. This connects to ongoing work on model and tool cards in adjacent communities and is worth explicit treatment in the security section.
Happy to discuss either thread further or to bring relevant W3C AI KR CG perspectives to bear on vocabulary coordination.
fix(typescript): correct webmcp docstring/README origin-safety claim,…
mysticalseeker24 commentedon Sep 12, 2026
Implementation evidence for §3, and two premises in it that have moved since February.
The surface is narrower than the issue describes
§3 says the
execute()callback'sModelContextClientparameter "exposes onlyrequestUserInteraction()". Neither of those is in the draft any more. What is there:dictionary ToolExecuteCallbackOptions { required AbortSignal signal; }; callback ToolExecuteCallback = Promise<any> (object inputObject, ToolExecuteCallbackOptions options);One required member.
ModelContextClientandrequestUserInteractioneach appear zero times inindex.bstoday. Measured against implementations:executearguments["signal"]ModelContextmembersexecuteTool,getTools,ontoolchange,registerToolSo the gap §3 identifies is real and slightly wider than stated: an imperative tool receives a cancellation signal and nothing else. 153 matches the draft exactly.
The two paths in the same browser do not agree
This is the part that seems most useful to the proposal, because it is an inconsistency rather than an absence.
On Chromium 153,
SubmitEvent.prototypecarriesagentInvoked:A declarative form handler can therefore distinguish an agent-submitted form from a person-submitted one. An imperative tool, in the same build, cannot distinguish anything — the only thing it is handed is an
AbortSignal.Two authors implementing the same capability, one declaratively and one imperatively, get different security and audit primitives from the same browser. Whatever the eventual answer on identity, that asymmetry seems worth resolving on its own terms, and it is narrower than the full identity question:
agentInvokedis a boolean, not an identifier, and the imperative path not having its equivalent does not appear to be a deliberate decision anywhere in the draft.What a page does without it, and why it does not hold
We built a booking site where the human command surface is a caller of the same registry as the agent — the palette discovers with
getTools()and executes throughexecuteTool()rather than keeping a parallel command list. Both callers therefore arrive at the same closure, indistinguishably.To keep an audit trail and to announce agent actions to screen-reader users, we mark the call the page is about to make immediately before making it and treat anything unmarked as agent-originated. It is a heuristic and it fails under concurrency: our first version used a single global mark, and a concurrent call consumed it, so a human action was recorded and announced as the agent's. Keying the mark by tool name narrowed the window without closing it. @mlmrx confirmed on #277 that caller attribution cannot be made reliable from today's
executeTool()surface.The consequence is not only a compliance one. Our page announces "Agent selected Dr. Okafor, Neurology" in a live region, because a screen-reader user is otherwise told nothing when an agent acts — the DOM simply mutates. That announcement is the one surface where a blind user learns an agent did something, and its actor is inferred rather than known. We have documented it as inferred rather than remove it, but "the page guessed" is a poor foundation for the only signal a user has.
On the correlation ID, and @Starborn's Gap 2
Agreed that who-called without what-was-intended is forensically incomplete, with one refinement from having built the audit trail: a page can already record a good deal of the second half. Ours stores, per execution, the tool name, the exact input arguments, the returned result envelope, and the actor. What it cannot do is join that to anything outside the page. Every id in it is page-generated, so a site's audit log and an agent's transcript cannot be reconciled even when both parties retained their half.
That makes the correlation ID the cheapest of the three asks in §3 and, for audit purposes, possibly the most load-bearing: identity tells you who, arguments tell you what, and neither is worth much if the two records cannot be lined up afterwards.
Implementation: https://github.com/mysticalseeker24/parity-webmcp
domfarolino commentedon Sep 25, 2026
Thanks for filing this. WebMCP provides a mechanism for web applications to expose tools to agents; I don't think that necessarily means WebMCP should define an agent identity, agent-specific authorization model, or general delegation/auditing infrastructure. Those are broader web-platform questions that would apply to agents regardless of whether they're interacting with a site through WebMCP.
I think the underlying questions around agent identity, permissions, and state are interesting, but we've increasingly been trying to separate those broader "agents on the web" questions from the scope of the WebMCP API itself. Then, of course, we can figure out how the broader "agents on the web" problems relate to WebMCP.
I've written up some of that distinction in #257 (comment). The individual concerns raised here are also already represented in more focused discussions such as #44, #54, #87, and #257.
Given that, I'm inclined to close this issue rather than keep a combined WebMCP-specific proposal for these concepts open.