Blocking Sensitive Customer Data From Reaching OpenAI and Third-Party LLM APIs

Sensitive customer data reaches LLM providers because of how prompts get built, not because engineers forget to scrub them. The fix is an interception layer at the gateway: redact regulated fields before the request leaves your environment, send the provider a clean prompt, then restore the real values when the response comes back. This piece explains why the exposure happens, what a redact-and-restore gateway does differently from a detect-and-block filter, and how to configure it for HIPAA, PCI DSS, and GDPR workflows without breaking the application.

Why Sensitive Data Ends Up in LLM Requests

A prompt is built from whatever data the application already has on hand. Pulling those fields out before the prompt gets assembled takes a deliberate, separate step, and most application code was never written to take that step. Sensitive fields ride along with everything else into the request body because nothing stopped them, not because anyone decided to send them.

Without something sitting between the application and the model provider, that data goes straight to a third party. None of this requires a careless developer. It only requires a prompt built the normal way, from the normal data store, with no interception step in between.

The categories at stake break into five groups: personally identifiable information such as names, emails, phone numbers, and addresses; government identifiers like SSNs; financial data including credit card numbers and IBANs; protected health information; and internal secrets such as AWS access keys, GitHub personal access tokens, and database connection strings. GDPR, HIPAA, CCPA, and PCI-DSS all impose fines when protected data reaches an unauthorized third-party processor, and a model provider counts as exactly that the moment a prompt lands in its request log.

Provider-side handling makes the exposure worse, not better. A provider's default terms do not guarantee zero data retention, so unless a team has negotiated that guarantee in writing, the assumption should run the other way.

Agentic workflows widen the exposure surface further. A single user request can now chain through multiple models, MCP servers, and tool calls, and each hop in that chain may receive the same context window carrying the same regulated fields. Every added model or tool is another place the data could be logged, cached, or mishandled.

One objection comes up often: "the provider doesn't train on API data, so there's no risk." Logging and training are separate questions, and solving one does not solve the other.

What detection-only approaches miss and why redact-and-restore changes the equation

Traditional data loss prevention tools work by detecting a sensitive pattern and blocking the request. Detect-and-block optimizes for stopping bad requests and ends up stopping good ones too. That tradeoff is why so many DLP rules get quietly disabled within a few months of rollout.

Reversible redaction solves the same problem without that cost. Before the prompt leaves the gateway, sensitive fields get swapped for placeholder tokens. The redacted prompt goes to the LLM provider. When the response comes back, the gateway swaps the real values back in before returning the answer to the application.

Picture a support ticket that reads: "Customer is requesting a refund for the charge on card ending in her credit card number, SSN included for verification. Redacted at the gateway, the provider instead sees: "Customer <PERSON_1>, SSN <SSN_1>, is requesting a refund for the charge on card ending in <CARD_1>." The model reasons about the ticket, drafts a response, and that response comes back through the gateway, where <PERSON_1> becomes the real customer name again before the support agent ever sees the output.

The mapping between the original values and their placeholder tokens stays in the gateway's session state and never leaves the environment. The provider only ever sees redacted content. The application sees a complete, coherent answer about the customer's actual data. From the application's side, the round trip is seamless, the model appears to have reasoned about the real record. From the provider's side, no sensitive value was ever received.

The structural problem with patterns alone is that they catch what has a fixed shape and miss what doesn't. Catching it reliably requires entity recognition that reads the surrounding context, not just a pattern that checks digit counts. Teams that start with pattern matching alone are making a reasonable first move, but they leave the single largest category of PII, names, locations, and dates, uncovered.

Not every field belongs in this redact-and-restore flow. AWS access keys, GitHub personal access tokens, private keys, and credit card numbers should be blocked outright, regardless of policy, because no legitimate workflow requires sending a live credential or a full card number to a model provider. Redaction serves data the model needs to reason about in some form. Credentials don't belong in a prompt.

Four Layers of the Detection Engine

Catching sensitive data reliably takes four layers working together, because each one covers ground the others miss.

The first layer is pattern matching. High-precision regex rules catch structured formats: SSNs in the XXX-XX-XXXX shape, credit card numbers, API key prefixes like sk-, ghp_, and AKIA*. Pattern matching is fast and precise, but only for data that already has a predictable shape.

The second layer is checksum validation. This step filters out the false positives that pattern matching alone would flag, a random sequence of digits that happens to look like a card number but fails the checksum gets left alone.

The third layer, and the one that does the most work, is entity recognition. Names, locations, organizations, and dates don't follow a fixed pattern the way an SSN does, so catching "John Smith" requires a model trained to recognize entities in context. At 67 milliseconds, it won't.

The fourth layer is context heuristics, reading the text around a candidate entity to settle ambiguous cases. Co-reference resolution matters here too: "Anna Petrova," "Ms. Petrova," and "Anna" should all map to the same placeholder token within one conversation, not three different ones, or the restored response will come back garbled.

An LLM-based detector can close whatever gap remains after these four layers, but it comes at a cost: hundreds of milliseconds to several seconds per document, compared to 67 milliseconds for NER. That latency puts it out of place in a live chat gateway. It belongs in batch jobs run after the fact, not in the request path of a real-time application.

Even with pattern matching, checksums, NER, and context heuristics all running together, some things still get through. These limits mean compliance teams setting residual risk tolerance should know them going in, before an audit surfaces them.

