Adding PII Redaction to a LiteLLM Proxy for HIPAA Workloads

Where redaction belongs in the request path

A LiteLLM Proxy sits between applications and model providers, so it is the natural place to apply a redaction step. The point to decide is which payloads the step covers. PHI does not only appear in the user's prompt. It can sit in retrieved documents added to context, in tool-call arguments, in tool results returned to the model, and in the model's own response.

A workable design has two stages. A pre-call stage masks content before it is sent to the provider. A post-call stage inspects what comes back, because a model can repeat, infer or reconstruct identifiers from the context it was given. Whichever mechanism you use, whether a custom hook, a guardrail integration or a Presidio-based masking step, confirm that each stage covers every payload type you actually send.

Two edge cases need explicit tests. Streaming responses arrive in fragments, so a detector that needs complete text must buffer, and an identifier can be split across chunk boundaries. Tool calls carry structured fields, and detectors tuned for free text can miss identifiers inside JSON values. Do not assume either case is covered. Prove it with test cases against your deployed version.

The limits of pattern and NER detection on PHI

Pattern-based detectors work well for identifiers with a fixed shape, such as telephone numbers and email addresses. Named-entity recognition handles names and places better, but it depends on context. Clinical text is full of abbreviations, shorthand, misspellings and unusual formatting, and identifiers that depend on context are the ones most likely to be missed. Treat any detector as probabilistic.

HIPAA's Safe Harbor method is defined around 18 identifier types, including names, telephone numbers, email addresses and other unique identifying numbers, characteristics or codes. NIST has noted that information allowing identification can remain even after those 18 elements are removed. NIST also describes redaction alone as generally insufficient to provide formal privacy guarantees, and notes that selective redaction can introduce bias. NIST's broader PII concept is wider than the HIPAA list, so personal data outside the 18 types may still need handling.

Published figures should be read carefully. One older NLM evaluation reported that a clinical de-identification tool removed 99.2% of identifiers matching Safe Harbor. That result belongs to that tool and that dataset. It says nothing about the detector in your proxy. Measure your own detector on text that resembles your own traffic, and report recall for each identifier category rather than one accuracy number.

For the same reason, do not describe a runtime redaction step as achieving HIPAA de-identification. De-identification means meeting Expert Determination or Safe Harbor, and a proxy filter does not establish either.

Fail-closed design and testing

Fail-open means a request continues unredacted when the detector errors or times out. For PHI workloads that is the wrong default, because the failure case is exactly when unmasked data reaches a provider. Fail closed: if detection cannot complete, reject the request and return a clear error to the caller. Apply the same rule to the response path.

Fail-closed behavior has an operational cost, which is that a detector outage becomes an application outage. Plan for it with health checks, timeouts, capacity for the detector and an alert on the block rate. If some low-risk routes can tolerate degraded behavior, make that an explicit per-route decision that is reviewed, never an inherited default.

Testing should cover three things. First, a synthetic PHI set with labeled examples for all 18 Safe Harbor identifier types, plus quasi-identifiers and context-dependent clinical phrasing. Never use real patient data. Second, regression runs on every change to the detector, its configuration or the proxy version, so coverage cannot drift unnoticed. Third, latency measurement with the detector in the path, at realistic payload sizes and with streaming enabled, because added latency is what pushes teams to relax controls. Include fault-injection cases that disable the detector and confirm requests are blocked.

Evidence for HIPAA 164.312(b) audit controls

NIST SP 800-66r2 frames audit controls as hardware, software or procedural mechanisms that record and examine activity in information systems. Its audit process includes activating review, beginning auditing and logging, and asking how the effectiveness of the audit process will be assessed. A redaction step therefore needs to produce records that can be examined, and someone has to examine them.

The constraint is that the evidence must not become a second store of PHI. Record the facts about each decision, not the content. A useful record includes a timestamp, a request identifier, the route, key or team, the stage (pre-call, post-call or tool call), the policy and detector version applied, the entity types and counts found, the action taken (allow, redact or block), and any error that triggered a fail-closed block. If you need to correlate with the original request, use an identifier or a salted hash rather than the text.

Retention, access to the evidence store and a periodic review of block rates and test results complete the picture. Proxy-level logs are a starting point, but they are only as durable and consistent as their configuration. Decide where evidence is written, who can alter it and how long it is kept before an auditor asks.

Where runtime policy enforcement complements the proxy

A proxy redaction step covers the traffic that is routed through it. Organizations often also have agents, tool calls and MCP servers whose interactions need the same treatment, and they need evidence that is consistent across all of them.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. It applies allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to HIPAA. It can be self-managed in the customer's cloud, with configurable retention and data residency. Trussed runs in production with healthcare and pharma organizations.

This complements a LiteLLM Proxy rather than replacing the design work above. You still need to define what counts as PHI in your workloads, test detection by category and decide how failures behave.