Every enterprise web team that has shipped an llms.txt file or annotated a page with entity schema has solved a discovery problem: making a site legible to a model that reads it once and moves on. WebMCP is a different category of problem entirely. It does not describe your business to an AI — it lets an AI agent act on your business, inside a live session, with write access to your systems. A discovery file is a brochure. A WebMCP tool registration is a set of keys handed to a stranger whose identity you can verify but whose intent you cannot.
This distinction matters because most of the implementation guidance circulating in 2026 treats WebMCP as a discovery-and-convenience layer — “expose your booking form as a tool, agents will find it, conversions will follow.” That framing ignores the fact that a callable action is, by definition, a mutation surface. Anything that lets an agent create a booking, submit a form, or query account status is functionally a new API endpoint, and it inherits every security obligation that comes with one: authentication, scoping, rate-limiting, logging, and reversibility. Skip that layer and you haven’t built agent-readiness. You’ve built an unauthenticated write path with a friendlier name.
Two Protocols, One Naming Collision
WebMCP and Anthropic’s Model Context Protocol (MCP) share a name fragment and a purpose — enabling AI systems to call tools — but they operate at different layers of the stack, and enterprise teams conflating them tend to build the wrong thing first.
MCP, introduced by Anthropic in November 2024 and donated to the Agentic AI Foundation under the Linux Foundation in December 2025, is a server-side, transport-agnostic protocol built on JSON-RPC 2.0. It standardises how an LLM-driven agent talks to backend tools, databases and services, independent of any browser context. The current specification, dated 2026-07-28, introduces a stateless core and hardened authorisation designed explicitly for serverless and edge deployment. If you’re exposing an internal API to an agent orchestration layer, MCP is almost certainly the protocol you’re implementing, whether or not your team calls it that.
WebMCP is different in kind, not just in name. It is a W3C Draft Community Group Report, developed jointly by engineers from Chrome and Edge, that introduces a browser-native API — navigator.modelContext — allowing a website to register callable tools directly within the page context the user is already browsing. Chrome shipped an early preview in version 146 (Canary, February 2026), moved to an origin trial in version 149 (May 2026), with general availability planned for Chrome 157. WebMCP offers two registration modes: a declarative approach using HTML annotations, and an imperative one via a JavaScript registerTool() call. Critically, WebMCP inherits the browser’s existing security model — same-origin policy, Content Security Policy, mandatory HTTPS — and, because the tool call happens inside the user’s live session, it automatically carries whatever SSO or session cookie already authenticated that user.
The practical consequence: these two protocols are complementary, and a serious agent-readiness architecture will need both, deployed for different purposes. MCP is how your backend exposes structured operations to an orchestration layer or an enterprise agent fleet. WebMCP is how the page a human (or an agent acting for a human) is already looking at exposes in-context actions without a separate authentication handshake. Treating WebMCP as “MCP for browsers” leads teams to under-engineer the server-side authorisation, because they assume the browser’s same-origin sandbox is doing more security work than it actually is. It isn’t. Same-origin policy stops a malicious third-party script from calling your tool across origins. It does nothing to stop a legitimately-loaded agent, manipulated by adversarial content on the page, from calling a tool it was never meant to invoke.
Authentication Is Not “Whoever Has the Session”
The default assumption in early WebMCP documentation is that session inheritance solves authentication: the user is logged in, the tool call happens in their browser, therefore the action is authorised. This is true only for the narrowest case — a human explicitly directing an in-page agent to perform an action they could perform themselves, in real time, with full attention. It collapses the moment you introduce delegation: an agent acting across multiple steps, a background process summarising and acting on a user’s behalf, or a multi-agent workflow where one agent instructs another.
The more defensible pattern is OAuth 2.0 Token Exchange (RFC 8693), which lets an agent trade a broad, session-level credential for a narrowly scoped, short-lived token specific to a single action — “create one appointment, for this user, within the next ten minutes” rather than “act as this user indefinitely.” Delegation is tracked through the act claim in the resulting JWT, which nests the identity of the acting agent inside the token alongside the user it is acting for. This produces something you cannot retrofit after an incident: a structural, cryptographically verifiable record of who actually initiated a mutation, distinct from whose session it rode in on. Auth0’s Token Vault, introduced in this form in October 2025, is a concrete implementation of this pattern specifically for delegated AI agent access.
Signed capability tokens go a step further and are worth treating as the default for any WebMCP action that mutates state rather than merely retrieves it. A capability token — cryptographically signed, typically with Ed25519 keys — names the specific action it authorises, carries a versioned scope object describing exactly what it permits, and expires quickly. The architectural value here is that authority is decoupled from identity. The token itself, not a re-checked user session, is the thing that proves an action is permitted. This matters directly for prompt injection resistance: if an agent is manipulated by malicious content on a third-party page into attempting an unauthorised action, a well-scoped capability token simply won’t cover it, regardless of what the agent believes it’s supposed to do. The blast radius of a compromised agent is bounded by the scope of the token it’s holding, not by the good judgement of the model.
For enterprise teams building this out, the practical rule is: session-bound access for reads and low-stakes, immediately-reversible interactions; OAuth token exchange with the act claim for any cross-step delegation; signed, narrowly-scoped capability tokens for anything that writes, books, cancels, or spends. Do not let convenience during a demo dictate the authentication tier you ship.
Rate-Limiting Built for Machines, Not Traffic Spikes
Conventional rate-limiting — N requests per minute per IP or API key — was designed around human traffic patterns and doesn’t map cleanly onto agentic behaviour. An agent can legitimately make dozens of calls in a burst while reasoning through a task, and a request-count ceiling that stops malicious scraping will also throttle a genuine, well-behaved agent mid-task. Worse, request count says nothing about the actual cost or risk of what’s being requested; ten read-only queries and ten booking mutations are not equivalent load, but a flat counter treats them identically.
The more robust pattern is token-based, or resource-based, rate-limiting: constraints tied to compute cost, action type, and identity rather than raw request volume, with limits that adapt to historical behaviour and subscription tier. In practice this is implemented at an API gateway layer sitting in front of every WebMCP-exposed endpoint — functioning as an AI gateway rather than a generic reverse proxy. The components worth specifying explicitly in any architecture review: a token bucket allocated per authenticated identity (not per IP, which agents rotate through easily); circuit breakers configured per action pattern, so a looping or malfunctioning agent triggering the same tool repeatedly is cut off before it cascades into your booking system or CRM; and fallback chains per route, so a rate-limited agent receives a structured, machine-readable refusal rather than a raw error that might be misinterpreted or retried aggressively.
This layer is not optional infrastructure you add once volume justifies it. A single agent, correctly authenticated but compromised via a prompt injection attack embedded in third-party content it was asked to summarise, can attempt hundreds of mutating calls in the time it takes a human to notice. Gateway-level circuit breaking is the mechanism that turns that scenario from an incident into a logged anomaly.
The Injection Threat Model Is Structural, Not Linguistic
Most discussion of prompt injection treats it as a content-filtering problem — detect the malicious instruction, strip it out, move on. That framing is useful but insufficient for WebMCP specifically, because the exposed tool call is the payload’s actual objective, not an incidental risk. An attacker doesn’t need the agent to say something wrong; they need it to call something wrong. The defensive posture has to operate at the action layer, not just the language layer.
Detection tooling — Microsoft’s Prompt Shields, published April 2025, and Google Cloud’s Model Armor — screens content before it reaches the agent’s context window, and spotlighting (explicitly demarcating third-party or tool-output content as data rather than instruction) reduces the chance that an agent treats embedded text as a command. Both are necessary. Neither is sufficient on its own, because the goal isn’t to stop the agent from reading a malicious instruction — it’s to stop the instruction from resulting in an unauthorised action even if the agent is fooled.
That’s where behavioural anomaly detection at the tool-invocation layer becomes the load-bearing control. Three patterns are worth building explicit alerting for:
- Scope abuse — a tool call attempting to access data or perform an action outside the agent’s established operational boundary for that session or user.
- Sequence abuse — an unusual or unauthorised chaining of tool calls, such as a document-read operation immediately followed by a call to an external endpoint, a pattern consistent with data exfiltration rather than a legitimate task.
- Rate abuse — a sudden burst of calls inconsistent with the agent’s established baseline, even if each individual call would pass a scope check.
Platforms such as Cyberhaven’s AI Agentic Security, which added workflow-level monitoring and data lineage tracking in May 2026, illustrate the direction this needs to go: not “is this input malicious” but “is this sequence of actions consistent with what this agent is supposed to be doing.” Combined with rigorous schema validation on every tool parameter — reject malformed or semantically implausible inputs before execution, don’t rely on the model to have sanitised them — this shifts the security model from content inspection to behavioural containment, which is the only approach that scales when the attack surface is “an AI you don’t control, acting inside a session you do.”
Audit Logging Has to Answer a Different Question Than Usual
Standard application audit logs answer “what happened.” For agent-initiated mutations, the log needs to answer a harder question: “who, acting on whose authority, decided this should happen, and can it be undone.” That requires capturing four things for every WebMCP action that changes state: the specific agent identity that initiated the call; the human or system on whose behalf it claims to be acting; the exact tool and parameters invoked; and the full delegation chain if more than one agent was involved. The act claim structure from OAuth Token Exchange gives you this chain natively, as an immutable, nested record rather than something reconstructed after the fact from scattered logs — which is precisely why it’s worth adopting even for teams that find the RFC 8693 flow more complex than a simple bearer token.
Logs of this kind need to be stored immutably — write-once, tamper-evident — because their value is almost entirely forensic and almost entirely realised after something has already gone wrong. A log that can be edited after the fact is not evidence in a dispute with a customer or a regulator; it’s a claim.
Reversibility is the companion requirement, and it needs to be designed before the action ships, not retrofitted after the first disputed booking. Data-mutating WebMCP actions should be transactional where the underlying system supports it, with a defined rollback path that the audit log has enough detail to execute precisely — not “cancel the booking” as a manual support ticket, but a specific, tested reversal operation. For higher-stakes mutations, the more conservative pattern is a pending state rather than immediate finalisation: the agent’s call creates a provisional record requiring human confirmation before it takes effect. MCP’s own 2026-07-28 specification formalises this as “elicitations” — a mechanism for a tool to prompt for explicit confirmation before completing an action with real-world consequences, such as confirming cost before creating a paid booking, or confirming intent before a deletion. Any enterprise WebMCP deployment handling money, contracts, or irreversible account changes should treat elicitation as a default, not an enhancement.
Where This Actually Belongs Today
Setting aside e-commerce checkout, which has its own transaction-node considerations, the near-term realistic candidates for WebMCP exposure share a common feature: they’re actions a human would normally perform through an existing UI, where the value of agent access is removing friction from a known workflow rather than inventing a new one.
Appointment scheduling is the clearest fit — a date_pick or submit_booking tool that lets an agent navigate an existing calendar UI on a user’s behalf, rather than requiring a bespoke integration per AI provider. Document retrieval and search is similarly well-suited: a documentation-heavy site exposing search_docs or get_section tools gives an agent structured, accurate access to content it would otherwise have to scrape unreliably, and it replaces a brittle indirect method with a direct, auditable one. Account status queries — dashboard reads, report generation, metric explanation — are lower risk again, since read access carries none of the reversibility burden that mutation does, and are a sensible place to start for teams building WebMCP capability incrementally. Customer support flows, where an agent directs a user to the correct form and pre-fills known fields, sit in a similar low-risk category provided no submission happens without explicit confirmation.
The Liability Question Sits Above the Architecture
None of the above resolves who is responsible when an agent completes an action a user didn’t intend, using a capability token that was technically valid but scoped by a mistake in your implementation. UK regulatory guidance is beginning to address this directly: the Competition and Markets Authority issued guidance in March 2026 addressing business responsibility for outcomes when AI agents transact on a consumer’s behalf, and the direction of travel is that exposing a callable action does not transfer liability for its consequences away from the business exposing it. A signed capability token, an immutable audit log, and a tested rollback path are not just security controls in this context — they are the evidence base a business will need if a disputed agentic transaction ends up in front of a regulator or in a contractual dispute with a customer. Enterprises deploying WebMCP without this evidentiary layer are not simply carrying a technical risk; they are carrying an unquantified contractual one.
The Takeaway
WebMCP is a genuine architectural shift, not an incremental SEO tactic — it turns a website into a set of callable operations that an autonomous system can invoke without a human confirming each step. Treated as a discovery mechanism, it’s a marketing feature. Treated correctly, it’s a new API surface that demands the same engineering discipline your enterprise already applies to any externally callable endpoint: scoped, short-lived credentials rather than inherited sessions; identity- and cost-aware rate-limiting at a gateway layer, not per-IP counters; behavioural anomaly detection on tool-call sequences, not just content filtering; immutable, delegation-aware audit logs; and a designed, tested reversal path for anything that mutates state. Enterprises that build this layer before exposing agent-callable actions will be able to demonstrate control when something goes wrong. Enterprises that don’t will find out, in a dispute or a regulatory inquiry, exactly how exposed “agent-ready” made them.
Frequently asked questions
What is the difference between WebMCP and MCP?
MCP is a server-side, transport-agnostic protocol from Anthropic (now under the Agentic AI Foundation) that lets agents call backend tools independent of any browser; WebMCP is a W3C Draft Community Group browser API (navigator.modelContext) that lets a web page register callable tools directly inside the user’s live browsing session.
Why isn’t a logged-in session enough authentication for a WebMCP tool call?
Session inheritance only holds up when a human is directly and immediately authorising an action; it collapses once an agent acts across multiple steps or on a user’s behalf in the background, which is why delegated actions need OAuth 2.0 Token Exchange with an act claim rather than relying on ‘whoever has the session’.
What is a capability token in a WebMCP architecture?
A capability token is a cryptographically signed, narrowly scoped, short-lived credential (typically Ed25519) that names the exact action it authorises, decoupling authority from identity so that a compromised or manipulated agent cannot exceed what the token itself permits.
Why does conventional rate-limiting fail for AI agents?
Flat request-count limits per IP or API key don’t distinguish a burst of legitimate reasoning calls from malicious activity, and treat low-cost reads the same as high-risk mutations, so enterprise WebMCP deployments need token-based, resource-aware rate-limiting with per-identity token buckets and per-action circuit breakers instead.
