Skip to content
YTT Secunet

Pillar 3 / Zero-egress PII and cross-border guardrail

Identities stay in the jurisdiction they came from.

Names, IBANs, passport numbers and national IDs are detected in the request path and replaced with typed tokens. The mapping sits in a vault in the origin region, so the model gets a coherent prompt and never the identity behind it.

Start 14-day trial Explore demo

Guardrail trace / eu-central

in   Kundin Petra Lindqvist, DE89 3704 ...

out  Kundin <PERSON_1>, <IBAN_1>

vault 2 entries, AES-256-GCM, ttl 24h

route ep_stackit_eu01 / eu01

restore 2 of 2 tokens unknown 0

Masking workbench: pick a prompt, edit it, follow every identifier

The workbench runs the guardrail's pattern layer in your browser: checksum validators for structured IDs, cue-based names with coreference and the health lexicon. Edit the text or flip a class between mask and classify to see what the provider receives, what it sends back, and what your application gets after re-identification in the origin region.

plane eu-central (Frankfurt)eu-gdpr-strict@4.2.0
1Detected in eu-central, in memory5 spans / 4 entities
Draft a reply in German. Ticket: Kundin Petra LindqvistPER (Steuer-ID 86 095 742 719STEU) meldet eine doppelte Abbuchung von ihrem Konto DE89 3704 0044 0532 0130 00IBAN am 3. Juni. Frau LindqvistPER bittet um Antwort an p.lindqvist@example.comEMAI.
Policy action per class (from the pack, editable here)
2Leaves the data plane for ep_stackit_eu010 identifiers in clear
Draft a reply in German. Ticket: Kundin <PERSON_1> (Steuer-ID <STEUER_ID_1>) meldet eine doppelte Abbuchung von ihrem Konto <IBAN_1> am 3. Juni. Frau <PERSON_1> bittet um Antwort an <EMAIL_1>.
3Model response, as the provider returns it
Sehr geehrte Frau <PERSON_1>, vielen Dank für Ihre Nachricht. Wir haben die doppelte Abbuchung vom 3. Juni auf dem Konto <IBAN_1> geprüft und die zweite Buchung storniert. Die Gutschrift erscheint innerhalb von zwei Bankarbeitstagen. Eine Bestätigung geht an <EMAIL_1>. Mit freundlichen Grüßen Ihr Kundenservice
4Re-identified in eu-central before your app sees it3 tokens restored
Sehr geehrte Frau Petra Lindqvist, vielen Dank für Ihre Nachricht. Wir haben die doppelte Abbuchung vom 3. Juni auf dem Konto DE89 3704 0044 0532 0130 00 geprüft und die zweite Buchung storniert. Die Gutschrift erscheint innerhalb von zwei Bankarbeitstagen. Eine Bestätigung geht an p.lindqvist@example.com. Mit freundlichen Grüßen Ihr Kundenservice
Pseudonymization vault / eu-central / conversation conv_0417 never replicated outside eu-central
TokenClassDetectorMentionsVault handleAction
<PERSON_1>Person namecue + coreference2vlt_bfe67698pseudonymized
<STEUER_ID_1>DE Steuer-IDISO 7064 mod 11,101vlt_fb9ebc4bpseudonymized
<IBAN_1>IBANISO 13616 mod 971vlt_04f31a63pseudonymized
<EMAIL_1>EmailRFC 5322 subset1vlt_0ef4d816pseudonymized

Detection classes

Validated, not just pattern-matched

Structured identifiers

Checksummed national and financial IDs

A format match alone produces false positives on order numbers and dates, so every structured detector validates the check digit before it masks. A number that fails its checksum is left alone and counted in the miss report instead.

IBAN
ISO 13616, country length + mod 97 = 1
DE Steuer-ID
11 digits, ISO 7064 MOD 11,10 check digit
FR NIR
13 digits + key (97 minus mod 97), 2A/2B Corsica
UK NHS number
10 digits, modulus 11, weights 10 to 2
US SSN
AAA-GG-SSSS, never 000, 666 or 900 to 999
Saudi national ID
10 digits, 1 citizen / 2 resident, Luhn

