Browser Sensor

Why the browser is its own surface

An endpoint agent reads what is installed. It cannot see the employee who never installs anything and simply opens a tab, signs into a consumer AI account, and pastes a production database URL into a chat window. That is not a fringe case: it is how most of an organization uses AI.

A consumer account signed into an AI site sits outside your identity provider, outside your data processing agreement, outside your retention policy, and outside offboarding. You cannot revoke what you never issued, and until it is recorded somewhere you cannot even name it.

The Browser Sensor is a managed Chrome and Edge extension that closes that gap. It is force-installed by browser policy from the Google Admin console, Microsoft Intune, or on-prem group policy, and it reports into the same console, the same findings queue, and the same audit trail as the Endpoint Sensor.

What it records

The sensor instruments the AI web services your people actually use and reports what happened on them. Everything below lands in the console as a searchable inventory, and anything that breaks policy becomes a finding with a severity.

• AI site use across 311 classified AI web services in seven categories, from consumer assistants and coding assistants to app builders, media generation, agent platforms, and meeting notetakers such as Otter, Fireflies, Fathom, and Gong, which hold recordings of your internal conversations
• The account signed into each service, classified five ways: enterprise, corporate, external, personal, or unknown. Both personal and external count as ungoverned, because an account on another company's tenant is no more yours than a consumer webmail address
• Sign-in and account-switch events, written to the audit trail as they happen, so a switch to a personal account mid-shift is a timestamped record rather than an inference
• Secrets and personal data entered into an AI site, whether pasted or typed. 162 credential formats and 13 personal and financial detectors with real checksum validation, covering payment cards by Luhn, IBAN by mod-97, national identity numbers, and SWIFT and BIC codes, plus your own dictionary of customer and project names
• Files uploaded to AI services, by name, size, and type, with an on-device content check
• Every extension installed in the managed browser, with its permissions, host access, and install method, and the AI ones called out

Typed, not just pasted

Detecting a pasted credential is the easy half. A developer who knows a paste is watched will retype the key by hand, and a control that only hooks the clipboard sees nothing.

The Browser Sensor evaluates typed input as well as pasted input, against the same pattern set, and records which of the two it was. That distinction is worth reading: a value that was typed rather than pasted tells you something about intent that a pasted one does not.

Three enforcement modes

Detection is only half the answer. Three modes let you start by watching and tighten when you are ready, with per-domain exceptions and per-device-tag scoping throughout.

In monitor mode, the default, nothing is ever blocked: every match is logged and the employee sees an in-page notice. In enforce mode the response follows severity, so a critical match is blocked, a high match is redacted in place before it reaches the page, a medium match warns, and a low match passes; uploads are blocked when the filename matches a sensitive pattern. In strict mode any match at any severity is blocked, along with any file pasted from the clipboard.

Blocking happens before the page ever sees the event. The paste is intercepted and the redacted text re-inserted, and a blocked upload is cleared from the file picker rather than cancelled afterwards, so a block never reads to the employee as a broken page. The notice they see names your organization in plain language.

Honest about what was scanned

Uploads are recorded with a content-scan status, and the status distinguishes three states rather than two. A file read on the device and checked against your patterns is reported as scanned. A binary the sensor never opened is reported as not scanned. The difference between "we looked and it was clean" and "we never looked" is exactly the difference an auditor will ask about, and collapsing the two would make the record useless at the moment it matters.

What the sensor never collects

The Browser Sensor is deployed to every managed browser in the company, so its collection boundary is a promise you have to be able to repeat to your works council, not a footnote.

It sends no prompt text and no model responses. No file contents beyond the first few kilobytes, and that read happens on the device, so only a pattern name leaves it. No page content, no cookies, no storage values, no browsing history outside the AI-site list, and nothing typed or pasted that did not match a pattern. Where a credential is detected, a masked fragment travels with the finding, enough for an analyst to know which key to rotate and never the value itself.

The narrowness is deliberate and it is enforced by the extension's own permissions rather than by policy alone. The sensor holds no blanket host permission and runs only on the AI services it is configured for. Of the AI-adjacent services Anomity can classify, a large share are recognised and counted but never instrumented, including Gmail, Slack, Salesforce, Atlassian, and Figma. Running a content script across the tools your people live in all day is a different product, and a different conversation with your employees.

Policies you can turn on

Browser findings use the same policy engine, the same severity model, and the same open to acknowledged to resolved workflow as everything else Anomity raises. Four browser policies ship disabled, ready to enable and scope to the device tags that matter.

• Personal account signed into an AI site
• Unapproved AI site visited
• Credential pasted or typed into an AI service
• Sensitive file uploaded to an AI service

Deploying it

The sensor is force-installed by extension ID through the browser management console you already use: the Google Admin console, Microsoft Intune, on-prem group policy, or macOS configuration profiles. It carries a small managed configuration that enrolls it against your tenant, and it pairs itself to the workstation it runs on so browser findings line up with the machine's endpoint inventory.

For a pilot, or for a single machine you want to try it on first, a time-limited connect code enrolls one browser without putting your organization enrollment token into a policy payload.

See the documentation for the deployment steps, or book a demo and we will roll it out to a handful of your own machines so you can see what comes back.