LLM egress DLP
DataDam fronts agent-driven traffic to Anthropic, OpenAI, and Gemini. Every outbound prompt and every image attachment runs through an in-proxy detection pipeline before the vendor sees it. Detections fall under operator-controlled modes: warn, redact, or block. Customer data never leaves your environment to reach the vendor; the proxy attaches the vendor key on forward.
Scope honestly
Live today
Any app you control that points its LLM SDK at a base URL: your in-house agents, Cursor, Continue, Cline, custom workflows, MCP-speaking IDE clients. Set the base URL to the proxy and every prompt plus every image attachment routes through DataDam.
On the roadmap
Claude Desktop, the ChatGPT web app, gemini.google.com. These apps connect directly to their vendor and do not expose a base URL override, so a proxy cannot insert itself in the path. Coverage comes via the managed browser extension we have scoped (DataDam Endpoint) plus an MDM enterprise pack that force-installs the extension and routes consumer traffic through the same DataDam proxy and audit pipeline.
We do not pretend the agent-driven slice covers consumer-AI shadow IT. Different slices, different mechanisms, different deployment shapes. The agent-driven slice is shipped and battle-tested; the consumer extension ships once the agent slice is production-proven with design-partner pilots.
The four endpoints
The proxy mounts a forward endpoint per vendor. Agents point their SDK base URL at the proxy. Vendor body shapes (Anthropic content blocks, OpenAI Chat parts, OpenAI Responses input typed parts, Gemini contents.parts) are walked natively.
POST /llm/anthropic/v1/messages
POST /llm/openai/v1/chat/completions
POST /llm/openai/v1/responses
POST /llm/gemini/v1beta/models/{model}:generateContent
Per-request pipeline
Same shape as the data-source proxy and the MCP gateway. No new service to deploy. Latency adds the scan time (typically tens of milliseconds for text, one to three seconds for images on a CPU engine).
Step 1
Standard DataDam bearer auth, same as the data-source proxy and the MCP gateway. Per-key role, IP allowlist, and optional request signing.
Step 2
Walk every text span (system prompt, messages, tool results) and every image attachment. Text routes through built-in PII detection plus operator-authored custom rules. Images route through the detection pipeline below.
Step 3
Warn, redact, or block. Defaults are org-wide. Per-vendor overrides take precedence. Mode resolution is deterministic, no LLM in the loop.
Step 4
Warn forwards the original with an X-DataDam-LLM-Warning header. Redact substitutes detected spans inline and forwards. Block returns 403 to the agent, no upstream call.
Step 5
The vendor API key lives in your proxy host environment. The agent sends its DataDam key; the proxy attaches the vendor key on forward. The vendor never sees the DataDam key. Your audit log never sees the vendor key.
Step 6
Per-vendor lineage event with entity counts, per-engine attribution, mode, outcome, and latency. Flows to your configured SIEM sink alongside every other DataDam audit row.
Image attachments
Text scanners are common. Image scanners that operate inline at the proxy layer, with redaction back into the forwarded request, are not. Here is what gets protected on every image.
Text inside the image (the same PII categories that get redacted in prompts: emails, phone numbers, SSNs, payment cards, secrets, plus your operator-authored custom patterns). Visual threats that text extraction misses: credit cards, ID cards, faces, signatures. Operators extend the detection class list from the console.
Detected regions get black rectangles painted over them before the image is forwarded to the vendor. The agent still receives a response; the vendor still receives an image; the detected regions are gone. If encoding the redacted image ever fails, the proxy strips the image entirely and substitutes a clear sentinel so the request still parses.
Size cap
Per-image hard cap. Oversize images never decode (no decompression-bomb exposure) and the audit row records the truncation so operators can see what happened.
Deployment
Both versions ship the same coverage. The difference is whether you run on standard pods or on GPU pods.
Hardware: Runs on standard pods. No GPU required.
Best for: Default for almost every deployment. Full detection coverage. Multi-worker proxy fleets can share one detection instance to keep the footprint modest.
Hardware: Requires a CUDA-capable GPU pod.
Best for: High-volume agent workloads where latency budget is tight, or environments that already provision GPU pods. Sub-second per-image detection at typical sizes.
Operator controls
No code, no deploys, no proxy restart required for behavior changes. Settings flow to every proxy in the fleet via /sync/keys.
Warn, redact, or block. The console default is redact: detections substitute inline and the request still forwards. Block fails closed on every detection. Warn forwards unchanged with a response header. Set on /settings.
Same three modes, per Anthropic / OpenAI Chat / OpenAI Responses / Gemini. Null fields fall through to the org default. Useful when one vendor has stricter contractual rules than another.
Org-wide on/off for the OCR pipeline. Off means image parts forward untouched and the audit row stamps IMAGE_NOT_SCANNED:image_dlp_disabled_by_org so operators see the gap. Use when you do not accept images on your agents or you want to benchmark before paying for OCR memory.
Operator-authored regex patterns scoped per-vendor. Author in the console; the proxy compiles and applies them alongside the built-in detection. Examples: internal project codes, customer record IDs, anything the default detection does not know about.
Off by default. When on, the proxy applies the same per-delta detection to the vendor reply stream. Latency cost is real; per-delta detection has gaps; the request-side scan is primary defense.
Audit
The audit row carries enough structure to answer ops questions without grepping logs. Per-engine attribution means a regression in one OCR engine version is visible immediately.
piiEntityCounts
Per-recognizer counts (EMAIL_ADDRESS: 2, PHONE_NUMBER: 1, FACE: 1). Same shape as data-source masking audit.
piiEngineBreakdown
Per-detector attribution. Operators answer "which detector flagged this?" without joining external logs. Text-detector and visual-detector counts surface separately so a regression in one is visible immediately.
piiColumnsMasked
Dotted in-body paths of every detection site. messages[2].content[1] for a flagged image, messages[3].content for a flagged text part. No values, just paths.
imageDlpEnabled deferred reasons
When the OCR path is intentionally skipped (org toggle off, image too large, http URL source), the audit row records the reason in entityCounts (IMAGE_NOT_SCANNED:image_dlp_disabled_by_org, OVERSIZED_IMAGE_TRUNCATED, IMAGE_NOT_SCANNED:http_url_source_unsupported). Operators see every gap.
Audit rows flow to your configured SIEM sink alongside data-source and MCP traffic. Splunk HEC, Datadog Logs, Elasticsearch, CloudWatch Logs, and generic webhook are first-party. Append-only retention is enforced at the control plane database.
Frequently asked
What platform teams and security reviews ask before they put DataDam in front of agent traffic to Anthropic, OpenAI, and Gemini.
Anthropic Messages, OpenAI Chat Completions, OpenAI Responses, and Gemini generateContent. Streaming and non-streaming on every vendor. Add a vendor by pointing your agent SDK at the proxy base URL instead of the vendor base URL; vendor body shapes are walked natively.
Observability watches what already happened. DataDam sits inline and changes the request before the vendor sees it. PII gets redacted, custom patterns get redacted, image attachments get black rectangles painted over detected regions. No post-hoc alert about a leak that already occurred.
No, not today. Those apps connect directly to their vendor and do not expose a base URL override, so no proxy can insert itself in the path. We cover agent-driven traffic where you control the SDK (your in-house agents, Cursor, Continue, Cline, custom workflows). Coverage for Claude Desktop and the ChatGPT web app is on the roadmap via the managed browser extension (DataDam Endpoint) plus an MDM enterprise pack that routes consumer traffic through the same DataDam proxy and audit pipeline. Honest framing: this product slice covers agents, not consumer-AI shadow IT, until the extension ships.
Yes, on your proxy host. The agent presents its DataDam key; the proxy strips that and attaches your vendor key on forward. Your vendor key lives in your environment's secrets layer (env vars, AWS Secrets Manager, 1Password, HashiCorp Vault). The control plane never sees your vendor key.
Text inside the image gets the same PII detection that runs on prompts: emails, phone numbers, SSNs, payment cards, secrets, and your operator-authored custom patterns. Visual threats that text extraction misses are flagged separately: credit cards, ID cards, faces, signatures. The detection class list is operator-extensible.
The vendor still receives an image. Detected regions are painted over with black rectangles; the rest of the image passes unchanged. The agent sees a vendor response generated against the redacted image. If image encoding ever fails, the proxy strips the image entirely and substitutes a clear sentinel so the request still parses.
Yes. Per-vendor mode picks one of three: warn (forward as-is, attach a response header), redact (substitute detected spans inline before forwarding, the default), or block (return 403 to the agent, no upstream call). Set org-wide defaults and override per vendor. Mode lives on the Settings page.
Streaming is supported on every vendor. Request scanning runs before the upstream call. Response scanning is optional: when on, each streaming delta gets the same per-delta detection and forwards inline. Per-delta detection has gaps for entities that split across deltas; the request-side scan is your primary defense.
CPU version is the default and runs on standard pods. Full text and visual detection coverage. Suits almost every deployment. GPU version requires a CUDA-capable GPU pod and runs detection in a single multimodal pass with sub-second per-image latency. Pick GPU when your agent workload is image-heavy and latency budget is tight, or when you already provision GPU pods for other AI workloads.
Yes. The console supports operator-authored regex patterns scoped per-vendor. Internal project codes, customer record IDs, anything the built-in detection does not know about. Rules apply alongside the built-in detection on every request.
Per-vendor lineage event with entity counts, per-detector attribution (text vs visual), mode, outcome, and latency. The detection paths (which message, which content part) are included; the detected values themselves never are. The row flows to your configured SIEM sink alongside every other DataDam audit row.
Yes. Detection runs entirely inside the proxy host. No third-party API calls, no model weights downloaded at runtime (the container ships with weights pre-baked, or you mount them once from your own volume). The proxy reaches your configured LLM vendor over your own network egress, not ours.
Three knobs. Per-vendor mode flip to warn (forwards everything, attaches a header). Org-wide image attachment toggle on the Settings page (image scanning off, text scanning on). Or kill switch on the LLM egress endpoint entirely. All three propagate to every proxy in your fleet via /sync within five minutes.
Point your agent SDK at the proxy. Drop one image. Watch the audit row populate. The design-partner pilot runs against your real workload, not a demo dataset. Email hello@mydatadam.com and we will set up the pilot.