PII Tokenization for LLMs: Simulator and Where It Fails
1. Paste sample text
Use fictional data. The sample uses reserved or published test values: SSN-like numbers with area 000 (never issued) and the published 4111 and 5555 test card numbers. Nothing leaves your browser.
The detection rules (all of them)
- Payment card number: 13 to 19 digits, optionally separated by single spaces or hyphens, that pass the Luhn check.
- US SSN-like: Three digits, hyphen, two digits, hyphen, four digits. Shape only: no check that the number was ever issued.
- Email address: Letters, digits and ._%+- before an @, then a dotted domain with a 2+ letter ending.
- US-style phone number: Optional +1, then 3-3-4 digits separated by spaces, dots or hyphens, area code optionally in brackets.
Overlaps go to the first rule in that order, so a card is never also read as a phone number. Real systems use trained entity recognisers plus context; these patterns are a teaching simplification.
2. What the model sees
- No matches.
Same value, same token, within this session: that lets the model reason about “the same email twice”. A new key gives different tokens, so tokens from another session do not restore here.
3. What this misses
Illustration heuristics flag text that still reaches the model after tokenization. They find names, addresses, dates and ZIP-like codes only to show the gap; they are as crude as the patterns above.
Nothing flagged in this text. That does not mean nothing identifying is there.
Joining attributes re-identifies people (all fictional)
Records with no name, only ZIP code, birth date and sex, matched against a public list that has the same three fields:
| Record | ZIP | Born | Sex | Note the model sees | Joined to |
|---|---|---|---|---|---|
| rec-1 | 00001 | 1975-03-04 | F | prescription refill dispute | Pat Fictional |
| rec-2 | 00002 | 1990-07-21 | M | billing complaint | Sam Imaginary |
| rec-3 | 00001 | 1982-11-09 | F | address change | Lee Madeup |
4. Paste a mock model reply and restore
Real models copy tokens back, move them around or are told to emit them. Pick a scenario or write your own.
TL;DRAt a glance
5 points
- Four simple patterns (SSN-like shape, Luhn-valid card, email, US-style phone) are swapped for deterministic UUID-shaped tokens made with HMAC-SHA256 under a random per-session key held only in your browser.
- You see the text the model receives, then paste a mock reply and restore the originals.
- Regex detection is a simplification of the entity recognition real systems use. Names, addresses and free text pass through; ZIP code, birth date and sex can be joined back to a person.
- Restoring tokens blindly is dangerous: injected text can make the model emit tokens inside a link.
- Tokenization or pseudonymisation does not by itself make processing compliant. Nothing is uploaded. Markdown and PDF export (without the original values) is a paid feature.
How the failures happen
- Not matched. A name, a street address or “the CFO of the company that moved to Lisbon last year” has no fixed pattern. Entity recognisers help, but they also miss things and cannot judge what is identifying in context.
- Quasi-identifiers. Several ordinary attributes together can single someone out. The fictional join in section 3 matches each “anonymous” record to exactly one person.
- Wrong context. Tokens are opaque to the model, so it can put a card token into a subject line or an email token into a field that gets published. Restore puts the real value there.
- Injection. Text the model reads can tell it to print every token it has seen, or to place them in a link. If restore runs on that output, the leak is complete.
- The mapping. The key and the token-to-value table are the sensitive part. Whoever holds them can reverse every token, so they need the controls the original data would have had.
What the sources say, briefly
OWASP’s LLM02 entry lists personal data, financial details and credentials among the sensitive information an LLM application can disclose. NIST SP 800-122 is about protecting PII by its impact and context. The PCI Security Standards Council’s 2011 tokenization supplement, written for PCI DSS 2.0, says it does not replace or supersede PCI DSS requirements, so a token scheme still has to be assessed. GDPR Article 4(5) defines pseudonymisation as processing that keeps data from being attributed to a person without separately held additional information, and it is generally understood that pseudonymised data can remain personal data (GDPR Recital 26, which we did not fetch). The EDPB opened guidelines on pseudonymisation for consultation in January 2025.
Cards in this tool are found by shape plus the Luhn check, which only catches mistyped numbers. A valid-looking number is not necessarily a real card, and a real one with spaces in unusual places can be missed. The sample SSN-like values use area number 000, which is never issued, and the cards are well-known published test numbers.
Frequently asked questions
What is PII tokenization for an LLM?
Before text goes to a model, sensitive values are replaced by placeholders and the real values stay in a mapping you control. When the reply comes back, the placeholders are swapped back. The model never sees the originals, but it can still tell that two mentions were the same value.
How does this simulator make tokens?
It takes HMAC-SHA256 of the value type and value under a random key created in your browser for this page view, and shapes the first 16 bytes like a UUID. The same value always gives the same token within a session, and a new key gives different tokens. The key and mapping are held in memory only.
How does it find the data?
With four simple patterns, all listed on the page: a 3-2-4 digit shape for SSN-like numbers, 13 to 19 digits that pass the Luhn check for cards, an email pattern and a US-style phone pattern. Real systems use trained entity recognisers with context. Regex detection here is a simplification for teaching.
What does it miss?
Anything without a pattern: names, street addresses, free-text descriptions and employer names. Quasi-identifiers such as ZIP code, birth date and sex pass through and can be joined with other data to single someone out. The page flags examples and shows a fictional join.
Is tokenization the same as pseudonymisation under GDPR?
They are related, not identical. Article 4(5) defines pseudonymisation as processing so that personal data can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected. Recital 26 of the GDPR, which we did not fetch, is generally read as treating pseudonymised data as still personal data. Either way, doing this does not by itself make processing lawful or compliant.
Can a prompt injection abuse tokens?
Yes. If injected text makes the model emit tokens inside a link or a message to someone else, a pipeline that restores every token blindly will put the real value there. Try the injected scenarios in section 4. Restore only in trusted places, never inside URLs, and treat model output as untrusted.
Is this a compliance tool?
No. It is an educational simulator. It does not detect all personal data, does not meet any payment or privacy standard, and nothing here is legal advice. Whether and how you may send personal data to a model depends on your law, contract and risk assessment.
Is my text uploaded?
No. Detection, tokenization and restore all run in your browser. Use fictional data anyway.
Sources
Pages below were fetched on 4 November 2026. We restate them in our own words.
- LLM02:2025 Sensitive Information Disclosure — OWASP Gen AI Security Project, 2025. Accessed 4 November 2026.Lists PII, financial details, health records and credentials as sensitive information that can leak through an LLM or its application context.
- SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) — NIST, April 2010. Accessed 4 November 2026.Old (2010). Used for the idea of PII and of protecting it by context and impact, not for any pattern list.
- PCI DSS Tokenization Guidelines (Information Supplement) — PCI Security Standards Council, August 2011. Accessed 4 November 2026.Written for PCI DSS 2.0 and says it does not replace or supersede requirements in the PCI DSS. A 2011 supplement: check the current PCI guidance before relying on it.
- Art. 4 GDPR, Definitions (point 5, pseudonymisation) — gdpr-info.eu (mirror of Regulation (EU) 2016/679), Regulation of 27 April 2016. Accessed 4 November 2026.EUR-Lex could not be fetched on 4 November 2026 (it returned an HTTP 202 challenge page with no text), so this is a mirror. Check against the Official Journal.
- Guidelines 01/2025 on Pseudonymisation — European Data Protection Board, public consultation 17 January to 14 March 2025. Accessed 4 November 2026.We read the consultation landing page only, not the PDF, so we make no claim about its detailed content.
- Logging Cheat Sheet — OWASP Cheat Sheet Series, as served 4 November 2026. Accessed 4 November 2026.Says logging mechanisms and stored events must be protected from tampering, unauthorised access and deletion, and lists data that should not be logged directly (tokens, passwords, card data, some PII).
We could not read EUR-Lex on 4 November 2026 (it returned a challenge page with no text), so the GDPR wording comes from a mirror; for the EDPB guidelines we read the consultation page, not the PDF. The PCI document dates from 2011.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.