Proposal: [Section 3] Address agent-to-tool trust — identity, scoped permissions, and delegation context

[davidcrowe]

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.

[Starborn]

- 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.