Skip to main content
The SDK sees agents you wrote. The Gateway sees calls routed through it. The egress node sees workloads on your network. None of them see the analyst who pastes a customer list into chatgpt.com on their laptop, which is the most common way company data reaches a model. The extension closes that, at the smallest size that answers the question.

What it collects

That is the complete list. There is no code path that reads a page title, a URL path, a form value, or a character of anybody’s message and sends it anywhere, and the API rejects a request carrying more than the above before it reaches any service. The extension registers listeners for the AI sites in its config and no others. Browsing outside that list isn’t filtered out after the fact — the browser never delivers those events to it.

Two rungs

Discovery is on once a browser enrols. It counts which AI sites are used and by whom, and answers “is anyone using AI here, and how much” without reading anything. Detection is off for every workspace until an admin turns it on under Connect → Browsers. It scans what is typed into those sites for the same PII kinds the SDK detects, using the same engine, and reports the kinds and counts. The scan runs in the browser; the text is discarded there. Counting site visits and scanning what someone types are different conversations to have with an employee even though neither sends text anywhere. Detection is a deliberate act with an audit row against a named admin, never a default, and the extension’s own popup says which rung is running so anyone can check.

What it does not do

It watches. It does not block, and every audit row it writes carries enforcement_status = "advisory" for exactly that reason. A row saying block that never stopped anything is worse than no row. Blocking a paste is technically possible and deliberately absent. An extension that can stop what you type into a page is a different security review and a different failure mode when it gets it wrong.

Deploying it

Fleet deployment is a managed policy — force-install the extension and push its settings, so nobody on the fleet sees a setup screen.
  1. Mint an enrollment token under Connect → Browsers. It is shown once.
  2. Push the policy. Chrome, Edge, and every MDM that speaks Chrome policy use the same shape:
personEmail is optional. Leave it out and browsers are counted without a name attached — still useful, and the right choice where per-person attribution needs its own legal basis.

Detection uses one engine, everywhere

Detection is @egisai/pii-core, the same engine the TypeScript SDK uses, pinned to the shared conformance corpus alongside the Python SDK’s regex tier. An SSN that Python catches in an agent and the browser missed on chatgpt.com would be a coverage hole nobody could see, so there is one detector and every surface calls it.

Revoking

Revoking an enrollment token stops every browser using it at its next call — requests start failing and the extension goes dormant. Devices stay listed, deliberately: an admin who just revoked a leaked token needs to see which browsers were using it, not an empty page.

Failure posture

Fail quiet. If the control plane is unreachable, visits accumulate locally and go out when it returns; nothing is dropped until the server acknowledges it. If the token is rejected, the extension goes dormant and says so in its popup. Nothing it does can make a page slower to load or a message fail to send.

What’s next

Coverage

Where this fits among the five surfaces.

Egress node

The same idea for workloads on your network.