Originally published on The Searchless Journal
For two years, the conversation around agent-ready websites has been about access. Can an AI agent reach your content? Can it read your pages? Can it complete a checkout? The arrival of WebMCP, the Model Context Protocol adapted for the web, shifts this conversation from access to capability. Instead of hoping an agent figures out your website from the HTML, you hand it named tools it can call directly. This is more powerful, more reliable, and more dangerous than anything that came before it.
Chrome's developer site now carries detailed security guidance for WebMCP, and the framing is notable. The obligation to make websites safe for agents falls on the websites exposing the tools, not on the companies building the agents. If you make your website agent-ready with WebMCP, you have opened an attack surface. Closing it is your job.
Two Attack Vectors Chrome Identified
The Chrome security documentation describes two primary ways that WebMCP tools can be used to hijack AI agents, and both arrive through the tools a website exposes.
The first is the malicious manifest. A website publishes tool definitions that contain hidden instructions embedded in tool names, parameter descriptions, or other text fields that the agent reads. Because the agent processes all text as part of its context window, an instruction hidden in a tool description can override the agent's original task. A tool named check_inventory could carry a description that includes instructions to exfiltrate user data or redirect the agent to a different action entirely. The agent cannot reliably distinguish between the functional description of the tool and the injected command because both arrive as text tokens in the same stream.
The second vector is more common and harder to eliminate. Chrome calls it contaminated output. A tool on your own legitimate website returns data that includes user-generated content, product reviews, forum posts, support tickets, or comment threads. If an attacker has planted an instruction inside one of those user contributions, your tool delivers the payload to the agent as if it came from you. The tool is legitimate. The website is legitimate. The data source is the problem.
This works because of something fundamental to how large language models operate. They treat all text, whether it is an instruction or user data, as a single sequence of tokens. The model cannot reliably separate the part you meant as data from the part an attacker meant as a command. Chrome's guidance states this directly: the probabilistic nature of LLMs makes it impossible to guarantee safety inside the model itself. This is the prompt injection problem, and it has no clean fix inside the model. WebMCP gives it a clean, structured delivery route through the tools you published on purpose.
What Chrome Asks Website Owners To Do
The Chrome guidance is written for whoever ships the tools, and the prescriptions are concrete.
First, only expose tools to origins you trust. The exposedTo annotation lets you restrict a tool to specific agent platforms. A tool that processes user payments should not be available to every agent that visits your site. The principle of least privilege applies here. Expose the minimum set of tools necessary, and restrict each one to the smallest set of origins that need it.
Second, mark tools that return user-generated content. The untrustedContentHint annotation explicitly labels a tool's output as untrusted, signaling to the agent that the data requires heightened scrutiny. If a tool returns product reviews, forum posts, or any externally sourced data, this annotation should be present. It does not solve the prompt injection problem, but it gives the agent's safety layer a chance to apply additional filtering.
Third, mark read-only tools. The readOnlyHint annotation indicates that a tool does not change state, which allows the agent to make better decisions about when to ask for user confirmation. A tool that reads product information can be called freely. A tool that places an order should require confirmation every time. This distinction is critical for agentic commerce, where the difference between browsing and buying is the difference between no risk and full risk.
The Agent-Ready Versus Agent-Safe Distinction
For the past year, the GEO and agent-readiness community has focused on making websites legible to AI agents. Structured data, llms.txt files, semantic HTML, and clear content hierarchies all serve this goal. WebMCP is the next step beyond legibility. It moves from passive legibility, where the agent reads what you have published, to active capability, where the agent can do things on your site through defined interfaces.
This is where being legible to an agent and being safe for an agent stop being the same property. A website can be perfectly legible and completely unsafe. A product page with rich structured data is legible. A WebMCP tool that accepts a product search query and returns results that include unmoderated user reviews is legible but unsafe. The first presents information. The second creates a channel for injection.
The distinction matters because the push toward agent-ready infrastructure is accelerating. E-commerce platforms are adding WebMCP endpoints. CMS providers are building agent integration layers. Travel sites, financial services, and healthcare platforms are all exploring tool exposure. Each of these additions expands the attack surface, and the security considerations are often treated as secondary to the functionality.
The User-Generated Content Problem
The contaminated output vector deserves particular attention because it is the one most websites will actually hit. Any site that allows user contributions, reviews, comments, forum posts, support tickets, or any other form of public text is a potential injection vector. The tool you expose for legitimate purposes returns text that someone else wrote, and that text can contain instructions designed to hijack the agent.
The defense is not to eliminate user-generated content. It is to sanitize what your tools return. This means filtering tool output through the same moderation pipelines you would apply to any user-facing surface. It means stripping or encoding text that could be interpreted as instructions. It means using the untrustedContentHint annotation so the agent knows to treat the output with appropriate suspicion.
For websites with large volumes of user-generated content, this is a significant engineering challenge. Review platforms, e-commerce sites with customer reviews, community forums, and social platforms all face the same problem at scale. The cost of not addressing it is that your site becomes the vector through which someone else's agent gets hijacked.
Implications For The Agentic Web
The agentic web is being built on the assumption that agents can safely interact with arbitrary websites through standardized protocols. WebMCP is one such protocol, and it is gaining traction. The security model Chrome describes puts the burden on website owners, which is the correct architectural decision. The website knows what its tools do, what data they return, and what risks they introduce. The agent visiting for the first time does not.
But this also means that agent-readiness is no longer just a GEO concern. It is a security concern. The teams building WebMCP endpoints need to include security review in the development process. The tools exposed need threat models. The output of each tool needs to be analyzed for injection risk. These are standard security practices for API development, but they are not yet standard for agent tool development because the field is too new.
The websites that get this right early will be the trusted destinations for agentic commerce. The ones that do not will be the cautionary tales. The difference is not a matter of technology. It is a matter of treating agent safety with the same seriousness as agent access, from the first tool you expose.
Top comments (0)