WebMCP Security: Why Your Agent Strategy Needs a Threat Model
The Reality of Agentic Exposure
For the last few years, the SEO conversation has been dominated by how to make content 'legible' to AI. We focused on structured data, XML sitemaps, and rendering. But we are shifting from passive consumption to active participation. By implementing WebMCP, you aren't just letting an agent read your site; you are giving it a set of keys to execute functions.
This is the AI decision layer in action. However, when you provide these tools, you create an attack surface. If you treat this as a simple 'plug-and-play' feature for your site, you are ignoring the reality of prompt injection. The practical route is simple: stop viewing WebMCP as a marketing feature and start viewing it as a public API endpoint.
The Two Vectors of Hijacking
Chrome’s security guidance highlights two ways your site can be turned against itself. Understanding these is non-negotiable if you are managing capability-based tools like WebMCP.
| Attack Vector | Source of Risk | Why it happens |
|---|---|---|
| Malicious Manifest | Tool definitions | Hidden instructions in names or descriptions. |
| Contaminated Output | User-generated content | LLMs cannot distinguish between data and commands. |
The second vector is the most dangerous because it is invisible. If your tool pulls product reviews or forum comments, you are effectively feeding an LLM raw, unvalidated user input. If a user hides a command in a review, your tool will dutifully hand that command to the agent as if it were your own instruction. This is not a bug; it is how LLMs function.
How to Audit Your Site Now
Before you register a single tool, you need to conduct a technical audit of your proposed implementation. Do not export everything and call it an audit; focus on the specific data streams your tools interact with.
Review your current WebMCP audits to ensure you are applying the following security annotations:
- untrustedContentHint: Use this for any tool that returns user-generated content (UGC). It tells the agent that the data requires extra scrutiny.
- readOnlyHint: If the tool doesn't change state (e.g., a search function or a review fetcher), mark it as read-only. This forces the agent to ask for user confirmation before executing potentially state-changing actions.
- exposedTo: Explicitly whitelist the origins that can access your tools. Never default to 'all'.
This is a small task with high leverage. These annotations are the difference between a secure implementation and an open door for attackers.
The Capability Bet: Moving Beyond the Brochure
Many teams are rushing to adopt WebMCP to look 'agent-ready.' But being legible to an agent and being safe for an agent are two different things. If you are a developer or an SEO lead, your job is to bridge the gap between marketing enthusiasm and technical risk.
Prioritise by crawl impact, indexation impact, and commercial value. If a tool doesn't provide significant value to the user, do not expose it. If it does, threat-model it. Ask yourself: 'What is the worst-case scenario if this tool returns malicious content?' If you cannot answer that, the tool is not ready for production.