Does PII redaction in LLM traffic replace our DSPM or data classification program?

They cover different data states, and neither substitutes for the other. DSPM classifies documents, buckets, and repositories at rest, typically on a scan cycle measured in hours or days, and it is genuinely useful for finding where sensitive files already live and who has access to them. LLM traffic redaction evaluates the live HTTP request and response on every call, in milliseconds, before the payload reaches the model. A DSPM label on a source document does not travel into a RAG-assembled prompt, and a DSPM scan will never see a JSON argument that existed for one function call and then disappeared. Keep the DSPM program for its actual job: inventory and access hygiene on stored data. Add request-level redaction for the traffic a document scanner structurally cannot reach, sitting at the AI API call layer instead of the storage layer.

What PII classes should a first policy cover?

Start with the classes that carry the highest exposure cost and the clearest regulatory mapping: government identifiers (SSNs, national ID numbers), financial account numbers, payment card data, and any protected health information if the organization touches healthcare data at all. Add organization-specific classes next: customer account IDs, internal case numbers, anything that shows up in support tickets or CRM records that would embarrass the organization if it appeared in a model provider's logs. A policy with three or four well-defined classes and clear actions beats a policy that tries to enumerate forty categories on day one and enforces none of them consistently. Expand the taxonomy as the audit record shows which classes actually appear in production traffic, and route new classes through a named owner so the definitions stay tied to a specific regulatory or contractual reason rather than accumulating as a vague catch-all list nobody maintains.

How does mask differ from allow-with-log in practice?

Mask changes what the model sees. The gateway replaces the sensitive span with a typed placeholder before the request leaves the enterprise boundary, so the model reasons over a redacted version and the raw value never reaches the provider. Allow-with-log changes what gets recorded, not what the model receives. The raw value passes through because the workflow needs it (a customer service model that has to reference an actual account number to be useful), and the gateway writes a record of exactly what class of data was permitted, on which route, for which identity. Mask is the default for classes the model does not need to see. Allow-with-log is the exception path for classes the workflow genuinely requires, made visible for review instead of invisible by default. Review the allow-with-log list on a fixed cadence. A class that was a legitimate exception in January can turn into a policy gap by June if the workflow it supported has since changed.

Does redaction on the prompt also need to run on the model's response?

Yes, and it is a separate evaluation. Prompt-side redaction stops PII from reaching the model. Response-side redaction catches what the model sends back: a field it was given and is now repeating, a summary that includes a name from the source document, or the rarer case of a model generating an identifier that resembles a real one without having been given it. The same policy engine can run both directions, but the classification has to run twice, once on the outbound request and once on the inbound response, because the content and the risk profile differ on each side of the call. A financial services deployment might mask account numbers on the way in but still need to check the response for a hallucinated routing number that resembles a real one closely enough to cause confusion downstream. Skipping the response side leaves half the exchange unreviewed.

Who should own exceptions to a redaction policy, security or the business unit?

Security should own the mechanism and the audit trail. The business unit should propose the exception, with a specific justification tied to a workflow, not a blanket request for a team. A claims-processing workload that needs PII.Financial-Account to function is a legitimate exception. A request to disable PII checks for "the whole analytics org" is a policy failure waiting to be discovered during an audit. The exception should attach to the role making the API call and the specific data class involved, get a documented business reason, and go through the same review cadence as any other access grant. Security enforces it at the request layer regardless of who approved it. The business unit brings the reason a workflow needs the data. Security's job is bounding that need to the smallest scope the workflow can still run on.

Does this apply to internal employees, or only to external-facing AI features?

Both, and the internal case is usually the larger blind spot. External-facing AI features get security review because they ship to customers and go through a launch process. Internal employees pasting customer data into a general-purpose assistant to draft an email or debug a ticket rarely go through any review at all, and Cloud Radix has reported that 77% of employees using unauthorized AI tools admit to pasting sensitive business data into them. The HTTP request from an employee's browser to a model API carries the same PII exposure as a request from a production service. The policy engine should evaluate both by identity and role, not by whether the call originated from a shipped feature or a browser tab. Treating employee-initiated traffic as lower risk because it never went through a launch process is the assumption behind the shadow AI exposure figures in the first place.

