Add WebMCP to your website and you give visiting AI agents a set of named tools to invoke. These same tools can be used to turn the agents against the people who sent them. Chrome’s developer page now includes the security advisories for WebMCP, and much of it is written for the websites that provide the tools, rather than the companies that develop the agents. Make your website agent-ready with WebMCP and you have also opened an attack surface, and closing that surface is your job, not the agent’s.
For two years, the conversation about agent readiness has been about access: Can an agent access your content, read your page, and complete your checkout? WebMCP is the version where you no longer hope that an agent will recognize your site based on the markup, but instead give it named tools to invoke. This is the more useful protocol and it is the direction in which the protocol layer of the agent web is moving. It is also the point at which being readable by an agent and being safe by an agent are no longer the same property.
Chrome lists two ways agents are hijacked via WebMCP
Chrome’s agent security guidelines describe two attack vectors, both of which occur through tools provided by a website. The first is the malicious manifesto. In the words of Chrome: “Websites may contain tool definitions with hidden instructions in tool names, parameters, or descriptions designed to hijack the agent.” A tool’s description is text that the agent reads to decide how to use the tool. Therefore, a description may contain an instruction that the agent should never follow.
The second vector is the one that most websites actually attack, and it doesn’t require a malicious website at all. Chrome calls it contaminated output: “Real-time tool responses from otherwise trustworthy websites could contain 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 responses is the return of texts written by other people. If one of these people included an instruction in a review, your legitimate tool passed it on to the agent as if it came from you. The payload is your own user-generated content that you invited.
This works because of a problem that is not a bug and cannot be fixed. “LLMs treat all text, instructions, and user data as a single sequence of tokens,” the guidance says, so the model cannot reliably separate the part you thought was data from the part an attacker thought was a command. For this reason, Chrome says: “Due to the probabilistic nature of LLMs, it is impossible to ensure security within the model itself.” This is the same prompt injection problem that has no clean solution in the model and now carries a log. WebMCP provides this attack with a clean, structured route through the tools you intentionally released.
Making a website agent-ready now includes agent security
Chrome’s guidance places the onus on the website, not just the agent. Chrome’s tool security document begins with a line aimed directly at whoever is disclosing the tools: “Only make your tools available to sources you trust. This is especially important if tools manage user data or otherwise impact the user.” This line is written for whoever ships the tool. This means you.
The defenses are concrete and consist of notes that you attach to the tools you send. untrustedContentHint “Explicitly marks the payload as untrusted to protect the integrity of your site while signaling to the agent that this data requires closer inspection,” and 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 doesn’t change state, which “allows the agent to make better decisions about when to request user confirmations.” exposedTo limits a tool to a set of trusted origins written in the registry itself:
document.modelContext.registerTool({...}, {
exposedTo: ['https://trusted.com']
});
Chrome also limits character budgets, a tool description to 500 characters and a single tool output to around 1,500, adding: requestUserInteraction() Path to confirm an action before it is triggered. Take the obvious example: a tool that displays product reviews to a purchasing agent. Securing it is not an exotic job: mark the output with untrustedContentHintSentence readOnlyHint because it reads rather than buys and limits exposedTo to the origins you actually serve. None of this is the agent’s job. It’s the job of the tool author, most teams are web, CRO or marketing people who add WebMCP to stay current, not the security people who read threat models. This is where things go wrong. Marking which content is data rather than commands is now part of the delivery of a tool, just as sanitizing input has become part of the delivery of a form.
Introduce WebMCP, but first build each tool in the threat model
Giving an agent explicit, callable tools is better than making them guess your site from the DOM, and it’s a skill worth having. None of this is a reason to avoid WebMCP. The point is narrower and more boring than “new protocol, new danger”: the feature comes with an attached invoice, and the invoice is yours.
So the line is simple. Don’t expose a tool to an agent that you haven’t created as a threat model in the way you would a public API endpoint. For each tool you want to register, answer one question before sending: What untrusted content can this return, and have you flagged it? If you can’t answer that, the tool isn’t ready, no matter how agent-ready the rest of your site looks.
WebMCP is early. It is in a Chrome origin version, the specification is still evolving and most websites have not provided a single tool. That’s when it has to be decided that Agent-Safe is part of Agent-Ready, before it turns out that the first tool you ship is the one that gives an agent your reviews and whatever someone has hidden inside.
Additional resources:
This post was originally published on No Hacks.
Featured image: Roman Samborskyi/Shutterstock
Follow us on Facebook | Twitter | YouTube
WPAP (907)
