Every organisation trying to control AI usage arrives at the same first question: where do you put the control? We spent a while on this and landed somewhere slightly unfashionable — inside the browser, as an extension. This post is the reasoning, including the parts that argue against us.
The four obvious places, and what each one misses
A network proxy with TLS inspection
This is the reflex answer, and it works right up until the laptop leaves the building. Any prompt typed on a home network, a hotel connection, or a phone tether never traverses your proxy. Certificate pinning breaks inspection for some clients outright. And you now own a box in the critical path of every request your company makes — when it degrades, everything degrades.
For a control aimed at accidental disclosure, coverage matters more than depth. A control that covers 60% of working hours is not a 60% solution; it's a solution an employee learns to route around without even meaning to.
A CASB
CASBs work from a catalogue of known SaaS applications. That model was reasonable when the SaaS landscape changed quarterly. New AI tools appear weekly, and a meaningful share of the risk comes from tools nobody has heard of yet. A catalogue is structurally always behind, and the gap is precisely where the interesting exposure lives.
An API gateway in front of your own LLM
If your developers call an LLM through your gateway, you can inspect those calls. Genuinely useful — and completely orthogonal to the problem. The exposure is not your applications calling an API with data you already control. It's a person opening chatgpt.com and pasting in a customer list.
Endpoint DLP
Endpoint DLP understands files and clipboard events. A prompt is neither. It's free text typed into a <textarea>, often assembled over several minutes, mixing a question with pasted context. Tooling built around file fingerprints and clipboard hooks doesn't have a natural way to reason about that.
What the browser gives you
The browser is the one place that sees every web AI tool, on every network, regardless of whether anyone has approved it. That is the whole argument, and it is mostly an argument about coverage rather than sophistication.
Three properties follow from it:
Interception happens before the network request. The extension reads the prompt at the DOM, when the person hits send and before the fetch is issued. There is no window in which the data has left the machine but not yet reached the AI provider — because it never leaves.
Detection can run locally. Since we're already in the client, analysis happens in the client. No round trip, so no latency added to typing, and prompt content doesn't need to reach our servers for us to analyse it. That inverts the usual privacy tradeoff of a security tool: this one doesn't need to see your data to protect it.
Deployment uses machinery you already have. Force-install through Chrome Enterprise policy, Workspace, or Intune. No proxy to provision, no certificates to distribute, no DNS change, no new box in the request path.
The tradeoffs we're accepting
It would be dishonest to present this as free.
It covers browsers, not everything. A prompt sent from a native desktop app, an IDE plugin, or a terminal doesn't pass through a browser extension. We have a desktop agent designed for exactly this and it is parked, not shipped. If your risk is concentrated in native tooling, this is the wrong control today.
Extensions can be removed. On a managed browser you can force-install and block removal. On an unmanaged one you cannot. This is a control for a managed fleet.
Chromium only, for now. Chrome, Edge, and Brave. Firefox and Safari aren't supported.
A determined insider still wins. Someone who intends to exfiltrate can photograph a screen or use a personal phone. Nothing at this layer stops them. What it stops is the far more common case: a competent person moving quickly who doesn't register that the paragraph they just pasted contains a customer's PAN.
Why coverage beat depth
The decision came down to which failure mode we cared about.
A proxy sees less traffic but can do more with what it sees. A browser extension sees essentially all of it but is easier to circumvent by someone actively trying. If the threat model were a malicious insider, the proxy argument would be stronger. It isn't. The overwhelming majority of real AI data incidents are ordinary people being helpful and fast, with no intent to leak anything at all.
For that population, being present everywhere they work matters more than being unbypassable. So: the browser.
We wrote this decision up as an architecture decision record before writing the code, and it sits in the repository alongside the others. If your environment makes a different tradeoff correct, we'd rather you knew that from a blog post than found out after deployment.