Detection has to run in both directions. On the way in, that means system messages, user messages, assistant messages, and tool-call arguments. On the way out, it means the answer text and any tool-call arguments the model generates in response. A gateway that only scans what the user typed misses the request's most dangerous surface, because agentic workflows routinely put sensitive data into tool calls and intermediate outputs that never appear in the original user message.

Choosing the right redaction mode for each data type and workflow

Once detection catches a sensitive field, the gateway has to decide what to do with it, and that decision depends on two questions: does the model need to reason about the shape of the data, and does the application need the original value restored afterward? Different fields call for different answers.

Mask mode replaces a real value with a typed placeholder token, something like <PERSON_1>, <EMAIL_1>, or <SSN_1>. The model can still tell one field type from another, so it can write "thank you for your request, <PERSON_1>" without knowing who that person actually is. The gateway tracks the mapping and restores the real value afterward. Mask mode is the default for HIPAA, PCI DSS, and GDPR workspaces, because it produces the clearest audit trail: a reviewer can see exactly which field type was touched and when.

Hash mode replaces a value with a deterministic keyed hash. Hash mode is one-way by design. It's the right choice when the application doesn't need the original value back and even a well-formatted placeholder would reveal too much about the data's shape.

Hard block refuses the request. No production workflow needs to send a live credential to a model provider, so there's no policy configuration where this should be allowed to pass through in any form.

Redaction has a measurable but limited effect on output quality. The failures that did show up had identifiable causes: a placeholder that hid a customer's gender led to a broken gendered salutation in the response, and a masked IBAN left the model unable to confirm the account number back to the user. These are exactly the kind of edge cases a team should weigh when deciding, field by field, which mode to apply.

Whatever mode gets chosen, the mapping between a real value and its placeholder lives only at the gateway. It stays in encrypted session state, never gets sent to the provider, never gets written to the audit log, and never becomes visible to the application layer. Concentrate AI handles this redaction and restoration inside its own gateway session state, rather than leaning on a provider's data retention promise or a contract clause that may or may not hold up in practice.

What the Audit Log Must Contain

A compliant audit log records that a sensitive field was detected and what the gateway did about it, nothing more. It should not contain the prompt or response itself. That distinction, logging the fact of redaction without logging the redacted content, is what lets the log satisfy an auditor without becoming a second data liability.

What belongs in the log: timestamps, session identifiers, token counts, latency figures, and policy enforcement outcomes, which entity types got detected, which mode was applied to each, whether a request was blocked. None of this requires storing a single word of the actual prompt.

What must never appear in the log: the original prompt, the redacted prompt, the provider's response, or the mapping table linking real values to their placeholder tokens. Storing any of these turns the audit log itself into a regulated data store, one that now needs its own HIPAA or GDPR controls layered on top of it, defeating the purpose of redacting.

Processing should stay stateless and in-memory, with no prompt body ever written to disk. Operational logs stay metadata-only. Policies should be versioned as immutable releases, so that if an auditor asks what rule governed a request made six months ago, the version history answers that question without referencing the prompt content from that request.

This metadata-only approach covers evidence requirements for SOC 2, GDPR, ISO 27001, NIST CSF, and CCPA without storing a single sensitive prompt. HIPAA and PCI DSS ask for more: both frameworks require logging what specific ePHI or cardholder data was accessed, which can call for controls beyond a metadata-only log. A team handling health records or payment data should treat metadata-only logging as the floor, not the complete answer.

Zero Data Retention, usually shortened to ZDR, is the provider-side complement to this gateway-side discipline. Gateway-side redaction keeps sensitive values from ever reaching the provider. ZDR governs what happens to whatever the provider does receive. The two mechanisms cover different parts of the same exposure path, and a complete program needs both.

ZDR enforcement can be set at several levels: across an entire team by default policy, per provider through configuration, or per individual request for workflows that carry unusually sensitive data. Applying it uniformly everywhere is simpler to manage but gives up flexibility. Setting it per request allows a single pipeline to mix sensitivity levels, strict ZDR enforcement on a workflow touching health records, looser rules on a workflow that never touches regulated data.

RBAC, team workspaces, and enforcing redaction policy across an organization adding AI faster than governance can track

A redaction policy that lives in one engineer's config file protects exactly one application. Per-request redaction has to scale to that reality, or it only ever covers the one team that set it up first.

Role-based access control is what makes that scaling possible. A security lead can define that PHI gets masked, credentials get blocked, and account numbers get hashed, and that policy follows every key issued under the organization, not just the ones someone remembered to configure correctly.

Team workspaces make this concrete. RBAC lets an organization set these policies independently per workspace while still enforcing a shared baseline, no workspace gets to skip the hard block on AWS keys, even if its own team never thought to add one.

Audit logs and spend controls round out the picture. A workspace-level view of usage, combined with policy enforcement outcomes logged at the metadata level described earlier, gives a security team visibility into which teams are sending what kinds of data through which models, without needing to inspect a single prompt. That visibility matters most in organizations where AI adoption is outrunning formal governance, where a new team can start calling a model provider's API within an afternoon, long before anyone from compliance has reviewed the workflow.

This is the point where a gateway's role shifts from a technical control into an organizational one. Redaction modes, audit logging, and ZDR contracts only do their job if every team's traffic actually passes through them. RBAC and shared workspace policy are what make that true at the scale of an entire company, not just the one application an engineer happened to build it for first.