> ## Documentation Index
> Fetch the complete documentation index at: https://docs.egisai.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser extension

> Which AI sites your team uses at work, and optionally what kinds of sensitive data get typed into them — detected locally, reported as counts.

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

|                      |                                                        |
| -------------------- | ------------------------------------------------------ |
| Which site           | A hostname — `chatgpt.com`. Not the URL, not the path. |
| Which person         | The work email your MDM templated in, if you set one.  |
| How many             | Conversations per site per 15-minute window.           |
| What kind (optional) | `[{"type": "ssn", "count": 2}]` — counts, never text.  |

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:

```json theme={null}
{
  "ExtensionInstallForcelist": [
    "<extension-id>;https://clients2.google.com/service/update2/crx"
  ],
  "3rdparty": {
    "extensions": {
      "<extension-id>": {
        "enrollmentToken": "egis_browser_…",
        "personEmail": "${user_email}",
        "apiBase": "https://api.egisai.co"
      }
    }
  }
}
```

`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

<CardGroup cols={2}>
  <Card title="Coverage" icon="shield-check" href="/coverage/overview">
    Where this fits among the five surfaces.
  </Card>

  <Card title="Egress node" icon="server" href="/coverage/egress-node">
    The same idea for workloads on your network.
  </Card>
</CardGroup>