Catch the six outputs that leaked, not 200
Your agent pasted a key into a reply. The DLP rule flagged two hundred other things
Agents echo whatever a tool result hands them: an API key, a customer record, the system prompt itself. Regex DLP flags every email address and every long token in a code block, so the queue is ignored and the real leaks ship. Leak calibrates on your own outputs and corrects across the batch, so the queue is six items long.
The problem
The review queue is full of email addresses, so nobody sees the key
A support agent quotes the customer's own address in half its replies. A coding agent pastes hashes, URLs and container names all day. Every one of those trips a regex rule, and after a week the security reviewer has learned that the leak channel is noise. The AWS key that came back in a tool result on Thursday sat in that same channel, ranked by nothing, between an order number and a docs link.
The insight
Whether an output is a leak is a question about your other outputs
A long token is suspicious in a support reply and ordinary in a code answer. An email address is a leak when there are five of them and a courtesy when there is one. No fixed rule knows that, but four hundred of your own prior outputs do: score every output with independent detectors, ask how often a normal output scores that high, and correct the resulting p-values across the whole batch so that scanning five hundred outputs does not manufacture twenty-five false alarms. The corpus has to contain the awkward legitimate cases, or every awkward output reads as a leak.
Eight weighted detectors (key prefixes and entropy, SSN, Luhn-checked card numbers, email lists, phones, private hosts, system-prompt shingle overlap, customer identifiers) produce a score; an empirical p-value against a first-party benign corpus, floored at 1/(n+1), is corrected across the batch with Benjamini-Hochberg at q < 0.05.
How it works
Four steps, no data science team
Leak scores a few hundred of your agent's prior outputs. That corpus, awkward cases included, is what "normal" means for this agent.
Independent detectors, each with a weight, each counting what it found. A hash in a code block scores nothing; a key with a private host next to it scores extra.
Empirical p-values against the corpus, then BH across the day. What survives is the queue. What did not survive is listed too, so the reviewer can see what was suppressed and why.
Block the output before it leaves, or route it to a human, per detector. The queue is short enough that someone reads it.
Who it is for
The engineer who owns the agent, and the security reviewer who asked
Teams running agents that read tool results and write to customers or code. Usually after the first near miss, usually because a security reviewer asked what the DLP rule actually catches.
Pricing
- –Eight detectors
- –First-party calibration
- –Daily review queue
- –Inline gate
- –Per-detector routing
- –Suppression audit
- –Slack review queue
- –Self-hosted
- –Custom identifier patterns
- –SSO and SCIM
- –Export to your SIEM
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Nightfall, Google DLP | Detect sensitive data in documents and messages with trained classifiers. | Built for humans pasting into Slack, not for an agent that quotes a tool result. No notion of what this agent normally says, and no correction across the day's volume, so the queue is still long. |
| Lakera, Prompt Security output guardrails | Inline guardrails that block model outputs matching a policy. | Policy is per-pattern and uncalibrated. They will block the docs URL and the customer's own email address as readily as the key, and the team turns the guardrail down until it blocks nothing. |
| NeMo Guardrails and framework filters | Programmable rails inside the agent framework. | You write the regex yourself. The false-positive problem is now your problem, and there is no calibration corpus and no multiple-testing correction in the box. |
| Regex in middleware | What almost everyone does today. | Flags any email, any long token, any nine-digit number. The queue is ignored inside a week, and the real leak ships in the middle of it. |
The obvious builders are the guardrail vendors, who already sit inline and could add calibration in a sprint if a customer asked. The defensible part is the calibration discipline, not the detectors, and calibration on a corpus the customer provides is a support burden: a corpus too small can never flag anything, a corpus with no awkward cases flags everything, and both failures look like the product is broken. The detectors assume a leak is textually visible; a paraphrased customer record or a secret spelled out in words is invisible to them. And the empirical p treats past outputs as exchangeable with today's, which a prompt change breaks until the corpus is refreshed.
Market
Priced against the DLP budget that already exists, applied to a channel it does not cover
Every team with an agent that reads tool results and writes outward is a candidate, and the near miss is the forcing event. Two thousand teams at the Team tier is $14M ARR; the Scale tier is priced against the incident report.