Add WebMCP to your website and you’re back visit of AI agents a set of named tools to call. These same tools can be used to turn agents against those who sent them. The Chrome developers site now has security tips for WebMCP, and much of it is written for the websites exposing the tools rather than the companies that create the agents. Prepare your website for an agent with WebMCP, and you’ve also opened an attack surface, and closing it is your job, not the agent’s.
For two years, the conversation around agent readiness has been about access: Can an agent access your content, read your page, complete your payment? WebMCP is the version where you stop hoping for an agent to discover your website from markup and start giving them named tools to call. This is the most useful protocol, and this is the direction to follow the protocol layer of the Web agent moves. This is also where being readable to an agent and being safe to an agent cease to be the same property.
Chrome named two ways agents are hacked via WebMCP
Chrome Agent Security Tips describes two attack vectors, and both arrive via the tools exposed by a website. The first is the malicious manifesto. In Chrome’s words, “Websites may contain tool definitions with hidden instructions, in tool names, settings, or descriptions, designed to distract the agent.” » The description of a tool is text that the agent reads to decide how to use the tool. A description may therefore contain an instruction that the agent was never intended to follow.
The second vector is what most websites will actually target, and it doesn’t require a malicious website. Chrome calls this tainted output: “Responses from real-time tools from otherwise trustworthy sites may include malicious instructions as part of third-party data, such as user comments. » A tool on your own website that returns your product reviews, comment threads, forum posts, or support responses returns text written by other people. If one of these people inserted an instruction in a review, your legitimate tool forwarded it to the agent as if it came from you. The payload is your own user-generated content and you invited it.
This works because of something that is not a bug and will not be fixed. “LLMs treat all text, instructions, and user data as a single sequence of tokens,” the guide says, so the model cannot reliably separate the part you think of as data from the part an attacker intended as a command. This is why Chrome states that “the probabilistic nature of LLMs makes it impossible to guarantee security within the model itself.” It’s the same rapid injection problem which does not have its own solution inside the model, now carrying a protocol. WebMCP provides this attack with a clean and structured distribution path via the tools you have voluntarily published.
Making a website agent-ready now means making it agent-secure
Chrome’s guidelines place this obligation on the website, not just the agent. Chrome Tools Security Document opens with a line aimed directly at anyone exposing the tools: “Only expose your tools to origins you trust. This is especially important when the tools manage user data or impact the user.” This line is written for whoever is shipping the tool. That means you.
The defenses are concrete and they are annotations that you attach to the tools that you ship. untrustedContentHint “explicitly labels the payload as untrusted, to help protect the integrity of your site while signaling to the agent that this data requires further review,” and Chrome indicates when to use it: “If a tool returns user-generated content (UGC) or data from an external source, 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 users for confirmations.” exposedTo restricts a tool to a range of origins you trust, written into the record itself:
document.modelContext.registerTool({...}, {
exposedTo: ('https://trusted.com')
});
Chrome also limits character budgets, a tool description to 500 characters and single tool output to around 1,500, and adds a requestUserInteraction() path to confirm an action before it is triggered. Let’s take the obvious example, a tool that presents product reviews to a sales agent. Securing it is not an exotic job: mark its release with untrustedContentHinttogether readOnlyHint because he reads rather than buys, and limits exposedTo to the origins that you actually serve. None of this is the agent’s job. It is the work of the author of the tool, which in most teams is the web, CROor marketers who add WebMCP to appear current, not security managers who read threat models. It is in this gap that things go wrong. Marking which of your content is data and not commands is now part of shipping a tool, in the same way that sanitizing inputs is now part of shipping a form.
Adopt WebMCP, but first model threats for each tool
It’s better to give an agent explicit, callable tools than to have them guess your website from the DOM, and this feature is worth it. None of this is a reason to avoid WebMCP. The point is narrower and more boring than “new protocol, new danger”: capacity comes with a bill attached, and the bill is yours.
The line is therefore simple. Don’t expose a tool to an agent you don’t have modeled by threat the same way you would threat model a public API endpoint. For each tool you’re about to save, answer one question before it’s delivered: What untrusted content might this return, and have you flagged it? If you can’t answer this question, the tool is not ready. agent ready the rest of your website appears.
WebMCP is ahead. It’s in a Chrome original trial, the specification is still evolving, and most websites haven’t exposed any tools. This is the window to decide that officer safety is part of agent readybefore the first tool you ship turns out to be the one that hands an agent your reviews and whatever someone has hidden there.
More resources:
This article was originally published on No hacks.
Featured image: Roman Samborskyi/Shutterstock
