Stop the paste that should not have happened
A production connection string in a debugging question, a customer list attached to a summarise request, proprietary source in a chat window. The only place to catch any of it is on the device, while the request is still unsent.
The problem
Nobody leaks data through an AI tool on purpose. They paste a config to ask why a service will not start, attach a spreadsheet to get a summary, or drop in a stack trace that happens to carry a token. The intent is ordinary work and the content is whatever the work required.
Classic DLP was built for other channels: mail, file shares, removable media. An AI request is an interactive TLS session to a trusted domain carrying content that was typed or pasted rather than attached, which is precisely the shape those controls were not built to inspect.
And there is a deadline. A control can rewrite or refuse a request only while the bytes are still on the device. After that every product in the world is alerting, because none of them can un-send a prompt.
What a guardrail actually is
- 01
A condition
A detector that runs against the content of the request: secret packs for provider tokens and keys, regular expressions for the formats you care about, keyword dictionaries for project names and internal terms.
- 02
An action
Block refuses the request. Mask removes the sensitive span and lets the rest through, which is the action people accept, because the question still gets answered. Alert records the finding and stays out of the way.
- 03
A mode
Every rule runs in monitor mode first, so you learn its false positive rate on your own traffic before it can refuse anything. This is detection engineering, not a switch to flip on day one.
- 04
A destination
Findings go to Slack, PagerDuty, Datadog or a webhook of your own. Alert bodies carry metadata only: user, device, policy, action taken, severity, and a link back. The captured content is never in the message.
What you get
Enforcement before the send
On endpoints in the deep-capture set, the request is buffered and evaluated on the device. A block is a request that never left. A mask is a request that left without the secret in it.
A finding worth investigating
Every decision lands on a timeline: which device, which tool, which rule, what action, when. That is the difference between knowing a key leaked and knowing where it left from.
One policy across tools
Rules are written once and applied across the AI tools you have onboarded, instead of per-vendor toggles in a dozen admin consoles that each mean something slightly different.
A kill switch when it matters
One click blocks all AI traffic from a device, catalog included, until you release it. It takes effect within a heartbeat, and a laptop that is offline isolates the moment it reconnects.
What it does not do today
- Enforcement happens on the prompt surface, on endpoints we deeply capture. Today that means Anthropic's endpoints; the set grows vendor by vendor.
- Other planes are monitor-only by physics. Tool inputs are emitted mid-stream by the model and OTLP telemetry arrives after the fact, so those surfaces are recorded and alerted on rather than blocked. The product says so in the interface, not only here.
- Certificate-pinned applications cannot be inspected by anyone. They are counted, not read.
- Isolation is an AI kill switch, not network isolation. It stops AI traffic within about a minute; taking a machine off the network entirely is EDR territory and out of scope.
Frequently asked questions
- Can you block a paste into ChatGPT?
- Blocking requires the request content, which requires the endpoint to be in the deep-capture set. Today that is Anthropic's endpoints, so ChatGPT is discovered and recorded at the domain level rather than enforced. The deep-capture set grows vendor by vendor, and the interface always says which tier a tool is in.
- Is masking safe to turn on?
- It is the least disruptive action available, because the request still goes through with the sensitive span removed rather than being refused. Start it in monitor mode anyway: a rule that has never been measured against your own traffic is a guess.
- Do alerts contain the leaked content?
- No, by design. Alert bodies are metadata only: user, device, policy, action taken, severity and a link back into the timeline. Whoever is in that Slack channel does not need to see the secret in order to act on it.
- What stops someone turning the sensor off?
- It installs through your MDM at the system level, and the transparent proxy sits at the socket layer rather than behind a proxy setting a user can unset. A device that stops reporting is itself a finding.
Keep reading
- AI governance and audit The decision log that turns a rule into evidence.
- Guardrail, defined Condition, action and mode, and why the word gets used loosely elsewhere.
- AI App Risk Directory What leaks through each tool, and the guardrail that covers it.
See it on your own fleet.
One sensor, deployed through your MDM, showing every AI tool in use and what is leaving the device.