Detecting PII Hidden in Encoded or Obfuscated LLM Prompts

Why plaintext-only inspection fails

Most PII detection was built for text that looks like what it is. A pattern for a national ID number or a payment card matches a recognizable string. If the same value arrives as base64, hex, or percent-encoded text, the characters no longer resemble the pattern, and the prompt passes inspection. The model, or a tool the model calls, may still interpret the content, because models and downstream code can often decode common encodings without being asked.

The cause is not always an attacker. Applications serialize data into JSON fields, agents pass tool outputs along as encoded blobs, and users paste content from systems that escape or wrap values. The detection problem is the same whether the encoding was deliberate or incidental: the sensitive value exists in the request, and the inspector never saw it.

This matters beyond the user's own message. NIST defines prompt injection as an attack that exploits the concatenation of untrusted input with a prompt built by a higher-trust party. Any untrusted text that is concatenated into a prompt is a channel where hidden content can arrive, including retrieved documents and tool results. NIST also reports that private information provided to a model in context can be elicited through direct prompting, which is a reason to inspect context and outputs as well as user text.

Common obfuscation forms and the step that addresses each

The table summarizes general mechanics, not prevalence. Each form defeats a matcher that only sees the raw string, and each needs a specific preprocessing step.

• Base64 or hex encoding: The value is rewritten as an alphabet of other characters. Detect candidate encoded spans, decode them, and rescan the result.
• URL or percent encoding: Characters are replaced with escape sequences. Decode escapes during normalization before matching.
• Character substitution: Look-alike Unicode characters, zero-width characters, or spacing replace plain digits and letters. Apply Unicode normalization and strip invisible characters.
• Splitting across fields: A value is divided between JSON fields, headers, or arguments. Reassemble fields in the order the downstream consumer would read them.
• Splitting across turns: Fragments arrive in separate messages. Maintain conversation state and test concatenated windows, not only single messages.
• Nested encoding: One encoding wraps another. Decode recursively with a depth limit and a defined action when the limit is reached.

A layered detection pipeline and its limits

Start with normalization: canonicalize Unicode, remove invisible characters, collapse irregular whitespace, and decode escape sequences. Then run recursive decoding. Identify spans that plausibly hold encoded data, decode them, and feed the output back through the same pipeline. Each pass multiplies work, so set a maximum depth and a maximum expansion size.

Next comes recognition. Pattern matching with checksum validation, where a format has one, cuts false positives for structured identifiers. It does little for names, addresses, or free-text health details, which need context-aware classifiers such as named entity recognition. Multi-turn analysis adds state so that fragments are evaluated together.

Each layer has a cost. Decoding attempts on high-entropy text such as hashes, keys, and compressed data can produce junk that triggers false matches or wastes compute. Context classifiers add latency and can miss values in unusual phrasing. A depth limit creates a decision: when content is still encoded at the limit, the policy must say whether to allow, flag, or block. Blocking is safer and noisier; allowing is quieter and leaves a gap.

No detector should be assumed to catch all obfuscated PII. Input-side detection also does not remove every exposure, since NIST notes that generative models may be able to infer PII that was neither disclosed by the user nor present in training data. Plan for layered controls and measured residual risk.

Enforcement and evidence as one example

Trussed is one example of this model. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants. Actions include allow, redact, block, rate limit, and escalate for human approval, applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, a policy decision happens before the data moves.

Enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency, which bears directly on the question of where PII-bearing evidence is stored. Trussed runs in production for customers in insurance, pharma, healthcare, and education, and holds SOC 2 Type II and ISO 27001 certifications, alongside HIPAA, GDPR, FERPA, and NIST AI RMF alignment.

Whichever approach you assess, apply the checklist above. How well any product handles specific encodings, depth limits, and false positives is a testing question, and the answer should come from your own corpus.