WebMCP hands publishers the liability. Nobody’s saying so.

Chrome's WebMCP security guidance dropped this week, and the coverage has focused on the technical shape of the problem — malicious tool manifests, contaminated outputs, prompt injection dressed up in a protocol. All of that is real and worth reading. But the more interesting story is buried in the opening line of Chrome's tool-security document, which is written as a direct instruction to 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.*

Read that again. The instruction isn't to the agent builder. It's to you, the website. The party being asked to accept responsibility for how an AI agent behaves is the party that published the tool the agent used.

That's a liability shift, and it hasn't been named as one.

For the last two years, the agentic web conversation has treated publishers as passive infrastructure. Agents visit, agents transact, agents cite. The interesting engineering problems all lived on the agent side. WebMCP flips that. The moment you register a tool via `document.modelContext.registerTool`, you have accepted a responsibility that used to belong to somebody else — and there's no contract, no insurance model, and no marketing guidance that acknowledges you've done it.

What Chrome is actually saying

Strip the technical language and Chrome's guidance reads like a warning notice. Two attack vectors. The first is the malicious manifest — a tool description that carries a hidden instruction the agent then obeys. The second is what Chrome calls 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.*

The second one is the one that matters, because it doesn't require the website to be malicious. It requires the website to have user-generated content. Reviews. Comments. Forum posts. Support replies. Q&A threads. If any of those return through a WebMCP tool, and any of that content contains an instruction addressed to an AI agent, your tool has just delivered a hostile payload with your domain as the return address.

The reason this can't be patched is structural. Chrome states it plainly: *LLMs treat all text, instructions and user data, as a single sequence of tokens.* The model cannot separate "here is the data you requested" from "here is a command you should now execute" because to the model there is no difference. This is the same prompt injection problem that has been unsolved since the first LLM shipped. WebMCP doesn't create it. WebMCP gives it a clean protocol-level delivery route.

And then Chrome tells the publisher what to do about it. Add `untrustedContentHint`. Add `readOnlyHint`. Restrict `exposedTo` to trusted origins. Annotate your tools. Curate what your tools return. Audit your UGC. Do this correctly, or the agent visiting your site will do something the user who sent it didn't ask for, and the trail will lead back to your tool.

The obligation is being written into the protocol, and the obligation belongs to the publisher.

The asymmetry nobody's naming

Here's the shape of the emerging relationship, and it's worth being clear about it.

The agent builder captures the value. The publisher accepts the risk.

The agent builder — OpenAI, Anthropic, Google, whoever ships the browser agent — controls the model, the training data, the safety layer, the tool-use policy, and what the agent does with the information it receives. They earn revenue from the user or from subscription fees. They set the rules for how their agent interprets tools.

