PII Firewall

Keep personal data out of the model.

The PII firewall finds names, emails, and account numbers in a prompt and swaps them for tokens before any model sees them, then restores the real values in the response. It runs on every request by default, and it is what lets you reach an external model without sending personal data abroad.

Start free Read the docs

detect · pseudonymize · restore

Your prompt 3 detected

Refund Jane Doe for order #4021. Confirm to [email protected], refund the card ending 4242.

What the model sees Tokenized

Refund <PERSON_1> for order #4021. Confirm to <EMAIL_1>, refund the card ending <CARD_1>.

No personal data leaves Akumi.

Your response Restored

Refunded Jane Doe and emailed the confirmation to [email protected].

The best model is often the wrong place to send a name.

To answer a real question, a prompt carries real data: a customer name, an email, an account number, a support ticket. Send that to an external model and you have made a transfer and widened your leak surface. Strip it by hand or with a few regexes and one missed field is a breach. Turn the protection off to ship faster and the gap is invisible until an auditor finds it.

Detect, pseudonymize, restore.

Every prompt runs through the firewall before routing. The work happens in the request pipeline, so the token map never reaches a provider.

Detect An EU-hosted analyzer and your own patterns find names, emails, phone numbers, IBANs, card numbers, and national IDs across the message and tool content.
Pseudonymize Each entity becomes a stable token, so the model keeps the structure it needs to answer while the real value stays behind. The same value maps to the same token.
Restore The token map lives in the request context, never sent to a provider. On the way back, tokens become the real values again, so your response comes out whole.

pii-firewall.yaml api.akumi.cloud

PERSON tokenized

→ <PERSON_1>

EMAIL_ADDRESS tokenized

→ <EMAIL_1>

IBAN_CODE tokenized

→ <IBAN_1>

PHONE_NUMBER tokenized

→ <PHONE_1>

CREDIT_CARD tokenized

→ <CARD_1>

Protection that keeps the answer.

Pseudonymize, do not destroy

Stripping data breaks the answer. The firewall swaps values for tokens and restores them after, so the model has what it needs and your response comes back complete.

On by default

Every request is firewalled unless a tenant admin turns it off and records why. Privacy by design, not a setting you have to go find.

The key to external models

An external or non-EU model is blocked at the egress guard unless the request is firewalled or carries a recorded acknowledgment. The firewall is what opens that door safely.

Pseudonymized is not anonymized. We say so.

The firewall shrinks what you expose and gives you a record of it. It does not make personal data disappear, and we will not pretend it does. The obligations stay yours, so we built the controls to meet them honestly.

Still personal data Under GDPR, pseudonymized data is still personal data. Sending it to a non-EU model is still a transfer that needs the right agreements. The firewall reduces exposure; it does not remove the rules.
Gated, never silent Turning the firewall off takes a tenant admin acknowledgment, recorded with who and when. A single request runs un-firewalled only when that record exists.
Fails closed If a request is not firewalled and has no acknowledgment, routing to an external or non-EU model is blocked, not waved through.
Provable Each request meters on its own line and writes a metadata-only audit trail: how many entities, of which type, never the values. Hand the reviewer the log.

Turn it on before the first token.

Create a key and the firewall is already on. Route anywhere you are allowed, with personal data tokenized on the way out and restored on the way back.

Start free Read the docs