Article: Chrome has added security guidance for WebMCP, the new way sites expose tools to AI agents, and puts the on-us of keeping those tools safe squarely on website owners. The guidance warns that any site that declares itself “agent-ready” also opens a pathway for malicious actors to hijack agents through crafted manifests or tainted output.

Why WebMCP matters now

Developers have long asked: can an AI agent read my page and complete a transaction? WebMCP flips that script. Instead of an agent guessing how a checkout works, the site publishes a manifest that tells the agent exactly which actions it can perform—price lookup, cart updates, review retrieval, and so on. The result is a much more capable assistant, but also a new attack surface: the moment a site hands an agent a tool, it hands the agent a set of instructions that can be subverted.

The two hijack vectors developers must fear

Malicious manifests – An attacker injects hidden commands into tool names or descriptions. Because agents treat every string of text as potential instruction, a cleverly crafted name can override the agent’s original task and make it do something unintended.

Contaminated output – This is the more common route. A legitimate tool returns user-generated data—product reviews, forum posts, comments. If a malicious user slips a command into that content, the tool delivers the command straight to the agent. Large language models (LLMs) do not reliably separate data from instructions; they see the whole stream as a single prompt.

Practical steps to lock down your manifest

Chrome’s guidance boils down to three configuration rules that developers can add to their WebMCP manifest files.

  • Limit who can call your tools – Use the exposedTo rule to whitelist trusted agent platforms. A payment-processing tool, for example, should not be visible to every AI agent on the web. Define the exact origins that may invoke the tool and reject the rest.

  • Mark untrusted content – Add the untrustedContentHint flag to any tool that returns data that could be user-supplied, such as reviews or comments. This tells the agent that the payload may contain malicious instructions, prompting it to apply stricter safety filters before acting on the text.

  • Declare read-only behavior – The readOnlyHint flag lets you signal whether a tool only reads data or can also write/change state. When a tool is read-only, the agent can proceed without extra user confirmation; when it can modify something, the agent should ask the user before proceeding.

What developers might push back on

The broader stakes

What to watch next

Bottom line

Making a site “agent-ready” is no longer a checkbox for visibility; it is a responsibility for security. By limiting access, flagging untrusted output, and clearly marking read-only tools, developers can stop attackers from turning a helpful AI assistant into a conduit for abuse. Treat the manifest like any other public API: audit it, version it, and lock it down before you expose it to the world.