The publisher — you, the website — controls what tools they expose, what those tools return, and (per Chrome's guidance) how well those tools are annotated and hardened. They earn no direct revenue from the agent visit. They accept the attack surface. And when something goes wrong, the entry point traces back to their infrastructure.

That's the deal being written into the protocol layer. The agent builder captures the value. The publisher accepts the risk.

I'm not saying this is a conspiracy. It's the natural shape of a permissionless protocol — whoever exposes the surface is responsible for what happens through it, that's how the web has always worked. But the web has never before had a category where the thing visiting your site is a probabilistic system with billions of dollars of R&D behind it, and the thing you're being asked to defend against is instructions hidden inside your own users' comments.

This is closer to being asked to secure your own building against burglars using master keys the locksmith gave out for free.

Why the marketing industry is missing this

Search the SEO and GEO commentary on WebMCP and you'll find a lot of enthusiasm about being *agent-ready*. Get your schema clean. Register your tools. Make sure your product data is machine-callable. The framing is entirely about visibility — being present in the agentic web, being findable, being transactable.

Almost nothing in that commentary addresses the fact that becoming agent-ready is becoming an attack surface. The two are the same act. You cannot register tools without exposing them, and you cannot expose them without accepting the liability model Chrome has just written down.

This is a repeat of a pattern the industry keeps falling into. When schema.org launched, the conversation was about visibility, not the auditing burden of maintaining structured data at scale. When AMP arrived, the conversation was about speed, not the platform dependency. When Core Web Vitals became a ranking factor, the conversation was about optimisation, not the ongoing engineering cost. Each time, the marketing industry sold the upside and quietly left the downside for the client to discover in year two.

WebMCP is worse than any of those precedents, because the downside isn't a maintenance cost. It's a security posture. If you expose a tool that returns user comments and one of those comments contains a prompt injection that redirects an agent to a competitor's checkout, or exfiltrates the agent user's session data, the incident has your domain in the logs. Not the agent's. Not OpenAI's. Yours.

Making your website agent-ready and making your website agent-safe are two different projects, and only one of them has an obvious ROI story.

What this means for the actual work

I don't think WebMCP is a bad idea. Structured tool access is a genuine improvement over the current situation, where agents grope around in markup and hope for the best. Named tools with defined schemas is how any of this scales. Chrome is right to publish security guidance early, and it's a credit to the protocol design that the hints and origin restrictions exist at all.

But if you're advising clients on getting agent-ready — and this is going to be a significant slice of consulting work for the next two years — you have a duty to be honest about what they're taking on.

Three things become real obligations the moment a WebMCP tool ships.

First, UGC hygiene stops being a moderation problem and becomes a security problem. Every review, comment, forum post, and support message that can be returned through a tool is now potential injection material. The `untrustedContentHint` annotation is table stakes, not a nice-to-have. It doesn't solve the problem — Chrome is explicit that the model cannot guarantee safety inside itself — but it signals to the agent that this data should be treated with scrutiny. Ship without it and you've made the problem worse than it needed to be.

Second, tool inventory becomes a governance artefact. You need to know which tools your site exposes, what they return, who registered them, what they're annotated as, and which origins they're exposed to. That list needs to be reviewed on a schedule. This is closer to how mature security teams manage API surface than how marketing teams manage schema — and marketing teams are the ones being told to ship these tools.

Third, incident response needs an agent-injection playbook. When an agent misbehaves and the trail leads to your tool, you need to be able to answer three questions quickly: what tool was called, what did it return, and was the payload user-generated. Sites without logging around WebMCP tool calls will be unable to answer any of these when it matters.

None of this is glamorous. None of it appears in the pitch decks currently being shown to clients about agentic commerce. But it's the actual work that follows from Chrome's guidance, and someone will end up doing it.

Better it be you at the front end than a forensic contractor at the back end.

The limits of this argument

Two honest caveats.

First, WebMCP is early. Adoption is small, the threat model is theoretical for most sites right now, and the security research community will develop better defensive tooling over time. I'm not suggesting anyone panic. I'm suggesting the marketing industry stop selling agent-readiness as if it were a pure upside.

Second, agent builders will absorb some of this liability whether they want to or not. The reputational cost of high-profile agent hijacks will push OpenAI and Google to build better tool-use safety, better provenance signals, better sandboxing. The protocol will mature. The asymmetry I've described is the shape of things today, not the permanent settlement. Reasonable people can disagree about how quickly the balance shifts.

But the settlement will be shaped by whoever pushes back hardest during the shaping. Right now the publishers — the people accepting the attack surface — are not at the table. They're being handed a hint API and a set of best practices and told to get on with it. The agent builders are setting the terms.

What to actually do this quarter

If you run a site that's likely to expose WebMCP tools in the next 12 months, the useful moves are unglamorous and available now.

Audit what user-generated content lives on pages that would plausibly be exposed via tools. If your product pages return reviews through a tool, those reviews are now attack surface. Decide whether the tool actually needs to return them, or whether it should return a summarised safe subset.

Write down which team owns WebMCP tool registration before any tools ship. In most organisations this will land ambiguously between marketing, engineering, and security. Ambiguity here means nobody is responsible when something goes wrong. Pick an owner and give them the security guidance to work from.

Push your agencies and consultants for a straight answer on how they're planning to handle the security dimension of agent-readiness. If the answer is a blank stare or a pivot back to visibility, you've got the wrong agency for this work. The visibility conversation is the easy half. The safety conversation is the one that will matter when the incident happens.

The protocol is being written now, and the norms around it are being written faster than the guidance. The publishers who will do well in the agentic web are the ones who accept early that being legible to agents and being safe for agents are two different projects, both required, neither optional.

The rest will discover the difference the hard way.