AI Agents Moved Into the Browser, Make Sure Your Governance Follows

Now agents drive the browser too

Earlier this month OpenAI released GPT-6 Astra, a computer-use model that automates tasks across browsers, spreadsheets and desktop apps and ships to every ChatGPT subscriber. Agents driving the browser is not new; an agent this good at it, in this many hands, is. It is the clearest signal yet of where AI agents are heading, and it is not where security tooling has been looking. Runtime governance for AI agents grew up on the endpoint, because that is where autonomous agents first reached enterprise scale: Claude Code, Cursor, Codex and their peers, running on developer machines with access to source code, secrets and production. That is the surface Manifold has covered from the start.

Outside engineering, the picture looks different. In the enterprises we work with, the workforce meets AI through the browser: ChatGPT, claude.ai, Gemini and Perplexity open in tabs on managed devices, often mixed up between personal and work accounts, with company data pasted straight into the conversation. Coding tools have followed them there, with Claude Code on the web and Cursor's web agents running in a tab rather than a terminal, and company data often being synced to instances in the cloud.

AI agents now also operate the browser itself. Claude in Chrome reads pages, clicks, fills forms and calls tools inside an ordinary browser session, with the employee's logged-in identity and access to every authenticated app in that profile. With Astra in every ChatGPT subscriber's hands, that pattern is about to become ordinary.

That is a large surface, sitting next to the one we already cover, and in the organisations we talk to it is largely ungoverned. We saw it coming: Manifold has been deploying browser coverage with customers over the last few months, adding surfaces as employees adopted them, and we are extending it again now. The rest of this article is how we think about the browser, and why the tools most security teams already have in place do not close the gap.

The controls you already run decide access, then stop watching

Security teams are not starting from nothing in the browser. The current toolkit looks like this:

• Enterprise browsers, meaning managed browsers deployed for the workforce, control which sites open in a corporate session, wall sessions off from each other, and can apply data loss prevention rules to what gets copied, pasted or uploaded.
• Secure web gateways, proxies and DNS filters allow or deny AI domains for the whole fleet, and inspect the traffic that passes through them.
• Extension allowlists and browser management policies decide which extensions install and which settings users can change.
• CASB and DLP tooling classifies data as it moves to sanctioned SaaS applications.

All of this does real work, and none of it should be ripped out. But each of these controls makes its decision at the moment of access: does this site load, does this extension install, does this request pass. The unit of control is the domain, the extension ID, the request. What none of them models is the AI inside the sanctioned tab: the data that moved through a conversation on an approved site, or the actions an agent took with the user's session.

Gateways are the sharpest example. A gateway funnels all of the enterprise's web traffic through one point, then tries to pick the AI sessions out of it. Even when it succeeds, the decision is made per request and ends when the page loads, so what the AI does across the rest of the session is invisible to it. Manifold's extension starts from the other end. It lives in the browser, knows which tab is talking to which AI provider, and watches only those sessions. Traffic that is not an AI session is never collected. You get visibility into the session itself rather than a verdict at the front door. We made the general version of this argument in The Gateway Gap: chokepoints evaluate requests in isolation, and agents do most of their work through channels the chokepoint never sees.

What happens when the agent drives the browser

An agent in the browser holds the user's privileges: every session the user is signed into and every internal tool reachable from that profile. The browser's own protections, same-origin policy and CORS, keep sites apart from each other. They do nothing to keep the agent apart from the user, because to the browser the agent is the user.

The agent also reads the web, and the web can talk back. A page, an email or a comment can carry text written for the agent rather than the human, and the agent can take it as instructions (OWASP calls this indirect prompt injection). Anthropic has published how often this works against its own browser agent: a 23.6% attack success rate before mitigations in the Chrome pilot and 11.2% after, then in the Claude Opus 4.8 system card, 31.5% per attempt in browser environments before safeguards and 0.5% with them.

Those numbers are the case for layered defences, and every filter in the chain earns its place, the model's own safeguards included. They also show what is left over. An agent working the browser across a large workforce reads thousands of pages a day. At 0.5% per attempt, some of those attacks succeed every day, each one running with the user's credentials inside an approved session. Filtering sets how many get through. Whether anyone finds out is a separate question, and no filter answers it.