Names

Person names with coreference

A multilingual entity model in the data plane finds names; cue words (Herr, Mme, Mr, Kundin, Patient) raise confidence. Coreference links later mentions, so Frau Lindqvist and Petra Lindqvist resolve to one token and the model can still follow the story.

Kundin Petra Lindqvist ... Frau Lindqvist
-> <PERSON_1> ... <PERSON_1>

Travel documents

Passport numbers

Formats differ by issuer (a French passport is two digits, two letters, five digits; a German one is nine alphanumeric characters), so passports are context-anchored: the number must follow a passport cue in any supported language.

Special category

Health terms and ICD-10 codes

Conditions, medicines and ICD-10 codes in English, German and French. By default they are classified, not masked: a clinical summariser needs the diagnosis, so the term raises the data class to health and the router narrows the pool.

How data class narrows routing

Contact data

Email and phone

Email addresses and phone numbers in E.164 and national formats. Masked by default, because a drafted reply needs a slot for the address, not the address itself.

Vault architecture

EU / EEA JURISDICTIONYTT SECUNET DATA PLANE / EU-CENTRALYour appclear text both waysDetect + tokenizechecksums, names, lexiconRestore tokensissued tokens onlyVaultAES-256-GCM entriesttl = conversationWrap keyregional KMS or your HSMModel endpointin-region, ZDRsees tokens onlyOTHER ZONESno vault replicano key accessno route<PERSON_1> <IBAN_1>writeread

Token format

Tokens are typed and numbered per conversation: <PERSON_1>, <IBAN_1>, <NHS_NO_1>. The same value gets the same token within a conversation, so the model can follow references, and a different token in the next conversation, so nobody can link records across them. Tokens carry no hash of the value.

Key custody

Each vault entry is the detected value encrypted with AES-256-GCM under a per-tenant data key. That key is wrapped by a key-management key in the same region as the data plane. On Sovereign Dedicated the wrapping key lives in your HSM, so entries cannot be decrypted without it.

In-jurisdiction storage

The vault is part of the regional data plane: an EU tenant's entries live in eu-central, a Saudi tenant's in me-central. Vaults are not replicated across zones and the control plane never reads them. Entries expire with the conversation, after 24 hours by default, configurable per pack.

Restoration rules

The response passes back through the same data plane. Only tokens issued in this conversation are substituted; an invented or foreign token is held and the response is flagged in the decision log. A reply addressed to <PERSON_1> is awkward; one addressed to the wrong person is a breach.

What is masked, what is classified, what is not touched

Data in the promptDefaultWhyOverride
National IDs (Steuer-ID, NIR, NHS number, SSN, Saudi ID)maskThe model never needs the value, and these are the identifiers regulators ask about first.Per class, per pack. Disabling requires a pack change and review.
IBAN and payment identifiersmaskA drafted reply or summary needs a reference to the account, not the account.Allowed for in-region reconciliation workloads that validate IBANs upstream.
Person namesmaskNames are the most common direct identifier in support and HR traffic.Keep for tasks such as letter salutations if your DPIA accepts it.
Passport numbersmaskTravel document numbers enable identity fraud and are rarely needed for reasoning.Per pack.
Email addresses and phone numbersmaskContact data is a slot in the output, restored on the way back.Per class.
Health terms and ICD-10 codesclassifyClinical tasks need the content. The term sets data class health, which routes to a health-only pool.Switch to mask for tasks that do not need clinical detail.
Quasi-identifiers in free textnot maskedA rare diagnosis, a small town and an age can single someone out. No detector can mask meaning without destroying the task.Mitigated by in-region routing and ZDR, not by masking.
Identifiers in formats no detector coversnot maskedDetection has false negatives. A miss stays inside the jurisdiction because the route is in-region first.Add a custom pattern detector to the pack; measure recall per class.
Image and audio inputsnot inspectedThe guardrail inspects text parts. Binary parts pass through untouched.Packs can deny requests with image or audio parts, or pin them to in-zone endpoints.

