Understanding Anonymization
How Zeuslock rewrites sensitive values into structurally valid fakes so the AI still gives useful answers, while the original never leaves your machine.
The three policy modes, in one minute
Every detector in Zeuslock runs in one of three modes, and you can mix them per data type. Monitor lets the prompt through and logs the finding for the security team. Anonymize rewrites the sensitive value before the prompt is sent, so the AI never sees the real data but still gets a useful question. Block stops the prompt entirely and shows you why.
This article is about the middle mode, because it is the one that confuses people the most. Monitor is invisible. Block is obvious. Anonymize is the one that quietly does the work.
What anonymization actually does
When Zeuslock detects a sensitive value in your prompt, it does not delete it or paste a generic [REDACTED] tag in its place. That would make the AI answer with nonsense or refuse to help. Instead, Zeuslock replaces the value with a structurally valid fake — a string that looks and behaves like the original, minus the secret part.
Concretely, that means:
- The new value has the same format, length and check digits where it matters.
- The non-sensitive context (country prefix, brand, last 4 digits) is preserved so the AI can still reason about it.
- The actual secret bytes — the card number, the API key, the phone digits — are replaced.
Examples
| Type | Original | Anonymized | Why this rewrite |
|---|---|---|---|
| Credit card | 4111-1111-1111-1111 | 4xxx-xxxx-xxxx-1111 | Luhn check still passes, brand inferable from the leading 4, last 4 digits kept for customer support context. |
| alice@acme.com | user@example.com | Still a valid email shape, no real identity, no real domain. | |
| AWS access key | AKIAIOSFODNN7EXAMPLE | AKIA**************** | Prefix kept so the AI knows it is an AWS key; the secret entropy is removed. |
| IBAN | FR76 3000 6000 0123 4567 8901 234 | FR76 XXXX XXXX XXXX XXXX XXXX XXX | Country code and bank-code prefix preserved, account digits destroyed. |
| Phone | +33 6 12 34 56 78 | +33 6 XX XX XX XX | Country and carrier prefix kept, subscriber digits destroyed. |
Why we call it format-preserving
The point of keeping the prefix, the length and the checksum is that the AI can still answer questions about the value without seeing the value itself. If you ask ChatGPT "what country is this IBAN from?", the redacted version still answers "France" — because we kept FR76. If you ask Claude to write a refund email referencing "the card ending 1111", it still works — because we kept the last four digits.
Anonymization is therefore not a tax on usefulness. It is the opposite of a black bar over the screen. Your prompt keeps working; the secret simply does not travel.
The pre-send preview
Anonymization is never silent. Before any rewritten prompt leaves your browser or desktop agent, Zeuslock shows you a preview window with the exact text that is about to be sent. You can see, line by line, which substrings were replaced. You can cancel, edit the prompt and resend, or confirm.
This serves two purposes. It builds trust — you always know what the AI saw. And it teaches good habits: after a few previews you start noticing the kinds of values you were about to leak.
What is not anonymized
Only the detected values are rewritten. The prose around them stays intact. A prompt like:
My customer at acme.com paid with 4111-1111-1111-1111 yesterday, can you draft a thank-you email?
becomes:
My customer at user@example.com paid with 4xxx-xxxx-xxxx-1111 yesterday, can you draft a thank-you email?
The intent of the prompt is preserved. The AI writes the email. The card number and the customer email never leave your machine.
One-way and local
Anonymization is one-way. The original sensitive value never reaches the LLM provider, and it never reaches Zeuslock's servers either. The mapping from real value to fake value lives only in your browser or desktop agent for the duration of the prompt, then it is discarded. There is no reverse lookup, by us or by anyone else.
When anonymization is not enough
Anonymization works beautifully for values with a clear structure: cards, keys, IBANs, emails, phone numbers. It works less well for two categories of content:
- Source code. A proprietary function is sensitive as a whole — you cannot anonymize "the secret algorithm" by replacing variable names. For code, use Block mode, or rely on an organization-wide policy that routes code only to sanctioned tools.
- Free-form proprietary text. Internal strategy notes, unreleased product details, customer-confidential prose. The sensitive content is the meaning, not a token. Block mode is the right answer here.
The recommended rollout still applies: start in Monitor for the first two weeks to see what flows through, switch to Anonymize for everything that has a usable rewrite, and reserve Block for the categories where no safe rewrite exists.