The safety numbers also come from the labs, about their own models, measured in a test environment rather than on your fleet. Model safety is their job, and they do it. The security of the enterprise running the agent is a different job, and this summer showed how far apart the two sit. When OpenAI's own evaluation agents broke into Hugging Face's production infrastructure in July, OpenAI's monitoring missed it for about a week, and the independent review that followed was written by AI safety researchers rather than incident responders. Zack Korman asked the obvious question: since when do safety researchers run breach forensics? For your own deployment, that job is yours.

The browser incidents are already on record. An AI browser's summarise function was hijacked by instructions hidden in a Reddit comment, which walked the agent into exfiltrating the user's email address and a one-time password. Manifold's own research disclosed two bypasses in the Claude for Chrome extension that let any other extension coerce Claude into reading a victim's Gmail, Docs and Calendar.

What Manifold's browser support does

Manifold's browser support is an extension for managed Chromium-based browsers on macOS, Windows and Linux. It has been running in customer deployments for the last few months, and it runs through the same policy engine, inventory and audit pipeline as Manifold's endpoint coverage, so browser findings land in the violation model a customer already has, with no additional policy maintenance. It does two jobs.

Governing the AI employees use in tabs

Covered today: claude.ai, Claude Code on the web, Claude Cowork, ChatGPT, Gemini, Cursor and Perplexity, with more coming.

For those surfaces, the extension can:

• Block a denied prompt before it leaves the browser, and stop a denied AI site from loading.
• Require a corporate account where the organisation demands one: a rule can gate an AI site on the account someone is signed into on a managed device.
• Flag and record a policy breach as it happens. The employee sees an in-page notice naming the policy; the security team gets the violation tied to the user, the device and the conversation it came from.
• Sweep the MCP servers, skills and plugins people have wired up in the browser into the same AI bill of materials as the endpoint, where they become visible and reviewable.
• Detect from what the AI did: the tool calls it made, where data went, which capabilities it combined. Prompt capture is a deployment setting, and with it switched off, conversation content never leaves the device.

Governing the agent that drives the browser

The new part is security coverage for agents that operate the browser on an employee's behalf. Claude in Chrome was the first we covered; Replit, ChatGPT and Gemini agents followed, with more to come.

The same policies that govern an agent's tool calls on the endpoint apply to its tool calls in the browser, so a step that breaches policy is flagged and recorded the moment it happens. The same detections apply too: an agent that reads sensitive data and sends it to an external destination in one session, or that combines capabilities no legitimate task needs, surfaces as a detection rather than a line in a log. And because an agent's work is a sequence rather than a single request, Manifold rebuilds what it actually did as one auditable timeline: the prompt, each tool call, the approval decision, the result, and page-level evidence of what each action left behind, correlated by browser tab and time. Send an agent to update supplier records in an internal portal and the timeline shows which tab, which steps, which approval, and what each page looked like when it happened. When something goes wrong, that is the record you investigate from.

Deployed through MDM, with a deliberately small permission scope

IT pushes the extension to managed Chromium-based browsers through the mobile device management tools already in place; employees install nothing. Distribution is self-hosted and signed, policy arrives through the browser's managed storage, and a kill switch can turn the extension off fleet-wide. The permission ask is small on purpose: two permissions, host access limited to the AI provider domains, no browsing history, no broad web access, no remote debugging. For a security team deciding whether to trust one more extension, that narrowness is the point, and it is verifiable.

What security teams should do

1. Inventory browser AI use: which AI surfaces are in play, on which accounts, and which installed extensions have AI capability.
2. Set an account policy for AI sites on managed devices where the business requires it, and make current usage visible before blocking anything.
3. Extend your AI bill of materials to what lives in the browser: extensions, MCP servers and skills, reviewed like any other dependency.
4. Demand runtime records of AI tool use in the browser: which user, which device, which conversation, which policy.
5. For browser-driving agents, require a reconstructable timeline of what the agent did. An allow or deny verdict on the site tells you nothing once an agent is inside it.
6. Keep the enterprise browser and gateway layers that earn their place. They control access, and access control still matters. Add visibility behind them rather than replacing them.
7. Deploy browser governance through the MDM you already run, and verify any extension's permission surface before trusting it, including ours.