The Industry Just Built a Wall. Google Put in a Door.

By Robin Martherus

In the last twelve months, the AI security industry converged on a single architectural bet: put a gateway in front of MCP.

The logic was sound. The Model Context Protocol has become the de facto standard for connecting AI agents to tools and data. Agents authenticate, call tools, get results. MCP is the chokepoint. Control MCP, control the agent.

A rush of vendors built exactly this. Runlayer raised $11M to build MCP-specific security — centralized registry, threat detection, fine-grained permissions. MintMCP built the first SOC 2 Type II certified MCP platform. Cloudflare, Docker, and Wiz entered the market. Ping Identity shipped an MCP Gateway with DLP and session recording. Every major enterprise security vendor now has an MCP governance story.

They all bet on the same assumption: MCP is the only structured path between an agent and a service.

On February 10, 2026, Google — with Microsoft as co-developer — shipped WebMCP in Chrome 146. It’s a new browser standard, incubated at the W3C, that gives any website the ability to become a structured agent interface.

In one release, the assumption underlying a year of investment became architecturally false.

What WebMCP Actually Is

WebMCP is not MCP running in the browser. It’s a separate protocol with two APIs:

• Declarative API — standard actions defined directly in HTML forms
• Imperative API — complex interactions requiring JavaScript execution

These APIs let websites expose structured, machine-readable actions directly to browser-resident AI agents. Instead of scraping the DOM and guessing where buttons are, agents invoke clearly defined tools inside the browser.

This is genuinely useful. An agent that needs to search inventory, initiate checkout, or submit a service request can now do so through explicit API calls rather than brittle screen-scraping. It’s faster, more reliable, and more predictable.

It is also, from a security perspective, a catastrophe.

The Bypass Nobody Is Talking About

Here is the problem in one sentence: an agent that is denied an action at the MCP gateway can perform the same action through WebMCP on the service’s website, where no gateway exists.

Consider how MCP gateways work. An enterprise deploys Runlayer or MintMCP. They configure policies: this agent can read CRM data but not write it. This agent can access Salesforce but not HR systems. The gateway sits between the agent and the MCP server, enforcing these policies on every tool call.

Now the same agent opens Chrome. The CRM has a website. That website has adopted WebMCP (because Google and Microsoft are pushing it as a web standard). The agent invokes the CRM’s WebMCP tools — search, update, export — using the user’s authenticated browser session.

The MCP gateway never sees this traffic. It can’t. WebMCP operates inside the browser, between the page and the browser’s built-in agent infrastructure. There is no proxy point. There is no chokepoint. The gateway is architecturally irrelevant.

Here’s the thing: this bypass already existed before WebMCP. Any sufficiently capable agent can interact with a service’s human-facing website directly — scraping the DOM, clicking buttons, filling forms, reading results — using the user’s authenticated browser session. Agents don’t need MCP to reach services. They just need a web browser. MCP gateways have always been invisible to these interactions.

What WebMCP changes is not whether the bypass is possible — it’s how reliable, structured, and scalable it becomes. DOM scraping is brittle. WebMCP is a W3C standard with explicit tool definitions and typed parameters. Google didn’t open a new door. They paved an existing dirt path into a highway.

This isn’t a theoretical attack. It’s the intended design. Google’s own documentation positions MCP and WebMCP as complementary protocols: MCP for backend operations, WebMCP for “contextual, in-browser interactions.” They’re encouraging every service to expose both paths.

It Gets Worse: Session Inheritance

MCP gateways enforce agent-specific credentials — scoped tokens, just-in-time access, least-privilege service accounts. This is hard-won progress. The entire MCP security architecture depends on agents having their own constrained credentials, distinct from the user’s.

WebMCP throws this away.

WebMCP inherits the browser’s existing session — cookies, SSO credentials, role-based access controls already present in the authenticated web session. There is no separate agent credential. No agent-specific scoping. No mechanism to distinguish agent actions from human actions.

A browser agent operating within a user’s authenticated session gets the user’s full privilege context by default. If the user is a senior engineer with broad access, the agent is a senior engineer with broad access. Every carefully scoped MCP credential, every just-in-time access policy, every least-privilege enforcement — all of it is bypassed when the agent goes through the browser instead.

This is the credential-parity problem — agents and humans sharing the same credentials with no way to differentiate them — baked into a W3C standard.

The Specific Attack Vectors

The MCP ecosystem has already demonstrated what happens when agents have structured access to services. Invariant Labs documented tool poisoning attacks where malicious MCP servers hijacked agent behavior. GitHub’s MCP server was exploited via prompt injection to exfiltrate private repository contents. A WhatsApp MCP server was compromised to silently copy users’ entire message histories.

WebMCP inherits all of these attack classes and adds new ones:

The cross-tab isolation problem is particularly concerning. The WebMCP specification’s own authors acknowledge this as an open problem: “any browser-based agent framework faces the question of cross-tab context isolation — an agent with access to your bank account tab and a malicious site tab should not be able to move data between them.” They expect “something analogous to CORS policies for tool access to emerge as the standard matures.” In other words: the security model doesn’t exist yet, but the protocol shipped anyway.

