The WebMCP Tools You Expose To Agents Can Be Used To Hijack Them

Search Engine Journal covers Chrome’s newly published security guidance for WebMCP, the protocol that lets websites register named, callable tools for visiting AI agents. The key takeaway: the same tools you expose to make your site agent-ready are the attack surface, and securing them is your responsibility.

What’s actually new

Chrome’s guidance identifies two attack vectors, both routed through WebMCP tools. First, a malicious manifest — tool definitions carrying hidden instructions in names, descriptions, or parameters that hijack agent behavior. Second, contaminated outputs — legitimate tools that return user-generated content (reviews, comments, forum posts) where an attacker has planted instructions that the LLM cannot distinguish from your intended data. Chrome states plainly that LLMs treat all text as a single token sequence, making it impossible to guarantee safety inside the model itself. The guidance introduces concrete annotations for tool authors: untrustedContentHint to label UGC payloads, readOnlyHint to signal state-safe tools, exposedTo to restrict tool access to trusted origins, requestUserInteraction() for confirming actions, and character limits on tool descriptions and outputs. WebMCP is currently in a Chrome origin trial and the spec is still in motion.

What it means for your config

This isn’t a config-file story in the traditional sense — WebMCP tool registration happens in JavaScript via document.modelContext.registerTool(), and the security annotations (untrustedContentHint, readOnlyHint, exposedTo) are options passed at registration time. There’s no .webmcprc or YAML config to lint against. But if your team manages Content Security Policy headers, origin allowlists, or any configuration that governs which third-party origins interact with your site, the exposedTo array in your tool registrations is now another surface to keep in sync with those policies. The article doesn’t detail how WebMCP interacts with existing CSP directives or service worker configs, and since the spec is still moving, there’s nothing stable to codify yet. Worth watching, not worth over-engineering today.

The more relevant config-adjacent concern: if you ship tools that surface any database-backed content — product reviews, support threads, CMS-driven pages — your data pipeline now has a security property it didn’t before. Content that was previously “just display text” is now potential agent instructions. That’s closer to an output-sanitization problem than a config problem, but it’s the kind of thing that ends up in build-time checks and CI rules once the pattern matures.

Recommended next step

If you’re experimenting with WebMCP during the origin trial, treat every tool registration like a public API endpoint: enumerate what untrusted content each tool can return, apply the annotations Chrome documents (untrustedContentHint, readOnlyHint, exposedTo), and keep tool descriptions within the stated character budget. Don’t wait for a framework to wrap this for you — the security properties are simple enough to apply manually right now, and building the habit early beats retrofitting later once the spec stabilizes. The original article has the specific code patterns and Chrome’s reasoning in full.

---

Read the full announcement on Search Engine Journal → The WebMCP Tools You Expose To Agents Can Be Used To Hijack Them