The three bottom rows are why masking sits on top of in-jurisdiction routing and never replaces it. Detection reduces what a provider sees; routing decides who can see anything at all.

< 8 ms
p99 added gateway latency, policy evaluation plus receipt minting
YTT Secunet production telemetry, 2026
< 3 ms
median OPA policy evaluation per request
YTT Secunet production telemetry, 2026
0 hops
out of region for a vault lookup: detection, vault writes and restoration run in the tenant's own data plane
YTT Secunet data plane design
80 to 100 ms
typical round trip between Frankfurt and US East (Northern Virginia) before any model compute
Speed-of-light fibre path, public cloud inter-region latency measurements

Latency budget: detection runs alongside policy evaluation inside the gateway's 8 ms p99 envelope. A central vault in another region would add a cross-region round trip to every request, which is why each zone keeps its own.

Guardrail profile as code

Guardrail profiles sit in Git next to your policy packs and routing profiles. Each class gets an action: mask, classify or off. Custom pattern detectors cover your own reference formats, such as claim or contract numbers.

The policy engine sees the outcome, not the text. Its input lists any identifier class left unmasked, so a pack can deny a request that would send a Saudi national ID in clear text, even if someone switched the detector off in a profile.

onDetectorError: fail_closed means a detector timeout returns an error rather than forwarding an unscanned prompt. The decision log records the guardrail profile version for every request, so an auditor can see which masking rules applied.

yamlguardrails/claims-eu.yaml
apiVersion: yttsecunet.com/v1
kind: GuardrailProfile
metadata:
  name: claims-eu
spec:
  detectors:
    person: mask
    iban: mask
    de_steuer_id: mask
    fr_nir: mask
    uk_nhs_number: mask
    us_ssn: mask
    sa_national_id: mask
    passport: mask
    email: mask
    phone: mask
    health: classify          # sets data_class=health
  custom:
    - name: policy_number
      pattern: "CLM-[0-9]{8}"
      action: mask
  vault:
    mode: reversible          # Growth: one_way
    scope: conversation
    ttl: 24h
    wrapKey: kms://eu-central/tnt_de_4417
  onUnknownToken: hold
  onDetectorError: fail_closed

Frequently asked questions

Is pseudonymised data still personal data under the GDPR?

For anyone who holds or can reach the additional information, yes. Article 4(5) defines pseudonymisation, and Recital 26 says pseudonymised data that can be attributed using additional information is still personal data. YTT Secunet keeps that additional information, the vault, in the origin jurisdiction. Treat masking as a supplementary measure that reduces what an importer or provider sees, not as a way out of Chapter V.

Does masking make a US endpoint acceptable for EU personal data?

Not in our packs. eu-gdpr-strict routes to an in-region endpoint first and masks on top of that. No pack uses masking as the reason a request may leave its zone, because detection is never perfect and a missed identifier would then have crossed a border.

What happens when the detector misses an identifier?

It reaches the in-region endpoint in clear text, under that endpoint's zero data retention terms. That is why routing comes first. Each tenant gets a per-class miss report from labelled test traffic, and your DPIA should record the recall you measured for the identifier types that matter to you.

Where are the vault keys and who can decrypt entries?

Each tenant has a data key wrapped by a key-management key in the same region as the data plane. On Sovereign Dedicated the wrapping key sits in your HSM, so decryption needs your key. Vault entries are AES-256-GCM ciphertext and expire with the conversation.

Does re-identification work with streamed responses?

Yes. The restore step holds back a few bytes when a chunk ends in the middle of something that looks like a token, then substitutes once the token is complete. Tokens that were not issued in the conversation are never substituted; the response is flagged in the decision log instead.

Which plans include the reversible vault?

In-path detection and masking are on every plan. Growth masks one way: tokens are not restored in the response. The reversible pseudonymization vault is part of Enterprise Sovereign, and on Sovereign Dedicated it runs in your VPC with your keys.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.

Schedule an architecture demo Start 14-day trial