Prompt-Level DLP: Inspection at the Field Where the User Says What They Mean
Prompt-level DLP runs inspection at the prompt body sent to an LLM endpoint, not at file boundaries or network egress. The prompt is the data, and the prompt sits inside an encrypted POST body to a SaaS destination. This piece walks through where prompt-level DLP sits, the classifier categories it has to recognize, how the redaction decision feeds the model, and the regulatory framing under EU AI Act Article 12 and HIPAA.
The prompt body is the surface every other DLP layer misses. A network DLP sees the TLS handshake to the LLM endpoint but not the body. An endpoint DLP sees the keystrokes that compose the prompt but not the assembled POST body. An email DLP does not sit on the path at all. Prompt-level DLP fills the gap by running classification on the prompt content at the moment the HTTP request crosses the inspection boundary between the authenticated user or agent and the LLM endpoint.
I want to walk through where prompt-level DLP sits, what the classifier has to recognize on the prompt content, how the redact decision works against the model, and what the regulatory framing expects from the per-request record.
What "prompt-level" means
Prompt-level inspection means the classifier runs on the JSON body of the HTTP request the application or browser sends to the LLM endpoint. The request body carries the prompt content in fields the LLM API contract specifies: messages for OpenAI Chat Completions and Anthropic Messages, contents for Google Generative AI, inputText for AWS Bedrock Runtime. The inspection layer parses the body, locates the prompt fields, runs classification against the text, and returns a decision before the request is forwarded to the model.
The granularity of the inspection is character-level inside the prompt text. The classifier identifies the span of the sensitive content (the start offset and the length) plus the category label and the confidence score. The decision applies to the span: permit forwards the prompt unchanged, redact substitutes a placeholder for the span, block returns an error to the caller without forwarding to the model.
Where the inspection sits
The inspection runs at the HTTP proxy between authenticated users or agents and the LLM endpoint. The proxy terminates TLS at the inspection layer (so it can read the body), authenticates the caller against the corporate IdP (so it can bind identity), runs classification (so it can label), evaluates policy against identity and classification (so it can decide), and commits the audit record (so the decision is recoverable).
The placement is the only one that holds the prompt and the verified identity at the same surface. A network inspection point sees the TLS connection but not the body. An application-side classifier sees the body but does not see the verified identity unless the application carries it through. The proxy placement removes the integration dependency from each application team.
What the classifier recognizes on prompt content
The classifier categories the audit record sits on:
The categories are tuned for the way data appears inside prompts rather than the way data appears inside files. Prompt content often contains short snippets of structured data embedded in natural-language context. The classifier handles the embedded-snippet pattern: a name and a Social Security Number inside a paragraph, a credit card number inside a customer support narrative, a SOAP note inside a chat exchange.
How redaction feeds the model
When the policy returns a redact decision, the inspection layer substitutes a placeholder for the labeled span before forwarding the request to the model. The model receives a prompt where the PII or PHI has been replaced with a typed placeholder:
The model produces a response against the redacted prompt. The response does not contain the sensitive data because the model never saw it. The original prompt content is retained in the audit record on a separate store with stricter access controls. The record carries the original text, the redacted text, the labels, and the policy version, so the program can reconstruct the decision at any point.
The redaction approach matters for compliance because the model provider never receives the raw sensitive data. Under EU AI Act Article 12 obligations, the record carries the original; under HIPAA, the BAA scope of the model provider does not have to cover the redacted content because the content never crossed the inspection layer in its raw form.
What the audit record carries
The record commits before the response returns to the caller. The fields include:
The record series is the field auditors sample under Article 12 and the HIPAA audit control rule. The series is tamper-evident because each record's signature chains against the previous record, so any deletion or modification is detectable on a routine integrity check.
Regulatory framing
EU AI Act Article 12 requires automatic recording of events over the lifetime of the system sufficient to ensure traceability. Article 19 specifies the record fields, including identification of natural persons involved and input data references. Article 99 sets penalties at €15 million or 3% of global annual turnover for high-risk non-compliance. The August 2, 2026 deadline applies to high-risk AI systems including credit scoring, employment screening, education access, and biometric identification.
HIPAA Security Rule 45 CFR 164.312(b) expects audit controls on systems that process PHI. The PHI classification label on the prompt content is the field that maps directly to the HIPAA record requirement. A classifier that fails to identify PHI in SOAP notes or clinical narrative fragments produces records that fail the HIPAA audit sample.
What goes wrong without prompt-level DLP
Without prompt-level inspection, the program lands on one of three failure modes. The first is reliance on the model provider's safety filters, which catch some categories but do not produce an enterprise-controlled audit record. The second is reliance on application-side classifiers, which catch the data the application team chose to wire in but miss the prompts other application teams send. The third is reliance on network-level DNS or SNI logs, which produce an inventory but not a per-request record.
None of the three failure modes produce a record that survives an Article 12 or HIPAA audit. The auditor's question reduces to who sent which prompt under which policy at which moment. The answer requires the prompt content, the identity context, and the policy state on the same record.
DeepInspect
DeepInspect is the prompt-level DLP placement. The proxy sits inline between authenticated users or agents and any LLM, terminates TLS at the inspection layer, authenticates against the corporate IdP, runs deterministic classification against the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the model response returns. The records carry the classification spans, the redaction decision, the policy version, and an integrity signature on a tamper-evident series.
For programs preparing for the August 2, 2026 deadline, the prompt-level placement is the field auditors will sample. The placement at the HTTP boundary is what makes the field consistent across multiple application teams and multiple LLM providers.
Book a demo today.
Frequently asked questions
- How does prompt-level DLP handle file attachments to chat interfaces?
When a user attaches a file to a chat interface that supports it, the file content typically arrives at the model through a separate upload endpoint and then becomes part of the prompt context. The inspection layer at the HTTP boundary sees the upload endpoint as a related call and runs classification against the file content using the same category catalog. The audit record carries both the prompt-level decision and the file-level decision on the same series.
- Does prompt-level redaction confuse the model?
The placeholders preserve the structural cues the model needs to produce a coherent response. The model treats the placeholder as a token referencing a named entity and produces a response that references the entity at the appropriate grammatical position. Programs that need response quality calibration usually run the redaction policy in detection mode for the first thirty days to confirm the model behavior stays in scope.
- Can the inspection layer cover system prompts and developer messages?
The inspection layer runs against the full request body including system messages, developer messages, and user messages. Programs that use system prompts to carry organizational context can decide whether the system prompt should be classified the same way as user prompts. The default policy applies the same categories to both with the option to scope rules to specific message roles.
- How does prompt-level DLP integrate with existing SIEM?
The audit records flow into SIEM through standard log forwarding (Splunk HEC, Elastic ECS, Datadog logs, syslog). The schema aligns with the fields Article 19 references and the HIPAA audit control rule expects. Programs that already operate compliance analytics pipelines extend the same pipeline to the prompt-level record series.
- What about the response side?
The same inspection layer runs classification on the model response before it returns to the caller. The redact-on-response pattern catches cases where the model produces sensitive data the prompt classification did not predict. The audit record carries the response-side decision on the same series as the request-side decision.