Your browser has access to everything you're logged into. Now it takes orders from the pages it reads.
AI browsers give a model access to page content, open tabs, history, and signed-in connectors so it can click, fill in forms, and run multi-step tasks for the user. For thirty years the browser just displayed things. Now it acts, and it does so from inside live sessions to every system your employees use.
Enterprise browser security only watches what goes out.
That made sense when the browser only answered questions. Now that it takes action, what comes back into the page is a set of instructions running inside a signed-in session. Nothing is watching that side.
Data going out
AI use on company devices went from 15% to 45% in one year, and two thirds of it happened on personal accounts. Across 858,440 DLP events tied to generative AI uploads, source code was the data type submitted most often.
Instructions coming in
Researchers tested seven AI browsers. In four of them, an attacker could get around the same-origin policy, the rule browsers have used since 1995 to keep one site from reading another site's data. They showed it working in a proof of concept.
DLP and CASB look at files
These tools expect data to leave as an uploaded file, a sent attachment, or a synced document. Pasting text into a prompt box is none of those. Often the traffic can't be inspected either. QUIC and HTTP/3 can skip proxy inspection completely, and certificate pinning rules out decryption. Even when inspection works, it isn't detailed enough. You see which provider was contacted, but not which model, which tool calls, or what the prompt said.
Enterprise browsers lock down the container
Copy-paste limits, download controls, watermarks, and session isolation are real controls, but they're all on or off. A harmless paste gets blocked the same way a risky one does, so people find ways around them. A security tool that is the browser also has to convince people to use it, while new AI browsers come out every month. And its reach ends at the browser, so coding agents, CLI sessions, and MCP connections end up under separate policies that drift apart.
Checked inside the page, before anything is sent.
The extension sees the prompt in the page, while it's still plain text, and checks it through the local Operant Gateway that Endpoint Protector already runs on the device. It works as part of Endpoint Protector, so Endpoint Protector needs to be installed.
Enforcement works the same with QUIC, HTTP/3, certificate pinning, split tunnels, or a VPN switched off in a hotel, because the check happens before the request is built. There's no proxy to get around and no traffic to route back.
A browser prompt goes through the same classification and audit trail as a Claude Code session, a CLI agent, or an MCP tool call. You define PII once and keep one record.
Prompts are checked before they're sent, and responses are checked before they appear. That second check matters most once the browser starts acting on what it reads.
Every check ends in one of four results.
The action goes through as usual. This is almost every case, and the user never notices.
Restricted content is swapped out and the cleaned version is sent instead. The user still gets an answer, and the account number never reaches the model.
The action stops, the page explains why, and the prompt stays there so the user can edit it. Attachments and downloads that would need cleaning are blocked instead of changed. Quietly editing a file without the user knowing would be worse than stopping and saying so.
The check is still running.
Chrome, Edge, Brave, and Firefox cover most managed fleets. Nearly all of the new AI browsers are built on Chromium too
ChatGPT, Claude, Gemini, Microsoft Copilot, and more, all through one extension instead of a separate integration for each vendor
Roll it out with Microsoft Intune, Jamf, or similar tools on Windows, macOS, and Linux
It fails closed, and we tell you that from the start