One sensor, and a console for what it finds
The point of knowing what leaves a device is not to ban things. It is to be able to say yes: yes to the assistant the engineering team already depends on, because you can see what goes into it and stop the one request that should not.
What it is
An endpoint agent and a console. The agent runs as a transparent proxy at the socket layer, so it sees outbound connections whichever application makes them: a browser tab, a desktop app, an IDE assistant, a command-line agent. The console is where the findings land and where policy is written.
Inspection happens on the device, and that is the design decision everything else follows from. A request can be refused or rewritten only while its bytes are still local and still unsent, so a control that sits anywhere downstream is alerting rather than preventing. Agentic endpoint security makes the longer version of that argument.
What it can see
Three fidelities, and the difference between them matters more than any single coverage number. Anyone quoting one figure for how much of your AI traffic they cover is adding these together.
Deep capture
Anthropic's endpoints (Claude Desktop, claude.ai) plus OTLP sources such as Claude Code
The request is decrypted on the device, buffered, and evaluated before it is sent. This is the only tier where a guardrail can refuse or rewrite something, because it is the only tier that holds the plaintext while the bytes are still unsent.
Recorded
Every other destination on the AI catalog: ChatGPT, Gemini, Cursor, Copilot, Perplexity and the rest
The connection is identified by process and destination, logged as device, tool, timestamp and count, then tunneled through without decryption. You learn what is in use and how much, not what was said.
Uninspected
Certificate-pinned applications
Nobody can decrypt these, and we do not pretend otherwise. They still appear at the domain level, and the console reports what share of traffic falls into this bucket rather than leaving a silent gap in a dashboard.
The deep-capture set grows vendor by vendor. Claude is the first one, not the scope.
What the console does with it
Guardrails
A condition, an action and a mode. Secret packs, regular expressions and keyword dictionaries on one side; block, mask or alert on the other. Rules run in monitor mode until you know their false positive rate on your own traffic.
Alerts where you already work
Slack, PagerDuty, Datadog, or a webhook with a body you control. Alert bodies carry metadata only, never captured content, and repeated triggers of the same rule on the same device collapse so a loop cannot flood a channel.
Device isolation
One click blocks all AI traffic from a device, catalog included, until it is released. It takes effect within a heartbeat, and an offline laptop isolates the moment it reconnects. Both actions are audit-logged.
An investigation timeline
Per device: AI events, MCP servers seen, policy findings and isolation history. Enough to answer what AI has done on this laptop without joining views together by hand.
How it gets onto a fleet
- 01
Install. A signed package, pushed through your MDM, or a one-line install command with your enrolment token baked in. Both land the same agent.
- 02
Consent. The operating system asks for the network extension and certificate trust it needs. The installer stages each prompt with plain-language copy rather than leaving a user with unexplained system dialogs.
- 03
Enrol. The device appears in the console the moment it enrols and walks its activation states through to protecting, so a stalled rollout is visible rather than assumed.
- 04
Run. A transparent proxy at the socket layer, sub-30ms on inspected requests, no browser extension and no traffic detour through a third party. Non-AI traffic is untouched.
Where the data goes
Findings and metadata go to the console. Storing the captured content itself is opt-in and its retention is configurable, because an organisation that wants the detection without the archive should be able to have exactly that. Alert bodies never carry content: whoever is in the Slack channel does not need to see the secret in order to act on it.
Deeply captured endpoints are decrypted on the device, which is the same TLS-inspection model as the EDR and DLP agents most fleets already run. Everything else on the catalog is observed by hostname and passed through encrypted, and traffic that is not AI is not touched at all.
What it does not do today
- Enforcement is on the prompt surface of deeply captured endpoints. Tool inputs are emitted mid-stream and OTLP telemetry arrives after the fact, so those planes are monitor-only by physics, and the interface says so where it matters.
- Isolation takes effect at the next heartbeat, within about a minute, not instantly. It is an AI kill switch rather than full network isolation, which stays EDR territory.
- Hosted in us-west-1 today. Storing captured content is opt-in, retention is configurable, and an Australian stack is a deployment decision we will make when a partner needs it rather than a claim we make now.
A hosted gateway, for AI and MCP traffic that never touches a managed laptop, is in development. It is not shipping, it is not in the pricing, and nothing above depends on it.
Where teams start
Three ways in, all on the same sensor: finding the AI nobody declared, stopping the paste that should not have happened, and seeing what an agent did on its own.
See it on your own fleet.
One sensor, deployed through your MDM, showing every AI tool in use and what is leaving the device.