Reversible PII redaction: how redact-then-restore works

Why does one-way masking break chat apps?

Classic redaction is one-way: find the email, replace it with [REDACTED], done. That is correct for logs and documents, where nobody needs the value back.

Chat breaks this model. A user writes "email my invoice to sarah@acme.com", you mask it, and the model dutifully replies "I have sent the invoice to [REDACTED]". The user stares at a broken product, and your team quietly turns redaction off.

The fix is a coat check. You hand over the real value at the door, get a numbered ticket, and the ticket is worthless to anyone else; on the way out, the ticket becomes the real thing again. That is the whole metaphor, and the rest of this post is the machinery.

What makes a good redaction token?

Sether tokens look like <EMAIL_uuid>: a type prefix plus a unique identifier. Both parts do work.

• The type prefix tells the model what kind of value sits there. It can still say "I will send the invoice to <EMAIL_uuid>" and reason about it as an email address.
• The unique identifier makes the token meaningless outside your system. There is nothing to reverse, no hash to crack; the mapping exists only in your vault.
• Stability means the same value gets the same token for as long as the vault holds it. If sarah@acme.com appears three times, it becomes the same token three times, so the model knows they are one address.

Where do the real values live?

In the vault: a key-value store mapping tokens to original values. Sether ships MemoryVault, an in-process LRU that holds 10,000 entries with a 1-hour TTL.

The vault is a pluggable interface, not a fixed implementation. When one process is not enough, back it with Redis or any shared store, and redact and restore can then happen on different machines. What never changes is where the vault runs: inside your infrastructure, never at the provider.

Why must the same instance redact and restore?

Because the vault lives on the instance. When redact() mints a token, it writes the mapping into that instance's vault; when restore() meets the token in the reply, it reads the same vault back.

Create a second instance for the restore side and you get a fresh, empty vault. The tokens come through untouched and your user sees <EMAIL_uuid> in the reply. This is the most common integration mistake, and it is also the easiest to catch: one round-trip test finds it immediately.

How does this survive a multi-turn conversation?

Stable tokens carry the conversation. Turn one redacts sarah@acme.com to a token; turn three, when the user says "actually send it to that same address", the history you resend contains the same token, so the model refers back to it consistently.

The model never learns the real address across any number of turns, yet the thread stays coherent. The 1-hour default TTL fits a live session; for conversations that must resume days later, a persistent vault with a longer TTL is the knob to turn.

What are the security properties?

• The provider never holds real values. Prompts, logs, and any retention on their side contain tokens only.
• Tokens are meaningless outside your boundary. A leaked prompt, a provider breach, or a screenshot exposes identifiers with no mapping attached.
• The vault stays in your infra. The token-to-value mapping never crosses the wire to anyone.
• TTL bounds exposure. Entries expire (1 hour by default), so even inside your systems, the mapping is not held longer than the session needs.

To be precise about the claim: this is a technical measure that helps with data minimisation. It shrinks what leaves your boundary; it does not remove the need for processor agreements or a lawful basis, which we walk through in the GDPR post.

When is reversibility the wrong choice?

Reversibility exists to serve a live user who needs the real value back in the reply. If no user is waiting, keeping a path back to the data is a liability, not a feature.

A good rule: reversible on the request path, one-way everywhere data comes to rest.

The round trip in code

In TypeScript, redact and restore are stream transforms on one instance. The full tutorial, including the drop-in OpenAI wrapper and SSE streaming, is here.

import { Sether } from '@raeven-co/sether';
import { Readable } from 'node:stream';

const sether = new Sether(); // holds the vault

// Outgoing: values become tokens
const safeForLLM = Readable.from([userMessage]).pipe(sether.redact());

// Incoming: tokens become values again, same instance
const safeForUser = llmResponse.pipe(sether.restore());

In Python, the same design with sync calls (async and streaming also exist; the Python walkthrough covers them).

from sether import Sether

sether = Sether()  # holds the vault

safe = sether.redact_sync(user_message)   # values -> tokens
reply = call_llm(safe)
restored = sether.restore_sync(reply)     # tokens -> values

One subtlety worth knowing before you ship: restoring a streamed reply means tokens can split across chunks, and a naive restore misses them. Sether holds back a small window to stay boundary-safe; the details are in the chunk-boundary bug post.