Format-Preserving Encryption for LLM Traffic Has a Narrow Job

Format-preserving encryption turns a structured plaintext value into ciphertext with the same length and character set. A 10-digit identifier remains 10 digits. A fixed-width uppercase account code remains the same width and alphabet. That property can keep a legacy validator or schema working after the value is protected. It also creates an attractive trap: teams start applying the technique to every sensitive substring in a prompt, even where the model needs language rather than a syntactically valid token.

TL;DR

• FPE fits fixed-format fields whose downstream schema requires the original length and alphabet.
• NIST SP 800-38G specifies approved methods for format-preserving encryption, while implementation still needs domain design plus controlled handling of encryption secrets and tweaks.
• Free text and other variable-length content the model must interpret usually need another transformation.
• An AI gateway can enforce a field policy on routed HTTP prompts, while cryptographic custody and re-identification remain separate services.

FPE preserves syntax rather than meaning

NIST SP 800-38G Update 1 specifies FF1 and FF3 as format-preserving encryption methods built on an approved symmetric-key block cipher. The useful property is syntactic compatibility. Ciphertext stays inside a defined domain instead of expanding into a base64 string or changing a numeric field into mixed characters.

That property says nothing about semantic usefulness to an LLM. Encrypt 4829017364 into another 10-digit string and a fixed-width parser remains satisfied. The model sees a different number with no business meaning. This works when the task only needs a stable placeholder or the application restores the original value later. It fails when the model must reason about the actual number, such as comparing a date or calculating an amount.

A white form with ten empty boxes makes the constraint visible. FPE can fill all ten boxes with protected digits. It cannot tell the model what those digits meant before encryption.

The broader tokenization versus redaction guide owns the reversibility decision. This article focuses on the narrower engineering case where format itself must survive.

Domain design decides what the ciphertext can look like

An FPE field needs an alphabet and a length. Together they define the domain of possible values. Google Cloud's Sensitive Data Protection pseudonymization guidance describes FPE output that preserves input length and character set. Its service supports alphabets containing 2 through 95 characters and allows a custom set such as digits plus selected punctuation.

Design the domain around the field, not the entire prompt. A phone-number field may contain digits while punctuation remains outside the encrypted substring. An account code may allow uppercase letters and digits. A free-text paragraph combines variable length and language structure with whitespace and punctuation. Treating that paragraph as one FPE domain creates little model utility and a difficult security review.

Small domains deserve special scrutiny because their structure leaks. Length and alphabet remain visible by design. Repeated deterministic outputs may also reveal equality when the same cryptographic material and context produce the same token. The security review should document those disclosures and decide whether the workflow accepts them.

My opinion is that FPE should lose every design review unless a real parser rejects a safer token format. Compatibility is the only justification I accept.

Encryption material and tweaks define the recovery boundary

Reversibility puts the encryption key on the critical path. Google documents the preferred pattern as wrapping encryption material through Cloud KMS and warns against sending that material raw. The component performing re-identification should authenticate the caller and check purpose and workflow context. It should also record the recovery event.

A context tweak changes token scope. The same plaintext can produce different protected values across tenant boundaries and matter-specific workflows when the implementation uses context correctly. This can reduce cross-context correlation. The tweak must be available again for decryption, so it needs a stable derivation and protection appropriate to its role.

Avoid placing the key or raw tweak inside the LLM request. The model needs the protected value only. A separate cryptographic service handles encryption and authorized recovery. The request policy should name the transformation profile rather than exposing identifiers for cryptographic material that an application may misuse.

Zero-trust LLM architecture provides the identity and route controls around that cryptographic service.

Field policy should precede prompt transformation

Start with an inventory of prompt fields and downstream behavior. For each field, record its data class, format constraint, model purpose, reversibility need, token scope, and recovery owner. A support summarization route might protect a fixed-width customer number with FPE while redacting credentials. Non-sensitive prose stays intact.

Apply the transformation before the provider-bound HTTP request. Preserve separators outside the encrypted domain where the parser needs them. Attach the transformation profile and policy version to the gateway decision record. Avoid writing plaintext into general logs before encryption. Response handling then checks every protected value before recovery.

FPE produces values that look valid for the field. That is the point, and it creates a response risk. A model can invent another 10-digit value that matches the alphabet and length. Format alone proves nothing about origin. The application must verify that a returned value came from the current encryption operation and belongs to the authenticated workflow.

AI prompt redaction covers routes where removal or nonreversible replacement preserves enough utility.

Output validation stops token-shaped inventions

Maintain an allowlist of protected values issued for the current request or workflow. When the model response contains a format-matching value, check membership before any decryption call. Any membership failure should stop decryption, including ownership by another tenant or placement in an excluded output field.

Bind recovery to a named business purpose and authorized route. A model may copy the protected customer number into a summary, which the approved application then uses to attach the summary to the right record. The same response should not trigger recovery inside a chat transcript or analytics export. The re-identification service needs the caller, route, field, and request context to decide.

Failure should preserve the protected state. If the cryptographic service is unavailable, return the encrypted value or stop the workflow according to policy. Sending the plaintext through a fallback model route defeats the transformation. Record the failure without copying the original value into telemetry.

Test streamed responses as partial values accumulate. A validator may need to hold a candidate until the complete token arrives. The final record should show the token reference, transformation profile, recovery outcome, and destination field.

The HTTP boundary owns policy, while cryptography stays adjacent

An inline LLM gateway can classify a prompt and identify fields covered by an approved transformation policy. It can require the application to call a cryptographic service before forwarding, or invoke an integrated transformation component where the architecture supports one. It can then block plaintext that violates the route rule.

Generation and storage of cryptographic material belong to the cryptographic service and KMS owners, along with rotation, tweak derivation, and decryption authorization. The gateway should receive the minimum result needed to enforce route policy. It should avoid becoming a general cryptographic vault or re-identification API.

The gateway also inspects the response before it reaches the caller. It can require token validation and restrict routes that permit recovery. Downstream database writes and user-interface disclosure remain application controls. LLM DLP covers the classification layer around these choices.

This allocation keeps the DeepInspect HTTP boundary exact. The gateway governs the provider-bound request and response. Cryptographic custody remains with the component designed for it.

DeepInspect

DeepInspect can enforce transformation policy on authenticated HTTP prompts deliberately routed through its LLM proxy. It can classify covered fields, require the approved protected representation before forwarding, inspect returned token-shaped values, and write a signed decision record containing the policy and transformation profile.

A KMS and cryptographic service retain custody of cryptographic material and authorized re-identification. That material includes keys and tweaks. DeepInspect owns the routed request decision rather than the cryptographic primitive or downstream recovery action. Book a technical deep dive at deepinspect.ai.