WebMCP Tools Exposed to Agents Can Be Hijacked

When you integrate WebMCP into your website, you are effectively handing visiting AI agents a curated set of callable tools. However, those same tools can be weaponized, turning the agents against the very people who deployed them. Chrome’s developer platform now hosts security guidance for WebMCP, and notably, much of the advice targets the websites exposing these tools, not just the companies building the agents. Making your site agent-ready with WebMCP also means opening a new attack surface, and the responsibility to close it falls squarely on you, not the agent.

For the past two years, the conversation around agent-readiness has centered on access: Can an agent reach your content, parse your page, or complete a checkout? WebMCP represents a shift where you stop hoping an agent will decode your markup and instead hand it explicit, named tools to call. This is the more practical protocol and the direction the agentic web’s protocol layer is heading. But it is also the point where being legible to an agent and being safe for an agent diverge into separate concerns.

Chrome Identifies Two Primary Attack Vectors Through WebMCP

Chrome’s agent-security documentation outlines two attack paths, both originating from the tools a website exposes. The first is the malicious manifest. As Chrome explains, “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 determine how to use it, so a description can embed an instruction the agent was never meant to follow.

The second vector is more common and does not require a malicious website at all. Chrome calls this 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 legitimate tool on your own site that returns product reviews, comment threads, forum posts, or support replies is returning text authored by others. If someone planted an instruction inside a review, your own tool delivers it to the agent as if it came from you. The payload is your own user-generated content, and you invited it in.

This vulnerability stems from 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, meaning the model cannot reliably separate data from commands. That is why Chrome concludes that “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 within the model, now repackaged as a protocol. WebMCP gives that attack a clean, structured delivery route through the tools you intentionally published.

Making a Website Agent-Ready Now Includes Making It Agent-Safe

Chrome’s guidance places the obligation squarely on the website, not solely on the agent. The tool-security document opens with a direct line aimed 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 come as 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 advises its use: “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 directly into the registration:

document.modelContext.registerTool({…}, { exposedTo: [‘https://trusted.com’] });

Chrome also caps character budgets, with a tool description limited to 500 characters and a single tool output to roughly 1,500. It adds a requestUserInteraction() path for confirming an action before it executes. Take a common 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 responsibility. It is the tool author’s job, which on most teams falls to web, CRO, or marketing people adding WebMCP to stay current, not the security teams who read threat models. That gap is where things go wrong. Marking which of your content is data and not commands is now part of shipping a tool, the same way sanitizing input became part of shipping a form.

Adopt WebMCP, But Threat-Model Every Tool First

Handing an agent explicit, callable tools is far better than making it guess your website from the DOM, and the capability is genuinely valuable. None of this is a reason to avoid WebMCP. The point is simpler and more mundane than “new protocol, new danger”: the capability arrives with a cost, and that cost is yours to pay.

So the rule is straightforward. Do not expose a tool to an agent that you have not threat-modeled the way you would 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, no matter how agent-ready the rest of your website looks.

WebMCP is still early. It sits in a Chrome origin trial, the specification is evolving, and most websites have not exposed a single tool yet. This 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.