Guardrails and AI Safety
Data Leakage Prevention — Stack
Data leakage prevention › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Nothing here works without two inputs the detector itself cannot supply: a label on the content and an entitlement for the recipient. Evaluate components on whether they can accept both.
- Recipient awareness. Whether a rule can reference who is receiving, or only what is being sent.
- Label intake and propagation. Whether classifications from the source system can be carried into the check, and whether derived text keeps them.
- Egress coverage. How many of your outbound paths one component can actually sit on: responses, tool arguments, webhooks, exports, logs, attachments.
- Detection beyond signatures. Whether it can flag high-entropy strings, encoded blobs, and volume anomalies, not just known formats.
- Decision latency on the serving path. A check that is affordable on a nightly export is not necessarily affordable before every response.
- Tenant-boundary enforcement. Whether isolation can be expressed as a hard filter in the retrieval layer rather than as a predicate a query is expected to include.
- Evidence for an investigation. Whether a finding records the content, the source, the recipient, and the path, which is the minimum an incident review needs.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Classification at ingestion, carried as metadata | Making sensitivity a property of the record rather than something re-derived from text every time | Only as good as the labelling; unlabelled legacy corpora stay unlabelled, and derived text loses the label unless propagation is explicit |
| Enterprise data-loss-prevention platforms (Microsoft Purview, Google Cloud Sensitive Data Protection and comparable suites) | Organisations that already classify documents and want the same policy applied to a new channel | Built for files and mail; conversational text and tool arguments are an awkward fit, and per-call latency is rarely a design goal |
| Secret scanners (detect-secrets, TruffleHog, Gitleaks) | Credentials, tokens, and keys, where entropy and format give near-exact detection | A narrow class; finds nothing about business-confidential prose, which is most of the risk |
| Egress proxies with destination allowlists | Bounding where an agent can send anything at all, independent of what the content is | Blunt: blocks a legitimate new integration as readily as an exfiltration attempt, and generates steady exception pressure |
| Retrieval-layer filters bound to the request identity | Preventing the disclosure before it is ever in the context, which is the only fully reliable point | Requires every index and every store to support the same filter; the one that does not is where the crossing happens |
| Observability redaction and export control (OpenTelemetry collector processors, log scrubbing, sampling policy) | Keeping traces useful without creating a second, less-governed copy of production data | Runs outside the application, so direct exporters, crash dumps, and vendor agents bypass it |
| Canary records seeded through the corpus | Measuring whether anything leaks, rather than asserting that nothing does | Detects only after the fact; a canary that never appears proves nothing about the paths it was never placed on |
| Per-tenant physical isolation (separate indexes, separate keys, separate stores) | Products where a cross-tenant disclosure is existential | Operational cost scales with tenant count, and shared components — caches, queues, embeddings — tend to be forgotten |