The Structural Problem

This is not a WebMCP bug. It’s not a deployment failure. It’s a structural problem with how the industry thinks about AI agent security.

The MCP gateway approach assumes a single chokepoint. Security Boulevard described MCP as the gateway that makes agents’ conversations with internal systems visible and controllable. MintMCP calls it a “single chokepoint for all agent-tool interactions.” This is the value proposition: one place to enforce authentication, authorization, DLP, and audit logging.

But a chokepoint only works if all traffic flows through it.

WebMCP means there are now at least three structured paths between an agent and a service:

Agent wants to perform action X on Service S
  |
  +-- Path 1: MCP server for S
  |           Gateway policies apply
  |
  +-- Path 2: Direct API call to S
  |           Credential-scoped, no agent governance
  |
  +-- Path 3: Web UI (DOM scraping)    <-- ALREADY EXISTS
  |           Brittle but functional,
  |           inherits browser session,
  |           no gateway visibility
  |
  +-- Path 4: WebMCP on S's website    <-- NEW, STANDARDIZED
              Structured agent interface,
              inherits browser session,
              no gateway, no governance,
              W3C-standardized, reliable

Path 3 already existed — capable agents have been interacting with web UIs through DOM scraping and browser automation for years. But it was brittle, slow, and broke when UIs changed. Path 4 is Path 3 with a W3C standard, explicit tool definitions, and typed parameters. It combines the structure and reliability of Path 1 with the governance absence of Paths 2 and 3 — and it’s backed by Google and Microsoft. It will become the path of least resistance for any capable agent.

Every dollar spent securing MCP through gateway architectures is a dollar spent securing one of four doors while three others stand open. And the newest door is the widest.

What’s Missing from the WebMCP Spec

Evaluate WebMCP against the most basic security questions:

WebMCP is a pure “can” protocol. It makes it easier for agents to act. It adds zero governance over why they’re acting or whether they should be.

The CVE That Already Happened

WebMCP shipped in early preview in February 2026. By March, CVE-2026-3918 was published — a critical use-after-free vulnerability in Chromium’s WebMCP component, potentially enabling remote code execution in both Chrome and Edge.

The protocol’s security model doesn’t exist yet, and the implementation is already exploitable.

What This Means for Security Teams

If you’ve deployed an MCP gateway, it’s still valuable — but it now governs one of multiple paths, not the only path. Specifically:

• Audit your WebMCP exposure. Any service your agents access that has a website is potentially WebMCP-accessible. That includes your CRM, your HR system, your code repositories, your cloud consoles.
• Don’t assume browser agents are constrained by MCP policies. A browser-resident agent can invoke WebMCP tools on any website the user has an authenticated session with. Your MCP gateway policies are invisible to it.
• Watch for Chrome 146 adoption. WebMCP is behind a feature flag today. When it ships by default (expected mid-to-late 2026), every Chrome and Edge browser becomes a potential ungovernored agent interface.
• Re-evaluate the “single chokepoint” assumption. If your agent security architecture depends on all agent traffic flowing through one gateway, WebMCP has invalidated that assumption.

The Deeper Issue

WebMCP is a symptom, not the disease.

The disease is an industry that keeps adding more ways for agents to act — more “can” — without adding any mechanism for verifying why they’re acting or whether they should be. MCP gave agents structured tool access. WebMCP gives them structured web access. Each new protocol expands what agents can do. None of them asks what agents intend to do.

Gateway security is protocol-level security. It works within the protocol it governs. It is structurally incapable of governing what happens outside that protocol. And every new agent access protocol that ships — WebMCP today, whatever comes next — is another path that exists outside the gateway’s reach.

The industry needs governance that sits above the protocol layer — governance that travels with the agent, not with the connection. An agent that carries a declared purpose, whose actions are checked against that purpose regardless of which protocol it uses to reach a service, cannot be bypassed by adding a new access path. The governance moves with the agent, not with the wire.

This is the thinking behind the Tamed Autonomy framework — a theoretical exploration of what governance above the protocol layer might look like: intent declarations that become enforceable behavioral contracts, normative constraints that evaluate purpose against organizational context, and trust physics that modulate agent autonomy based on demonstrated behavior. It’s not a product. It’s a catalyst for a conversation the industry needs to have — about governance that operates above MCP, above WebMCP, above whatever comes next.

Because the next bypass is always coming. The question is whether the industry will keep building walls, or start thinking about what travels with the agent.

Sources

• WebMCP Early Preview — Chrome for Developers
• When to Use WebMCP and MCP — Chrome for Developers
• WebMCP Explained — ScaleKit
• Your Most Dangerous User Is Not Human — Security Boulevard
• CVE-2026-3918: WebMCP Vulnerability — Windows News
• MCP Tool Poisoning Attacks — Invariant Labs
• Runlayer MCP Security
• MintMCP Enterprise AI Infrastructure
• AI Agent Security Risks 2026 — Cyberdesserts