What happened
Chrome's developer documentation for WebMCP — the origin-trial protocol that lets a website expose named, callable tools to visiting AI agents — describes two attack vectors. The first is the malicious manifest: hidden instructions tucked into a tool's name, parameters, or description, built to hijack the agent that reads them.
The second is subtler and, per the docs, the one most sites will actually hit: contaminated output. A tool on an otherwise trustworthy site returns real-time data that includes third-party text — user reviews, comments — and that text carries instructions the agent then follows. The root cause is structural. LLMs treat all text as undifferentiated tokens, so safety can't be guaranteed inside the model itself. The defense has to live at the boundary.
Chrome gives site owners concrete mitigations: an untrustedContentHint flag for tools returning UGC or external data, a readOnlyHint for tools that don't change state, an exposedTo array restricting which origins can call a tool, and character budgets — tool descriptions capped at 500 characters, outputs at roughly 1,500. The standing advice: threat-model every tool the way you would a public API, before deployment.
Why this matters
For an ecommerce store this lands squarely on reviews and Q&A — the most agent-relevant content you host, and the only content on your site an attacker can write for free. A planted review carrying hidden instructions is prompt injection you're hosting and serving under your own domain's credibility. Nobody had to breach anything; your review form was the front door.
Play it forward into agentic shopping. An agent comparing products across stores, nudged by a contaminated review to prefer one item or skip a price check, is a new species of sabotage — and the store serving the poisoned text takes the reputation hit, not the attacker. Most stores expose nothing through WebMCP yet; the protocol is still in origin trial. Which is exactly why this is cheap to get right now and expensive to retrofit later.
One honest caveat: hints are hints. The flags tell an agent how to treat your output; they don't force compliance. Sanitize UGC server-side as well — strip or neutralize anything instruction-shaped before it enters a tool response — rather than betting the store on a single annotation.
What to do about it
Threat-model each tool like a public API
Before exposing anything, inventory what every tool returns and mark each path where UGC or third-party data enters the output. Chrome's guidance is explicit on this — the threat model comes first, the deployment second.
Set every mitigation flag, not your favorite one
untrustedContentHint on anything touching reviews or Q&A, readOnlyHint on everything that doesn't mutate state, and an exposedTo allowlist so only origins you trust can call the tool. The flags are a checklist; use all of them.
Keep UGC out of responses that don't need it
The 500-character description and ~1,500-character output caps push discipline anyway. Return structured facts — price, stock, specs — instead of raw review text wherever the tool's job allows it. Less hostile text in the pipe, less to hijack.