Does redaction slow down the request enough to matter?

Not at the latency budgets production LLM traffic already operates within. Classification and policy evaluation on a typical prompt run in low single-digit to a few dozen milliseconds, depending on the classifier tier involved, against an LLM inference call that itself takes 500 milliseconds to several seconds to return. The redaction step adds overhead the model's own response time already dwarfs. The cost that actually matters is architectural, not computational: building identity context, classification, and policy evaluation into the request path in the first place, rather than bolting redaction onto a system that was never designed to pause a call before it reaches the model. Adding the classifier is a contained piece of work. Threading identity and policy state through every code path that calls an LLM is the part that takes real engineering time.

← Blog

August 22, 2026

PII Redaction in LLM Traffic Has to Happen at the Request, Not the Log

PII redaction has to run on the live HTTP request and response between a user or agent and an LLM, not on a periodic scan of stored documents. This piece breaks down the four paths PII takes into model traffic, why document-level tools miss all of them, and what a redaction policy needs to specify to hold up under review.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

Problem-Awareai-securityllm-securitydata-loss-preventionpolicy-enforcementauditzero-trust

PII Redaction in LLM Traffic Has to Happen at the Request, Not the Log

IBM's Cost of Data Breach Report studied 600 breached organizations and found that customer PII exposure showed up in 65% of breaches linked to shadow AI, against 53% across all breaches in the study. The twelve-point gap traces to one difference: nobody inspected the prompt. A support engineer pastes a customer's account number, email address, and a paragraph about a disputed wire transfer into a chat window at 11 PM to get a faster reply drafted. The account is authenticated. The tool is sanctioned. The PII leaves the building anyway.

Network DLP looked at that same request and saw an encrypted POST to api.openai.com. The API key attached to the call does not map to a corporate identity the way a badge swipe does. The data moved through the one channel legacy DLP was never built to read.

TL;DR

PII redaction in LLM traffic has to run on the live HTTP request and response, not on a document repository scan after the fact.
Four paths carry PII into a model call: typed prompt text, retrieval-augmented context injected server-side, tool-call arguments, and model responses that echo the input back.
DSPM and document-classification tools label files at rest. They have no view of a prompt assembled and sent inside one HTTP call.
A working redaction policy names PII classes, sets mask, block, or allow-with-log per class, and grants exceptions by role, evaluated on every request.

Four paths carry PII into a model call

PII enters LLM traffic through four separate insertion points, and each one has its own review problem.

The first is the prompt text itself, what a user or agent types into an input field or a script pipes into an API call. This is the surface most DLP programs already assume they cover, and it is the smallest of the four.

The second is retrieval-augmented context. A RAG pipeline pulls a support ticket, a contract clause, or a clinical note into the context window before the model runs. The user never typed that content. It arrived server-side, inside the same request, carrying the same PII risk as anything a human wrote by hand.

The third is tool-call arguments. An agent calling a CRM lookup tool passes a customer ID or an email address as a function argument inside the request body, structured as JSON rather than prose. Classifiers built to read narrative text routinely miss it.

The fourth is the model response. A model can echo a field it was given, summarize a document that contained a name, or occasionally generate a plausible-looking identifier it was never given. The response leaves the enterprise boundary the moment it reaches the caller.

All four paths cross the same wire: the HTTP request and response between the authenticated caller and the model API.

Document-level tools were built for data at rest

Data Security Posture Management (DSPM) and document-classification products scan repositories: file shares, buckets, SaaS drives, structured databases. They attach a sensitivity label to a stored object and alert when that object moves somewhere it should not. That model works for a spreadsheet sitting in a shared drive. It has nothing to check for a prompt, because a prompt is never at rest anywhere the scanner looks.

