Add WebMCP to your website, and you hand visiting AI agents a set of named tools to call. Those same tools can be used to turn the agents against the people who sent them. Chrome’s developer site now carries the security guidance for WebMCP, and much of it is written for the websites exposing the tools rather than the companies building the agents. Make your website agent-ready with WebMCP, and you have also opened an attack surface, and closing it is your job, not the agent’s.
For two years, the agent-readiness conversation has been about access: Can an agent reach your content, read your page, finish your checkout? WebMCP is the version where you stop hoping an agent figures your website out from the markup and start handing it named tools to call. That is the more useful protocol, and it is the direction the agentic web’s protocol layer is moving. It is also where being legible to an agent and being safe for an agent stop being the same property.
Chrome Identifies Two Attack Vectors for WebMCP-Exposed Tools
Chrome’s agent-security guidance describes two attack vectors, and both arrive through the tools a website exposes. The first is the malicious manifest. In Chrome’s words, “Websites may have tool definitions with hidden instructions, in tool names, parameters, or descriptions, designed to hijack the agent.” A tool’s description is text the agent reads to decide how to use the tool, so a description can carry an instruction the agent was never meant to follow.
The second vector is the one most websites will actually encounter, and it requires no malicious website at all. Chrome calls it a contaminated output: “Real-time tool responses from otherwise trustworthy sites might include malicious instructions as part of third-party data, such as user comments.” A tool on your own website that returns your product reviews, your comment threads, your forum posts, or your support replies is returning text other people wrote. If one of those people planted an instruction inside a review, your legitimate tool has handed it to the agent as if it came from you. The payload is your own user-generated content, and you invited it in.
Why Large Language Models Cannot Distinguish Data from Commands
This works because of something that is not a bug and will not be patched. “LLMs treat all text, instructions and user data, as a single sequence of tokens,” the guidance states, so the model cannot reliably separate the part you meant as data from the part an attacker meant as a command. That is why Chrome says “the probabilistic nature of LLMs makes it impossible to guarantee safety inside the model itself.” This is the same prompt-injection problem that has no clean fix inside the model, now wearing a protocol. WebMCP gives that attack a clean, structured delivery route through the tools you published on purpose.
What Are the Security Risks of WebMCP for Websites?
WebMCP creates a direct channel between an AI agent and the structured tools a website exposes. When a website registers a tool, it publishes a machine-readable definition that the agent parses to understand what the tool does and how to call it. That definition includes names, parameters, and descriptions written in natural language — the same natural language that an LLM treats as a token sequence indistinguishable from instructions. An attacker who embeds a hidden command in any of those fields can redirect the agent’s behavior without breaking the tool’s apparent functionality.
The contaminated output vector is even more insidious because it requires no compromise of the website itself. Any site that serves user-generated content — reviews, comments, forum threads, support tickets — and exposes that content through a WebMCP tool has created a pipeline for injected instructions. The agent cannot tell the difference between the product review it was asked to retrieve and the command hidden inside it. The tool is legitimate, the data is real, and the attack is invisible to the site owner.
Making a Website Agent-Ready Now Includes Making It Agent-Safe
Chrome’s guidance puts the obligation on the website, not only on the agent. Chrome’s tool-security document opens with a line aimed directly at whoever exposes the tools: “Only expose your tools to origins that you trust. This is particularly important when tools manage user data or otherwise impact the user.” That line is written for whoever ships the tool. That means you.
The defenses are concrete, and they are annotations you attach to the tools you ship. untrustedContentHint “explicitly labels the payload as untrusted, to help protect your site’s integrity while providing a signal to the agent that this data requires heightened scrutiny.” Chrome says when to use it: “If a tool returns user-generated content (UGC) or externally sourced data, consider adding the untrustedContentHint to the tool.” readOnlyHint marks a tool that does not change state, which “allows the agent to make better decisions about when to ask for user confirmations.” exposedTo restricts a tool to an array of origins you trust, written into the registration itself:
- untrustedContentHint — Labels the tool’s output as untrusted, signaling to the agent that the data requires heightened scrutiny.
- readOnlyHint — Marks a tool as non-state-changing, helping the agent decide when user confirmation is needed.
- exposedTo — Restricts the tool to an explicit array of trusted origins, embedded in the registration code.
Chrome also caps character budgets: a tool description at 500 characters and a single tool output at roughly 1,500, and adds a requestUserInteraction() path for confirming an action before it fires.
Securing a Shopping Agent Tool: A Concrete Example
Take an obvious example: a tool that surfaces product reviews to a shopping agent. Securing it is not exotic work. Mark its output with untrustedContentHint, set readOnlyHint because it reads rather than buys, and limit exposedTo to the origins you actually serve. None of that is the agent’s job. It is the tool author’s job, which on most teams is the web, CRO, or marketing people adding WebMCP to look current — not the security people who read threat models. That gap is where this goes wrong. Marking which of your content is data and not commands is now part of shipping a tool, the way sanitizing input became part of shipping a form.
How Can Websites Secure Their WebMCP Tools Against Hijacking?
The answer is not complex, but it requires a shift in mindset. For every tool you register, you must answer one question before it ships: What untrusted content can this return, and have you marked it? If you cannot answer that question, the tool is not ready, however agent-ready the rest of your website looks.
Chrome provides four concrete mechanisms for securing tools:
- Use untrustedContentHint on any tool that returns user-generated content or externally sourced data.
- Apply readOnlyHint to tools that do not modify state, giving agents better context for user confirmation decisions.
- Restrict exposedTo to a specific array of origins you trust, preventing unauthorized agents from calling the tool.
- Implement requestUserInteraction() for actions that should require explicit user approval before execution.
These are not optional decorations. They are the minimum viable security posture for any website that exposes tools through WebMCP. The protocol is still early, sitting in a Chrome origin trial with a moving specification, and most websites have not exposed a single tool. That is the window to decide that agent-safe is part of agent-ready, before the first tool you ship turns out to be the one that hands an agent your reviews and whatever someone hid inside them.
The Burden of Security Falls on the Website, Not the Agent
This is the central structural fact of WebMCP security: the website that exposes the tool owns the risk. Agents cannot be expected to sanitize every input they receive because the architecture of large language models makes reliable separation of data and instructions impossible inside the model. The website must pre-filter. The website must annotate. The website must restrict access. The protocol is designed to give websites the mechanisms to do all of this, but only if they use them.
The parallel to early web security is unavoidable. In the late 1990s, websites began accepting user input through forms, and it took years for the industry to learn that every piece of user-supplied data had to be sanitized before it could be rendered or stored. SQL injection, cross-site scripting, and command injection all arose from the same fundamental failure: treating user input as trusted content. WebMCP tools that return user-generated content without marking it as untrusted are repeating that mistake at a higher level of abstraction, and the stakes are higher because the agent can act on the injected instruction before anyone notices.
WebMCP Is Worth Adopting, But Only With Proper Threat Modeling
Handing an agent explicit, callable tools beats making it guess your website from the DOM, and the capability is worth having. None of this is a reason to avoid WebMCP. The point is narrower and more pragmatic: the capability arrives with a bill attached, and the bill is yours.
Do not expose a tool to an agent that you have not threat-modeled the way you would threat-model a public API endpoint. For every tool you are about to register, answer one question before it ships: What untrusted content can this return, and have you marked it? If you cannot answer that, the tool is not ready, however agent-ready the rest of your website looks.
WebMCP is early. It sits in a Chrome origin trial, the specification is still moving, and most websites have not exposed a single tool. That is the window to decide that agent-safe is part of agent-ready, before the first tool you ship turns out to be the one that hands an agent your reviews and whatever someone hid inside them. The teams that treat tool security as a deployment prerequisite rather than an afterthought will be the ones that survive the transition from websites that agents can read to websites that agents can use.
