Reading the spec, not a summary of it
What WebMCP's security model actually covers — and where it's still a TODO
Section 6 of the spec is titled 'Security and Privacy Considerations.' It opens by saying it can't define precise mitigation strategies. That's not a knock on the spec — it's the single most important sentence in it for anyone building on top of it today.
This is Site Passport's own reading of the current WebMCP draft and its source repository — a Draft Community Group Report under the W3C Web Machine Learning Community Group, not a finished standard. Nothing here should be taken as a substitute for reading Section 6 yourself; we link the exact sections below.
The four stakeholders the spec assumes
Before naming any specific risk, the spec frames responsibility across four roles: site authors (the people registering tools), agent providers (whoever ships the agent calling them), user agents (the browser mediating access), and end-users. That framing matters, because it means no single party is on the hook for "security" — it's distributed by design. Read generously, that's realistic. Read skeptically, it's also how a gap ends up nobody's job.
What the spec assumes an agent can already do
The baseline is worth sitting with: the spec assumes agents act with identity inheritance (the user's own credentials and session), extended user context (personalization, history, sometimes payment data), and cross-site context (the ability to correlate what it learns across different websites). WebMCP isn't creating that access — a logged-in browser agent already has it. What WebMCP changes is how precisely an agent can act on it, which is exactly why the spec treats the risk surface as worth a dedicated section instead of an afterthought.
Five risk categories the spec names outright
1. Tool poisoning — malicious metadata
An agent reads a tool's name, description, and parameter descriptions as part of its own context. The spec's own warning: malicious instructions embedded in that metadata "can override the agent's original instructions." A tool doesn't need a bug to be dangerous — its description is attack surface, full stop.
2. Output injection
A tool's return value can carry the same kind of instruction-injection risk as its description — and the spec is explicit that this includes "untrusted user-generated content on social media platforms, forums, review sites." Any WordPress site with comments, reviews, or forum plugins is squarely in scope here, not a hypothetical.
3. Misrepresentation of intent
The spec's term for when an agent's action diverges from what the user actually meant — through "ambiguous finalization," accidental or malicious. This is the category that maps most directly onto "did a human actually agree to this," and it's the one a generic checkout or form-submit flow handles worst by default.
4. Privacy leakage through over-parameterization
A tool with broad, free-form parameters can let an agent extract far more granular data than a human clicking through the same UI ever would — a search or filter tool is the obvious shape this takes.
5. Same-origin boundary violations
The spec's own permission model (default same-origin, exposedTo / fromOrigins for anything cross-origin) exists specifically because a tool bypassing origin isolation is a named risk, not a theoretical one.
What it actually proposes as mitigations
Four, and they're worth naming precisely because none of them is a requirement — they're documented as non-normative recommendations:
- Restricting maximum input lengths — a blunt but real defense against certain injection patterns.
- Shared attack-evaluation datasets — the spec's phrase is "interoperable probabilistic defense structures" — essentially, an ecosystem-wide effort to test against known attacks, rather than every implementer inventing their own.
- Untrusted Annotation for tool responses — a way to mark a tool's output as not to be treated as trusted instruction, directly aimed at the output-injection risk above.
- Consequential Annotation for tool executions — flagging that a given tool call is high-risk or state-changing, which is the closest thing in the spec itself to "this needs a human to confirm."
What's still explicitly undefined
This is the part worth taking seriously rather than glossing over:
- The spec states outright it "cannot define precise mitigation strategies" — it documents responsibilities and recommendations, not requirements.
- Security considerations for the declarative API (the plain HTML-attribute path most WordPress sites would actually use) are marked as a literal "TODO" in the current draft.
- Several open issues (including #146 and #227 in the spec repo) track unresolved security questions directly — this isn't a settled design, it's an active one.
- Nothing in the spec says what an agent must do defensively. The word is "recommends," not "requires."
Our read
None of this is a defect in the spec — a Community Group draft that's honest about what it hasn't solved yet is doing exactly what a draft should do. But it does mean something concrete for anyone building on WebMCP today: the spec gives you the plumbing — permissions, origin isolation, annotation hooks — and names the risks precisely. It does not give you the policy. Deciding which tools are consequential, who approves them, and how a site refuses to trust its own comment section's content — that's implementation work the spec deliberately leaves to the site. Which is exactly why Safety & Trust is one of the two categories in our own scoring methodology that can't be faked or inferred from the outside: it has to actually exist on the site.
Primary sources
- webmachinelearning.github.io/webmcp/#security-privacy — Section 6, Security and Privacy Considerations, in full
- github.com/webmachinelearning/webmcp — spec source, open issues, changelog
- developer.chrome.com/docs/ai/webmcp/secure-tools — Chrome's own "Creating Security-Minded Tools" guidance
See also: What is WebMCP? for the spec's status and governance, and our companion piece on what this means concretely for a WordPress site.
See how your own site handles this today
The free scan checks Discoverability, Bot Access, and Content right now. Safety & Trust is the category this article is actually about — see the full methodology.
Scan your site