Hi, I’m Amit Tyagi. Across 18+ years of building and securing websites — from state government digital platforms to enterprise projects for a US-based IT firm — I’ve watched a lot of “the web is changing” moments come and go. Most were incremental. This one isn’t.
WebMCP is a new W3C-backed API, co-developed by engineers at Google and Microsoft, that lets any website expose a set of named, callable “tools” directly to AI agents browsing on a user’s behalf. Instead of an agent guessing which button is “Checkout” by parsing your HTML and taking screenshots, your site simply hands it a structured function it can call. Chrome has already shipped an origin trial for this, and the momentum behind it is real.
Here’s the catch, and it’s the part every marketer and web developer building an “agent-ready” site needs to understand: the same named tools that make your site agent-friendly are also a clean, structured delivery route for prompt injection. Chrome’s own developer documentation now spells this out in detail, and much of the responsibility falls on the website shipping the tools — not just the AI agent calling them. In this post, I’ll walk through what WebMCP actually is, why it creates this risk, and exactly what Chrome recommends locking down first.
1. What WebMCP Actually Is — And Why It’s a Big Deal for Web Teams
For the last couple of years, AI agents navigating websites on a user’s behalf have had to do it the hard way — reading raw HTML, guessing which element is a submit button, taking screenshots to interpret a page visually. It’s slow, brittle, and breaks the moment a site changes its CSS. WebMCP fixes that by letting a website register explicit, typed, named functions that an agent can call directly, using either an imperative JavaScript API or a declarative set of attributes added straight to existing HTML forms.
Think of it as the same idea behind the server-side Model Context Protocol many AI teams already use, but built specifically for the browser and running entirely client-side. A shopping site might expose a tool like search_flights or add_to_cart; a SaaS dashboard might expose toggle_layer or get_account_summary. The agent doesn’t have to reverse-engineer your interface anymore — you’re handing it a menu.
This is landing fast. Chrome shipped an early developer trial, followed by a broader origin trial, and the specification is being actively shaped with input from both major browser vendors. Early benchmarks circulating in the developer community point to major reductions in token usage and computational overhead compared to traditional screenshot-and-guess automation, with task accuracy holding up well. For any business investing in being visible and usable to AI agents — which is quickly becoming as important as being visible to search engines — WebMCP is worth understanding now, not in a year.
2. The Core Problem: LLMs Can’t Reliably Tell Instructions From Data
Here’s the uncomfortable truth sitting underneath all of this, and Chrome’s own guidance says it plainly: large language models process everything — your instructions to the agent, and any data the agent reads along the way — as one continuous stream of tokens. There’s no hard wall inside the model separating “this is a command” from “this is just content.” That single fact is the root of prompt injection, and it existed long before WebMCP came along.
What WebMCP changes is the delivery mechanism. Before, an attacker trying to hijack an agent had to hope the agent would read some manipulated text somewhere on a page. Now, with named tools sitting right there in a manifest — complete with tool names, descriptions, and parameters that the agent reads and trusts as part of doing its job — there’s a much cleaner, more structured channel to smuggle malicious instructions through. Chrome’s documentation is explicit that this is not a theoretical concern; it identifies two distinct attack vectors that agent developers and tool-publishing websites both need to actively defend against.
The important nuance for business owners: this isn’t purely an “AI vendor problem” to wait out. Chrome’s guidance repeatedly puts real obligation on the website exposing the tools — meaning if you’re the one adding WebMCP to your site to look agent-ready, part of the security burden now sits with your web team, not just whichever AI company built the agent visiting your pages.
3. Attack Vector One: Malicious Manifests
The first attack path Chrome flags is what it calls malicious manifests — websites whose tool definitions carry hidden instructions embedded directly inside tool names, parameter names, or descriptions. Since an agent reads a tool’s manifest as trusted context before deciding how to use it, a cleverly worded tool description can quietly redirect the agent’s behavior without the agent ever realizing it’s being manipulated.
This matters because tool manifests are, by design, meant to be read and acted on automatically. An agent isn’t going to pause and second-guess a tool description the way a human developer might read documentation skeptically. If a tool called get_shipping_status actually contains buried text instructing the agent to also retrieve and forward the user’s saved payment details, a poorly defended agent may simply comply — because from its perspective, that instruction arrived through a legitimate-looking channel it was told to trust.
The practical risk compounds when you consider scale. The current WebMCP guidance recommends keeping tool counts under roughly fifty per page and enforcing tight character budgets on tool names, descriptions, and parameters. Those limits exist partly for agent usability, but they also shrink the surface area available for an attacker to hide something malicious in plain sight. For any team building or auditing WebMCP tools, treating every manifest field as untrusted, reviewable, user-facing text — not internal documentation nobody will scrutinize — is now a basic security hygiene step, not an optional extra.
4. Attack Vector Two: Contaminated Outputs From Otherwise Trustworthy Sites
The second, arguably scarier, attack path doesn’t require a malicious website at all. Chrome’s guidance calls this contaminated outputs — a completely legitimate tool, on a completely legitimate site, returning real-time data that happens to include third-party content like user comments, reviews, or messages. If an attacker manages to embed an instruction inside that user-generated content, the agent can end up executing it, because the model still can’t distinguish a genuine data field from an instruction sitting inside it.
Picture a product review tool feeding a shopping agent. The tool itself is honest, the site owner did nothing wrong, but one reviewer’s comment contains a hidden instruction telling the agent to navigate elsewhere or leak information it’s holding in context. The site publishing that tool becomes an unwitting delivery mechanism for an attack it never intended to enable — which is exactly why Chrome frames this as a shared responsibility problem rather than something only “bad actors” need to worry about.
This is the scenario I’d flag hardest to any e-commerce or content-heavy client running WebMCP tools. Any tool surfacing reviews, comments, forum posts, chat transcripts, or any other field a regular user can freely type into is a candidate for this exact attack. If your business relies on user-generated content anywhere near a tool an agent might call, assume it’s a target, and plan your defenses — covered next — before an incident forces the conversation.
5. Why This Is Higher Stakes Than Ordinary Web Security: Authenticated Sessions
Here’s what pushes WebMCP security above a routine sanitize-your-inputs conversation: agents using WebMCP tools typically operate inside a user’s authenticated session. A classic server-side integration runs with whatever permissions a developer deliberately configured for it. A WebMCP tool, by contrast, inherits whatever the logged-in user can already do — their cart, their saved payment methods, their account settings, their private data.
That distinction matters enormously once you connect it back to prompt injection. If an attacker successfully hijacks an agent through a malicious manifest or contaminated output, the agent doesn’t act with some limited service-account permission set — it acts as the actual logged-in user. A hijacked agent browsing a banking site, a healthcare portal, or an enterprise SaaS dashboard could, in principle, be steered into taking real actions or exposing real data, because from the platform’s point of view, the requests are coming from an authenticated, legitimate session.
I bring this up because it changes how seriously a business needs to treat WebMCP rollout. This isn’t the same risk tier as a contact form typo or a minor XSS bug you patch on your next sprint. Any tool that can mutate state — update an order, change account settings, initiate a payment — deserves security review before launch, not after. Chrome’s own guidance leans on this point directly, recommending that teams assume a tool can mutate state unless it’s explicitly and clearly marked otherwise.
6. Lockdown Step One: Mark Untrusted Content With untrustedContentHint
The first concrete defense Chrome recommends is an annotation called untrustedContentHint. If a tool returns user-generated content or any data sourced from outside your direct control — reviews, comments, third-party feeds — you flag that output explicitly, so the agent knows to treat it as data to be handled cautiously, not as an instruction to be trusted and followed.
This connects to a broader technique Chrome calls spotlighting: clearly demarcating untrusted content so the model can tell the difference between what your system is telling it to do and what a third party has merely said. Without spotlighting, an agent reads everything as one undifferentiated stream, which is precisely the vulnerability prompt injection exploits. With it, you’re giving the model an explicit signal — this content is data, evaluate it skeptically, don’t execute instructions found inside it.
For any team shipping WebMCP tools, this should be treated as close to non-negotiable for any tool touching reviews, comments, chat logs, forum content, or any other field where a stranger’s text ends up in your tool’s response. It’s a small addition to a tool definition, but it’s the single most direct lever Chrome points to for reducing the risk that user-generated content becomes an attack vector. Skipping it on a tool that clearly returns third-party text is the kind of oversight that turns a convenience feature into an open door.
7. Lockdown Step Two: Default to readOnlyHint-Aware, Assume-Mutation Thinking
The next piece of Chrome’s guidance is about intent clarity: assume any WebMCP tool can mutate state — meaning it can change something, not just read it — unless the tool’s description or its annotations clearly say otherwise. The readOnlyHint annotation exists precisely to mark tools that only fetch information and never alter anything, so an agent (and any human-in-the-loop safeguards layered on top of it) can treat those tools with a lighter touch than ones capable of taking an action with real consequences.
Why this matters for lockdown priorities: agents making decisions about when to ask for user confirmation, when to proceed automatically, and how much scrutiny to apply to a tool’s inputs need a reliable signal about what that tool can actually do. If every tool is treated identically regardless of risk, you either end up over-prompting users for confirmation on harmless read operations — killing the usability WebMCP was supposed to deliver — or under-protecting genuinely risky, state-changing tools because nothing distinguished them from safe ones.
The fix is straightforward but requires discipline from whoever is writing tool definitions: label read-only tools honestly and consistently, and never mark a tool as read-only if there’s any chance it triggers a side effect. Getting this classification wrong in either direction either frustrates users with unnecessary friction or quietly removes a safeguard that was supposed to be there. This is web development and product decision-making now doubling as a security control.
8. Lockdown Step Three: Scope Tool Exposure With exposedTo
By default, a WebMCP tool you register is private to your own site — other websites and cross-origin iframes can’t see or call it. Chrome’s exposedTo option lets you deliberately open that up to specific, named origins when you actually need cross-site tool sharing, such as a trusted partner integration. The critical lockdown guidance here is blunt: only expose your tools to origins you genuinely trust, and treat this especially carefully for any tool that touches user data or has any real-world effect.
This is a classic least-privilege principle applied to a brand-new surface, and it’s worth taking seriously precisely because it’s easy to get lazy about. A read-only tool that reveals something like a user’s saved preferences might feel low-risk to share broadly, but Chrome’s guidance is direct on this point too — you should only expose that kind of tool to origins you’d be comfortable sharing that same data with through any other channel. Convenience is not a good enough reason to widen your exposure list.
For businesses running WebMCP across multiple properties or working with partners, I’d treat the exposedTo list the same way I’d treat API key access or OAuth scopes — reviewed periodically, granted deliberately, and never left wide open “just in case.” An overly permissive exposedTo configuration is exactly the kind of quiet misconfiguration that looks fine during a launch demo and turns into a real incident six months later when nobody remembers why a tool was ever shared that broadly.
9. Lockdown Step Four: Character Budgets and Human Confirmation for Risky Actions
Chrome’s guidance also gets specific about limits: keep tool descriptions to roughly 500 characters, parameter descriptions to around 150 characters, tool and parameter names short, and individual tool outputs capped at about 1,500 characters. These budgets exist partly for agent performance and reliability, but they double as a security control — tighter limits mean less room for an attacker to bury a malicious instruction inside a wall of text that looks like normal content.
The other major lockdown mechanism is requestUserInteraction() — a way for a tool to pause and explicitly ask the human user to confirm an action before it actually fires. This is your circuit breaker for anything with real consequences: a purchase, an account change, a data-sharing action. Even if an agent has been successfully manipulated by a hidden instruction somewhere upstream, a well-placed human confirmation step means the actual harmful action still requires a real person to say yes.
I’d treat this as the last line of defense you build in, not the first — spotlighting, hints, and origin scoping should already be reducing the odds that a malicious instruction reaches this point at all. But for any tool that spends money, shares personal data, or changes account state, requiring human confirmation regardless of how confident your other defenses feel is simply good practice. Layered defense beats a single point of failure every time, and this is one of the cheapest layers available.
10. Lockdown Step Five: Treat This as an Ongoing Discipline, Not a Launch Checklist
The last piece of Chrome’s guidance is the one most teams underestimate: agent capabilities and prompt injection techniques keep evolving, so a WebMCP security review isn’t a one-time task you complete before launch and forget. Chrome explicitly recommends routine evaluation of your agent’s vulnerabilities, using dedicated red-teaming tools to test for prompt injection and data exfiltration, and running structured audits of complex, multi-turn agent behavior under adversarial conditions.
Chrome also points to the value of “critic” models — a second LLM layer that checks whether a planned tool call actually matches what the user originally asked for, without being exposed to the same untrusted content that may have manipulated the primary agent. This kind of gatekeeping step, combined with data-minimization discipline — only ever passing the personal information a tool strictly needs to function — meaningfully shrinks what an attacker can achieve even if an injection attempt partially succeeds.
For a business team, the operational takeaway is to build WebMCP security into your regular release and monitoring cadence, the same way you already handle vulnerability scanning or dependency updates. Combine automated, real-time alerting with periodic offline analysis — watching for unusual token usage, abnormal tool-call patterns, and user-reported oddities. WebMCP is early, the specification is still moving, and most sites haven’t shipped a single tool yet. That’s precisely the window to decide that agent-safe is part of agent-ready, before the first tool you publish turns out to be the one an attacker uses against your own users.
Conclusion
WebMCP is a genuinely useful step forward — it replaces agents guessing at your website from raw HTML with a clean, structured contract they can actually rely on, and the momentum behind it from both Google and Microsoft suggests it’s not going away. But it also hands prompt injection a more organized delivery route than it’s ever had before, and Chrome’s own documentation is refreshingly honest that a lot of the responsibility for closing that gap sits with whoever builds and publishes the tools, not just the AI agents calling them.
If you’re a business or web team considering WebMCP, my recommendation is simple: don’t ship a single tool without spotlighting untrusted content, accurately labeling which tools mutate state, scoping exposure tightly with exposedTo, respecting the character budgets, and gating any consequential action behind explicit human confirmation. Then keep testing, because this threat model is still moving. Treat agent-readiness and agent-safety as the same project, not two separate ones — because right now, on most teams, they aren’t being handled by the same people, and that gap is exactly where this goes wrong.