The browser security model is one of the most carefully thought-through pieces of software engineering on the planet. Same-origin policy. User gesture requirements. Click-to-permission grants. Site isolation at the process level. Cookie partitioning. Cross-origin resource sharing. Each of these mechanisms exists because somebody, twenty or fifteen or eight years ago, traced through a specific class of attack and shipped the structural change that made it stop working. The mechanisms compose. The composition has been load-bearing for the trustworthiness of the open web.
The mechanisms also share, almost without exception, a load-bearing assumption: the entity at the keyboard is the user, and the user is a human, and the user's intent is the principal the security model is protecting. When a webpage tries to access the camera, the browser shows a permission dialog because the user's clicking through the dialog is the authorising act. When a script tries to make a cross-origin POST, the browser blocks it because the user did not navigate the source page expecting to authorise that POST. When an onclick handler tries to open a popup, modern browsers require the click to have been a real user gesture because programmatic clicks shouldn't generate the same authorisation as a user's intentional click.
The agent-driving-browser product family launched between October 2024 and mid-2025 is asking the browser security model to keep doing all of those things, intact, while replacing the entity at the keyboard with a large language model.
The math on that does not work, and I want to walk through specifically where it breaks, what's already shipping, what the W3C's WebMCP proposal is trying to fix, and where the next class of public incidents is going to come from.
What's actually shipping
The four products worth tracking through this argument span eighteen months and share roughly the same architectural shape: a model that takes screenshots of a real browser, reasons about what's on screen, and emits keyboard and mouse actions back into that browser. The products differ in detail; the structural question they all face is the same one.
Anthropic Computer Use (October 22, 2024) was the first. Claude 3.5 Sonnet got beta access to a tool API that let it move a mouse, click, type, and take screenshots inside a developer-supplied virtual machine. Anthropic shipped it with an explicit warning in the documentation: "in some circumstances, Claude will follow commands found in content even if it conflicts with the user's instructions. For example, Claude instructions on webpages or contained in images may override instructions or cause Claude to make mistakes." The launch documentation recommends not letting Claude touch sensitive data during the research preview. The vulnerability the warning describes is the structural problem this whole article is about, named in clear terms by the company shipping the product on day one.
Google's Project Mariner (December 2024) was Google DeepMind's research-prototype shape of the same idea. Built on Gemini 2.0, distributed initially as an experimental Chrome extension to trusted testers, scoring 83.5% on WebVoyager. By May 2025 Google had moved it to Google AI Ultra subscribers in the US and was integrating it into the Gemini API.
OpenAI Operator (January 23, 2025) was the first commercial product in the family aimed at end users. Powered by the Computer-Using Agent (CUA) model — GPT-4o vision plus reinforcement-learning-trained reasoning — Operator runs in its own browser at operator.chatgpt.com and handles repetitive tasks: form-filling, grocery ordering, meme generation. OpenAI's own framing in the launch post is that "on particularly sensitive websites, such as email, Operator requires active user supervision, ensuring users can directly catch and address any potential mistakes the model might make." That sentence is doing work the rest of the article is going to push against.
Perplexity Comet (July 9, 2025 on macOS / Windows; October 2025 free; Android November 2025; iOS March 2026) is the most ambitious of the four — not an agent that drives a browser but a browser whose default mode is agentic. Built on Chromium, Comet integrates Perplexity's assistant directly into the browser interface. Users give high-level commands ("book a flight," "find a summary of this video") and the agent visits sites, extracts information, and performs actions across tabs. Voice interface is supported. The browser holds the user's session cookies, the user's saved logins, the user's tab state — and acts on them via natural language.
The four products together describe a clear arc: from a developer-only research preview (Computer Use) to a trusted-testers Chrome extension (Mariner) to a paid commercial product (Operator) to a free consumer browser (Comet). The arc compressed itself into eighteen months. The security model the products are running on is the same browser security model that existed before the arc started.
Where the security model breaks
The browser security mechanisms each have a specific failure mode under agent control. Worth taking them in turn.
Same-origin policy. SOP is the rule that JavaScript loaded from https://attacker.com cannot read content from https://bank.com, because the user's session-cookies and authentication tokens for bank.com belong to the user's relationship with bank.com, not to whatever site is currently scripting. SOP fails in spirit under agent control even though the technical mechanism keeps working. The agent has access to all open tabs, including bank.com. The agent's instructions can come from any rendered content, including an image's alt-text on a page from attacker.com. The agent reads the alt-text, follows the instruction, switches tabs, and does the cross-origin action that SOP was designed to prevent. The technical SOP rule didn't fail. The agent never made a cross-origin fetch from JavaScript. It just acted as the user on a different origin, after reading instructions from the first one. SOP protects the JavaScript-execution model; it doesn't protect the agent-instruction-execution model.
User gesture requirements. Modern browsers require a real user click before they grant permissions for camera, microphone, fullscreen, popups, autoplay-with-sound. The protection is that programmatic clicks don't count: a script can't el.click() its way into the camera. Agents emit clicks through the operating system's input-event interface, which the browser cannot distinguish from real human clicks. Mariner's tools.click() API and Operator's CUA-issued mouse events look identical to the browser. The user-gesture check is a check on whether a click happened, not on who issued the click.
Click-to-permission grants. The first time a site asks for a permission, the user sees a dialog and consents (or doesn't) explicitly. Subsequent visits inherit the consent. Under agent control, the dialog shows up while the agent is operating, and the agent (having been given a goal that requires the permission) clicks through. The user's earlier consent applied to this site, given by me, expecting these consequences; the agent's click-through applies to whatever this site asks for, given by an entity I'm delegating goals to. The two acts produce the same browser-state transition. The semantics are different.
| Mechanism | What it protects against (human user at keyboard) | What it protects against (agent at keyboard) |
|---|---|---|
| Same-origin policy | Cross-origin script reading authenticated content from another site | Nothing — the agent acts at the application layer with full session cookies for every open tab |
| User gesture requirements | Programmatic clicks invoking sensitive APIs the user didn't intend | Nothing — agent-issued OS-level clicks are indistinguishable from user clicks |
| Click-to-permission grants | Sites silently acquiring camera/mic/notification permissions | Limited — agent will click through dialogs that appear in pursuit of its assigned goal, regardless of the user's actual scoping intent |
| Cookie / session isolation | Cross-site session-cookie theft | Limited — the agent already holds the cookies and crosses sites by navigating, not by JavaScript |
| Site isolation (process-level) | Cross-origin Spectre-style memory attacks | Unchanged — protection is below the agent layer |
The pattern is uncomfortable to read but is what the actual mechanism analysis produces. The browser's defences are calibrated against attacks that route through the JavaScript layer, with the user as the trusted principal. The agent operates at a layer above the JavaScript model, with the agent itself as the principal, and the agent will execute instructions that arrived in content, not in user input.
The vulnerabilities that already shipped
Two of the four products have public vulnerability disclosures that demonstrate exactly this failure mode in production. Both involve Perplexity Comet, the most aggressive of the four.
In August 2025, Brave's research team disclosed that Comet was vulnerable to indirect prompt injection through webpage content. An attacker who controls a webpage the user visits can inject text that the agent reads as instructions and acts on with the user's authenticated privileges. Brave's framing is the load-bearing one. From the disclosure: "The AI operates with the user's full privileges across authenticated sessions, providing potential access to banking accounts, corporate systems, private emails, cloud storage, and other services." And: "When an AI assistant follows malicious instructions from untrusted webpage content, traditional protections such as same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless." Two months later, in October 2025, Brave disclosed a second variant where the prompt injection is hidden in screenshot images: text the underlying vision model can read but that doesn't render visibly to a human, allowing the malicious instructions to be smuggled past any human-in-the-loop review.
In November 2025, SquareX disclosed that Comet ships with two built-in browser extensions, Comet Analytics and Comet Agentic, that don't appear in the browser's extensions panel and cannot be disabled by users. The extensions communicate with Comet's MCP API in ways that allow attackers who can reach the API to issue system-level commands. The vulnerability is structurally distinct from the Brave finding: it's about the protocol surface the browser exposes for the agent's own operation, rather than about content the agent reads from the open web. The two together describe the security boundary of an agentic browser: the agent reads untrusted content from one side, exposes a privileged API surface on the other side, and both sides have already been turned into attack vectors in shipping products.
These are not theoretical concerns. Comet is downloadable for free, has been since October 2025, and the disclosed vulnerabilities affect every user. The vendor's fix-cycle on each is the public-record version of how seriously the agentic-browser category is taking these issues, which is to say not very.
What WebMCP is, and what it isn't trying to do
The W3C's WebMCP specification, accepted as a deliverable by the Web Machine Learning Community Group in the September 25, 2025 charter update and shipping behind a flag in Chrome 146 Canary as of early 2026, is the most serious attempt at a structural fix. WebMCP's idea is that websites should declare their capabilities to agents through a structured browser-native API — navigator.modelContext — rather than have agents scrape HTML and click DOM elements. A site exposes its tools (book_flight, add_to_cart, etc.) with explicit schemas; the agent invokes them through the formal API rather than by clicking; the browser brokers the relationship.
The security mechanisms WebMCP proposes are honest about the problem they're trying to solve. Domain-level isolation scopes tools to specific origins, so a tool exposed by bank.com can't be invoked while the agent is operating in attacker.com's context. requestUserInteraction() is the API by which a tool can pause execution and prompt for explicit user confirmation before sensitive operations. Per-invocation consent is the default for anything the spec marks as sensitive. The W3C reviewers explicitly flagged the deadly triad: an agent with simultaneous access to multiple authenticated tabs (email + bank + cloud-storage) is structurally dangerous, and WebMCP's domain isolation and consent flows are aimed at that scenario.
The thing WebMCP doesn't fix, and the thing that I think the spec's authors would acknowledge if asked, is the original problem: the agent's instructions can come from content. WebMCP makes the invocation path safer; it doesn't make the decision-to-invoke path safer. If a webpage's text instructs the agent to invoke a tool, and the agent has been authenticated to invoke that tool, the agent will invoke the tool. The requestUserInteraction() confirmation is the last line of defence, and it's the same confirmation the user would have clicked through if the agent had asked them. The treadmill is structural: if every sensitive action requires confirmation, the agent isn't an agent (it's a slow click-bot the user is supervising); if not, the security model has no signal about whether the action is what the user wanted.
WebMCP is a real improvement on screenshot-and-click. It's not the answer to the underlying question. It's a better surface for the agent to act through, with the same fundamental ambiguity about who the principal is.
Where the next incidents will come from
Reading the four products + WebMCP + the two Comet disclosures together, the predictable shape of the next year's worth of public incidents is this:
Cross-site action-laundering through agent context. An attacker controls page A. The user, in agent mode, visits page A. Page A includes content (text, alt-text, image OCR-target) that instructs the agent to navigate to page B and perform an action there using the user's authentication. The action happens. The vulnerability is "discovered" by a security researcher and reported on; the vendor patches the specific instruction-recognition pattern; the structural problem is unchanged. This pattern is likely to repeat across the four major products through 2026 — both Brave (August and October 2025) and SquareX (November 2025) have already produced disclosures in this category within a four-month window.
Hidden-MCP-tool exposure. SquareX's Comet finding is the first public instance of agentic-browser MCP surfaces being abused. It will not be the last. Every vendor shipping an agentic browser is shipping an MCP-style tool surface; every such surface is an attack target; the attack surface is novel enough that the standard browser-extension review processes do not catch the issues.
Permission-grant decay. Sites that previously had to convince users to grant permissions can now convince agents instead, by structuring the request to be agent-friendly. The user's initial I consent to camera access on this site dialog produced a stable user-site relationship; the agent decided to consent on the user's behalf to whatever the site asked for dialog produces a stable agent-site relationship that the user may not have intended to delegate. The dynamics are asymmetric in the agent's favour.
Auth-token reachability. Browsers store OAuth tokens, session cookies, password-manager state, autofill data. The agent has read access to all of it through the page DOM, the browser's autofill API, and (for products like Comet) the integrated password manager. A prompt-injection that successfully persuades the agent to navigate to its own session-token export endpoint is in scope for any of the four products. The mitigation is that browsers don't expose session-token export endpoints; the workaround is that agents can construct the export by visiting account-settings pages and reading what's displayed.
The honest reading of the situation is that the agentic-browser category shipped before its security model was complete, and the structural mismatch between the browser's protections and the agent's principal-substitution is going to produce a steady stream of incidents until either (a) the products restrict themselves to genuinely-non-sensitive tasks, (b) the protocol layer (WebMCP and successors) develops mechanisms for authenticating the source of the agent's instructions, or (c) the security community develops anti-prompt-injection tools that work reliably against adversarial content. None of (a), (b), or (c) is on a near-term ship schedule. The products are.
What I'd want before deploying any of these in earnest
The pattern that I'd want to see from any of the four agentic-browser vendors before treating them as production-safe for sensitive workflows:
- Provenance on agent instructions. Every action the agent takes should be traceable to a specific instruction source — the user's prompt, a webpage content fragment, a tool-result. Right now this is hand-waved.
- A meaningful confirmation step that distinguishes content-instructed from user-instructed actions. If the agent's plan to invoke a tool came from user-typed text, the confirmation can be light. If it came from page content, the confirmation should be heavy. This distinction does not exist in the products today.
- A read-only mode that's actually read-only. Not "read-only with permission to navigate," not "read-only with permission to fill forms" — read-only meaning the agent can look, summarise, and explain, but cannot type, click, or POST anything until the user explicitly opts each action into a write-mode. The current products conflate read and write at the lowest level.
- A way for the user to audit what credentials the agent had access to during a session. The Comet integrated-password-manager case is the canonical example: the user delegated browsing, but they probably didn't intend to delegate credential access — and the products don't currently surface that distinction.
None of these is exotic. Each is a piece of provenance / consent / scope hygiene the rest of the application-security industry has had for a decade. The agentic-browser category is shipping without them because the demos work without them and the incidents that will follow haven't accumulated yet.
The browser shipped a security model for humans because that was the actor it was protecting. The category trying to replace the actor is the one that has to update the model — and it's the category currently asking the browser to keep doing its job intact while quietly substituting the principal underneath. That's the part of the architecture that's going to give in 2026, not because the browser has anything wrong with it, but because the browser was never asked the question the agentic stack is now answering on its behalf.
Top comments (2)
The SOP table is the cleanest framing of this gap I've seen. Two things from working on browser-mediated agent runtimes (disclosure: I work on Armorer Labs, where we maintain Armorer Guard for this problem class):
1) Instruction provenance is the missing primitive. SOP protects the JS execution model but assumes the entity reading instructions is the user. Treating anything rendered to the agent's context (alt-text, page text, tool output) as a separate trust tier than user-issued instructions is the same boundary WebMCP is trying to express in HTTP — enforced at the runtime layer so a payload on attacker.com can't promote itself to "act on bank.com" because it's never in the user-trust tier.
2) Click-to-permission inheritance is the worst row in your table because the user's earlier consent was scoped to a human-authored action. Per-session permission re-prompts when the principal is the agent (not the user) match the actual semantics.
Curious whether WebMCP's tool/origin tagging can land fast enough that runtime-layer fixes are temporary, or if we'll be patching browser trust assumptions in userland for the next several years.
This is a clean way to frame it — the load-bearing assumption isn't only "the principal is human," it's that the authorizing act is external and non-forgeable by the code being authorized. A script can't synthesize a real user gesture or self-grant a camera permission; the gate lives somewhere the script can't reach. That non-forgeability, more than the human-ness, is what's actually carrying the weight.
The agent-driving-browser family breaks it from the principal side, which is the case you walk through. There's an adjacent break on the reporting side with the same root: even when an action is legitimately authorized, the surrounding workflow usually trusts the model's narration that the action occurred and succeeded. Same structural flaw — trusting an entity's account of its own actions — but it surfaces as "the step never actually happened" or "it happened, but its assumptions weren't validated before the next step built on them," rather than as an unauthorized action.
So the fix on both sides rhymes: the check has to live where the agent can't edit or narrate around it. Branch protection is a good example precisely because the agent cannot rewrite the rule it's being held to. My worry about WebMCP (and structured agent affordances generally) is that they can re-import the single-principal assumption one layer up — a cleaner channel for the model to act through is still a channel whose authorizing and reporting acts the model can influence, unless the gate is genuinely out-of-band.