RAG context injection

A retrieval pipeline pulls a chunk from a source document, inserts it into the context window, and sends the assembled prompt to the model in one call. The source document may already carry a DSPM label. Nothing carries that label into the request payload, and nothing evaluates whether this particular chunk belongs in this particular prompt, for this particular caller, at this moment.

Tool-call arguments

A customer ID, an order number, a phone number formatted as a JSON string inside a function call: these values never get written to a file a repository scanner will eventually find. Their entire existence is one HTTP request body, for the length of one call.

The response that echoes back

A model response is generated at request time and returned in the same exchange. It has no file system a scheduled scan will reach. If the model repeats an identifier it was given, the exposure completes before any document-level control runs its next scheduled pass, which for most DSPM tools is measured in hours, not milliseconds.

What a redaction policy has to specify

"Detect PII and redact it" is a slogan, not a policy. It skips three decisions a security team has to make explicitly before a gateway can enforce anything.

The first is which PII classes exist and how they're defined. A workable taxonomy names specifics: PII.Name, PII.Government-ID, PII.Financial-Account, PHI.Diagnosis, Custom.Contract-Terms. A policy that says "PII" gives a classifier nothing to act on and gives an auditor nothing to check the decision against later.

The second is the action per class. Mask replaces the value with a typed placeholder and lets the request continue. Block returns a deny response before the request reaches the model. Allow-with-log lets the value through because the workflow genuinely needs it, and writes a record of exactly what passed. Most production policies use all three, split by class and by API route.

The third is who gets an exception, and it belongs to a role, not a person. A claims-processing workload might be permitted to send PII.Financial-Account to a model that a marketing-analytics workload is blocked from touching, evaluated fresh on every request rather than granted once at login.

This is where the post-authentication gap shows up directly. Authentication answers who is calling. It says nothing about whether this specific caller, on this specific route, is permitted to send this specific class of data to this specific model. NIST's AI agent identity and authorization framework draws the same line between verified identity and the delegated authority to act on specific data. I think most PII programs optimize for the wrong artifact: they inventory documents nobody actually leaks and leave the text box everyone actually pastes into unreviewed.

Classifying prompt text at request latency, applying typed placeholders, and handling the RAG injection point are each their own mechanism. The policy layer above them decides which action applies to a given class on a given route.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline on the HTTP path between authenticated users and agents and any LLM API: OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, or a self-hosted endpoint. It is model-agnostic by design, because the redaction decision has to travel with the traffic itself, not with whichever vendor happens to be on the other end.

For every request, DeepInspect evaluates identity, route, and PII classification against the policy in effect, and applies the mask, block, or allow-with-log action the policy specifies for that class. Each decision is written to a signed, per-decision audit record before the response returns to the caller, independent of the application that made the call.

DeepInspect does not scan repositories or classify documents sitting in storage. It evaluates the request and response traffic itself, at the point where an authenticated caller meets the model. If your current PII control stops at the login screen, the request itself is still unreviewed. Book a demo today.

Frequently asked questions

