Tokenization vs. Masking vs. Encryption for LLM Prompts
Three techniques, three different threat models, three different failure modes. The one you want for LLM prompts is not the one your database uses.
Encryption
Deterministic AES-GCM of a name yields `9c7f...`. The model gets a random string and treats it as noise. Response quality collapses. Rules out for prompts.
Masking
Replace 'Anna Nagy' with `***`. Irreversible. Fine for logs, useless for a workflow where you want the name back in the response.
Tokenisation
Replace 'Anna Nagy' with `[NAME_1]` and remember the mapping. Model sees a token it treats as a proper noun. Response mentions `[NAME_1]`. You replace the tokens back on the way out. This is the technique PromptShielder uses.
Where the mapping lives
The threat model dictates. Server-side vault: strong audit, single point of failure. Encrypted local storage: durable across sessions, adds a decryption step. In-memory only: no persistence, dies with the tab, lowest risk profile. PromptShielder defaults to in-memory with an XOR-obfuscated per-session cache for cross-tab-within-session convenience.
Frequently asked
Is XOR-obfuscation encryption?+
No. It defeats casual DevTools inspection, not a determined attacker. The strong control is that the key dies on reload.
What if I need cross-session persistence?+
Then you need real key management. WebAuthn-derived keys are the honest answer.