FlowSentricWhat is PII masking, and how does FlowSentric actually do it?
PII masking in plain language: what gets detected, how placeholders work, why the mapping is reversible only in your view, and what a privacy log should store.
- Masking is not redaction. The value is replaced by a placeholder for the model and restored afterwards, only for you.
- Ten entity types are detected out of the box, in English and German. Addresses and company names are opt-in for a good reason.
- A privacy log should store types and counts, never the values. Otherwise the log is the leak.
A question we get a lot: "Is masking just a fancy word for deleting the names?" Fair question. The short answer is no, and the difference is the whole point.
PII means personally identifiable information: anything that points at a specific person, from the obvious email address to a tax number that only means something once you attach a name. PII masking replaces those values with placeholders before the text goes to a system you don't fully control. For us, that system is a large language model.
Masking is not deletion
Redaction destroys information. A black bar on a PDF is gone for good. Masking keeps a mapping. FlowSentric turns "Anna Weber" into [NAME_1], sends the masked prompt to the model, and when the answer comes back, puts "Anna Weber" back wherever the model wrote [NAME_1]. The model never saw the name. You never lost it.
That mapping is request-local. It lives in memory for one call and is thrown away afterwards. For flows that need to restore values in a later request, a workflow step for instance, we keep an encrypted mapping in a short-lived store for at most 24 hours. Then that goes too.
What gets detected
Out of the box, Privacy Guard looks for ten entity types:
| Type | Examples | Default |
|---|---|---|
| Names | Anna Weber, Herr Müller | on |
| Emails | anna@example.de | on |
| Phone numbers | +49 40 123456 | on |
| IBAN / bank accounts | DE89 3704 0044 0532 0130 00 | on |
| Credit card numbers | 4111 1111 1111 1111 | on |
| German tax IDs | USt-IdNr DE123456789, Steuernummer 21/815/08150 | on |
| IP addresses | 192.0.2.10 | on |
| Social security numbers | US SSN formats | on |
| Addresses | Reclamstr. 2, 22111 Hamburg | opt-in |
| Company names | Nordwind AG | opt-in |
Addresses and company names are opt-in, and there's a practical reason. Switched on everywhere, they wreck ordinary prompts: "What is the capital of France?" turns into "What is the capital of [ADDRESS_1]?" We tried it. You turn them on per workspace when the work actually needs them.
Several layers, two languages
No single technique catches everything, so we stack a few:
- Pattern rules are precise for structured values: IBAN checksums, card number patterns, the German tax-ID formats. They always run, as a safety net.
- Industry-standard recognisers cover emails, phones, cards, SSNs, IP addresses, IBANs, people and places.
- Language-aware name recognition finds names and organisations in running text. It understands English and German and picks the language per message, so a German letter is treated as German. Getting this right for German took longer than we expected; capitalised nouns and long compounds confuse a lot of tooling that grew up on English.
There's an optional fourth pass that uses a small local language model to catch what the others miss. It runs on our own infrastructure, never on a third-party API. Otherwise the whole exercise would be a bit pointless.
Where masking happens
Everywhere a model gets called. In chat, Privacy Guard masks the new message and the conversation history. In agents, it masks the system prompt, the retrieved knowledge-base context, the user input and every tool result before the model sees any of it. Widgets on your website default to masking mode. Agents have Privacy Guard on by default; in chat you toggle it, and organisation admins can lock it on for restricted accounts.
What a privacy log should store
A log that stores the masked values would itself be a PII store, which would be absurd. Our Privacy Log stores the entity type, the action and the count per message, plus the source (chat, agent, workflow, widget, session). That is enough to show an auditor that masking ran, and not enough to leak anything if someone exports the log.
Limits you should know about
- Masking works on identifiers, not on context. A unique story can identify a person without a single identifier in it.
- Dates are not detected as an entity type today.
- Detection quality on unusual formats varies. Test with your own documents using the PII tester in Settings before you rely on it.
How masking fits with the rest of our controls is on the security page. Or skip the reading and try it on the Free plan.