Does PII redaction in LLM traffic replace our DSPM or data classification program?: They cover different data states, and neither substitutes for the other. DSPM classifies documents, buckets, and repositories at rest, typically on a scan cycle measured in hours or days, and it is genuinely useful for finding where sensitive files already live and who has access to them. LLM traffic redaction evaluates the live HTTP request and response on every call, in milliseconds, before the payload reaches the model. A DSPM label on a source document does not travel into a RAG-assembled prompt, and a DSPM scan will never see a JSON argument that existed for one function call and then disappeared. Keep the DSPM program for its actual job: inventory and access hygiene on stored data. Add request-level redaction for the traffic a document scanner structurally cannot reach, sitting at the AI API call layer instead of the storage layer.
What PII classes should a first policy cover?: Start with the classes that carry the highest exposure cost and the clearest regulatory mapping: government identifiers (SSNs, national ID numbers), financial account numbers, payment card data, and any protected health information if the organization touches healthcare data at all. Add organization-specific classes next: customer account IDs, internal case numbers, anything that shows up in support tickets or CRM records that would embarrass the organization if it appeared in a model provider's logs. A policy with three or four well-defined classes and clear actions beats a policy that tries to enumerate forty categories on day one and enforces none of them consistently. Expand the taxonomy as the audit record shows which classes actually appear in production traffic, and route new classes through a named owner so the definitions stay tied to a specific regulatory or contractual reason rather than accumulating as a vague catch-all list nobody maintains.
How does mask differ from allow-with-log in practice?: Mask changes what the model sees. The gateway replaces the sensitive span with a typed placeholder before the request leaves the enterprise boundary, so the model reasons over a redacted version and the raw value never reaches the provider. Allow-with-log changes what gets recorded, not what the model receives. The raw value passes through because the workflow needs it (a customer service model that has to reference an actual account number to be useful), and the gateway writes a record of exactly what class of data was permitted, on which route, for which identity. Mask is the default for classes the model does not need to see. Allow-with-log is the exception path for classes the workflow genuinely requires, made visible for review instead of invisible by default. Review the allow-with-log list on a fixed cadence. A class that was a legitimate exception in January can turn into a policy gap by June if the workflow it supported has since changed.
Does redaction on the prompt also need to run on the model's response?: Yes, and it is a separate evaluation. Prompt-side redaction stops PII from reaching the model. Response-side redaction catches what the model sends back: a field it was given and is now repeating, a summary that includes a name from the source document, or the rarer case of a model generating an identifier that resembles a real one without having been given it. The same policy engine can run both directions, but the classification has to run twice, once on the outbound request and once on the inbound response, because the content and the risk profile differ on each side of the call. A financial services deployment might mask account numbers on the way in but still need to check the response for a hallucinated routing number that resembles a real one closely enough to cause confusion downstream. Skipping the response side leaves half the exchange unreviewed.
Who should own exceptions to a redaction policy, security or the business unit?: Security should own the mechanism and the audit trail. The business unit should propose the exception, with a specific justification tied to a workflow, not a blanket request for a team. A claims-processing workload that needs PII.Financial-Account to function is a legitimate exception. A request to disable PII checks for "the whole analytics org" is a policy failure waiting to be discovered during an audit. The exception should attach to the role making the API call and the specific data class involved, get a documented business reason, and go through the same review cadence as any other access grant. Security enforces it at the request layer regardless of who approved it. The business unit brings the reason a workflow needs the data. Security's job is bounding that need to the smallest scope the workflow can still run on.
Does this apply to internal employees, or only to external-facing AI features?: Both, and the internal case is usually the larger blind spot. External-facing AI features get security review because they ship to customers and go through a launch process. Internal employees pasting customer data into a general-purpose assistant to draft an email or debug a ticket rarely go through any review at all, and Cloud Radix has reported that 77% of employees using unauthorized AI tools admit to pasting sensitive business data into them. The HTTP request from an employee's browser to a model API carries the same PII exposure as a request from a production service. The policy engine should evaluate both by identity and role, not by whether the call originated from a shipped feature or a browser tab. Treating employee-initiated traffic as lower risk because it never went through a launch process is the assumption behind the shadow AI exposure figures in the first place.
Does redaction slow down the request enough to matter?: Not at the latency budgets production LLM traffic already operates within. Classification and policy evaluation on a typical prompt run in low single-digit to a few dozen milliseconds, depending on the classifier tier involved, against an LLM inference call that itself takes 500 milliseconds to several seconds to return. The redaction step adds overhead the model's own response time already dwarfs. The cost that actually matters is architectural, not computational: building identity context, classification, and policy evaluation into the request path in the first place, rather than bolting redaction onto a system that was never designed to pause a call before it reaches the model. Adding the classifier is a contained piece of work. Threading identity and policy state through every code path that calls an LLM is the part that takes real engineering time.

← All posts