What PII does data protection mask?

Structured masking (Starter and up) catches checksum-verifiable PII: email addresses, IBANs, credit card numbers, Dutch BSNs, and phone numbers, replacing each with a bracketed placeholder like [EMAIL] or [IBAN]. Free-text masking (Team and up) adds detection of names and addresses in prose, run through a dedicated NER model over the already-masked text.

Where does scrubbing run?

On every tool-call result, error message, and progress message a project's MCP endpoint streams back - before any of it reaches an agent, the dashboard's bring-your-own-key chat, or the Playground. It runs on the full, untruncated payload first, so a value is never cut in half before it's checked.

What happens if a result can't be scrubbed?

Data protection fails closed: a payload it can't fully walk (cyclic, too deeply nested, or an unscrubbable shape) is never forwarded unmasked. The tool result is withheld instead, with an explicit 'could not be scrubbed for PII' message in its place.

How do I check it's actually working?

Call any tool from the project's Playground tab. Each result shows a one-line PII status underneath it - what was masked and how many, a clean 'no PII found', or a withheld notice - so you can confirm scrubbing is live on a real response before pointing an agent at the server.

Why did Tier 1 mask a number that is not a BSN?

Tier 1 verifies an 8- or 9-digit number against the Dutch BSN checksum before masking it, but that checksum is not unique to real BSNs - roughly 1 in 11 random numbers of that length pass it too. An order number or reference code can occasionally come back as [BSN]. It is tuned to over-mask rather than miss a real citizen number, so this is expected behavior.

Use your server

Data protection

Q: Why did free-text masking mask a word that is not a name?

It uses a language model, not a fixed pattern, so it can occasionally mask a capitalized common word - a grocery item, a product name - as [NAME]. It is tuned to over-mask rather than miss a real name, so this is expected behavior.

When it's on, every tool-call result, error, and progress message a project sends back is masked for PII before it reaches an agent or your browser - a raw record with a real email, IBAN, or name in it never leaves the platform unredacted.

What gets masked?

Structured masking, available from the Starter plan, catches PII a regex plus a checksum can verify deterministically: email addresses, IBANs, credit card numbers, Dutch BSNs, and phone numbers. Each match is replaced with a placeholder that names what was there - [EMAIL], [IBAN], [CREDIT_CARD], [BSN], [PHONE] - so the shape of a response survives even though the value doesn't.

The BSN check verifies the Dutch 11-proof checksum before masking a number, but that checksum is not unique to real BSNs - roughly 1 in 11 random 8- or 9-digit numbers pass it too. An order number or reference code can occasionally be masked as [BSN]. Data protection is tuned to over-mask rather than miss a real citizen number, so this is expected behavior, not a bug.

Free-text masking, available on the Team plan, runs a second pass over the same text looking for names and addresses written in prose - the kind of PII no regex reliably catches. It always runs after structured masking, so an email or IBAN already masked is inert to it and nothing is ever double-counted.

Free-text masking uses a language model to spot names and addresses, not a fixed pattern, so it can occasionally mask a capitalized common word - a grocery item, a product name - as [NAME]. Data protection is tuned to over-mask rather than miss a real name, so this is expected behavior, not a bug.

Where does it run?

Data protection sits in the same stream every tool call already goes through - it scrubs the result, the error text, and any progress messages a long-running tool reports, before any of it is written back to the caller. That covers an agent connected over MCP and the dashboard's own Playground and chat equally - there's no second, unscrubbed path either one could see.

Masking always runs against the full, untruncated payload first. If a result also gets trimmed down for size, that happens afterward - so a value never gets cut in half first and left in a shape the scrubber can no longer recognize.

What if a result can't be scrubbed?

Data protection is built to fail closed. If a payload can't be fully walked - it's cyclic, nested unreasonably deep, or otherwise not a shape the scrubber can safely traverse - the result is never forwarded as-is. Instead the tool result is withheld, with a message explaining that it couldn't be verified PII-free, rather than risk handing an agent something that was never actually checked.

Try it yourself in the Playground

The fastest way to see data protection working is to use it: open a project's Playground tab, enable data protection in the project's MCP settings, and call a tool that returns something with an email, phone number, or IBAN in it. The result panel shows a per-call line underneath the response - how many values of each type were masked, or a clean "no PII found" when there was nothing to catch - so you can confirm it's live on a real response before wiring the server into an agent that isn't you.