Agentic data loss prevention

The data stays.
Only the evidence leaves.

complens.ai is a data-loss-prevention (DLP) application for the browser. A managed extension watches the moments data is about to leave — a prompt submitted to an AI assistant, a file attached to it, a copy, a print, a download — classifies each one on the device, and reports only a metadata verdict, never the content, to an administrator console. It is built and operated by Ross IT Solutions, LLC.

Your people leak data through the browser, and not only into chat. complens classifies what is about to leave — on the device, at the moment of the send, even offline. Your console receives the verdict: what kind of data, how risky, where it was going, on which machine. Never the words themselves.

On this device
draft → chatgpt.com
debug this for me, creds are AKIAIOSFODNN7EXAMPLE and it still 403s
classified locally in <1 ms aws_access_key · risk 0.92

The message text never leaves this machine. It is hashed, classified, and released or held — right here.

Across the wire
{
  "event_type": "genai_submit",
  "detectors": ["aws_access_key"],
  "risk_score": 0.92,
  "context_hash": "9f2c8e1b…",
  "app_context": "chatgpt.com",
  "action_taken": "blocked",
  "routed_to": "regex",
  "device_id": "d-4a1f"
}

That is the whole event. There is no content field to omit — the device strips everything on-device-only before a send and again before the offline retry queue, so the text is not withheld by the server's good manners. It is never handed over.

The surface

Data leaves the browser in more than one way

Most AI-security tools watch a list of chat domains. complens is active on every site, because the tools it exists to guard are not a fixed list — and because a customer list leaves just as completely through a print dialog as through a prompt. Being active is not the same as recording: on an ordinary page nothing matches, and a send that matches nothing produces no event at all.

And what is not covered, so nobody has to discover it later. Printing via Ctrl+P or the browser menu bypasses the page entirely and cannot be observed; drag-and-drop, native form submits, and synchronous or binary transports are logged only where the browser makes them readable. A partially covered surface that reads as fully covered is the failure this product exists to prevent, so we name ours.

How it works

A detection pipeline that runs where the data is

A lightweight browser extension — force-installed by your Chrome Enterprise, Intune, or GPO policy — watches the browser's exit points and classifies what passes through them with an engine that lives entirely on the endpoint.

01

Intercept at the exit

The extension hooks fetch, XHR, WebSocket and beacon sends in the page itself — before the request leaves the browser — plus the clipboard, the print path, downloads, and requests made from background workers.

02

Classify on the device

Two tiers, both local. A pattern floor catches structured secrets in microseconds; a trained classifier — a sentence embedding and a small model, in the browser, on your machine — catches sensitive prose that matches no pattern at all. Long documents are scored in windows so a single buried paragraph still registers. No network round-trip, so it works offline.

03

Report metadata only

Flagged activity produces an event: detector, risk score, SHA-256 context hash, site, device. In enforce mode, risky sends are held for the user to confirm or cancel, and the override is recorded with its justification.

If a send is benign, nothing is sent to us at all. Not a hostname, not a hash, not a counter. Ordinary browsing produces zero telemetry — an event exists only when a detector fires.

And until a browser is enrolled, it makes no request to us whatsoever. Not an event, not a policy poll, not a heartbeat. An unenrolled browser is not a device we are waiting on — it is one we have no relationship with, so it holds nothing back for later and reports nothing now. It still protects the person using it, from policy shipped in the extension itself.

Google sign-in

What we ask Google for, and why

On managed devices, the extension can verify who owns a device by asking Google to confirm the signed-in Workspace account. We request the two smallest scopes Google offers, and nothing else.