Protecto Vault Jun’26 Release: Expanded Healthcare Entities and Regional Identity Detection
A few years ago, an Australian government health agency released what it believed was a fully de-identified dataset covering 10% of the national population. Names, addresses, and other obvious identifiers had been stripped out. Researchers showed individuals could be re-identified using nothing more than rare medical procedure codes and treatment dates cross-referenced with publicly available information. No names were needed. That incident illustrates a structural gap in how most enterprise data protection works, a gap that is growing more consequential as AI systems take on more of the workflows that handle sensitive data.
The gap traditional PII detection leaves open
Most data protection tooling was built to catch direct identifiers: names, emails, phone numbers, physical addresses, passport numbers, and account numbers. Those fields are obvious, and most platforms handle them well.
The harder problem is quasi-identifiers, fields that do not look sensitive in isolation but become identifying in combination. A diagnosis paired with a ZIP code and an age range narrows a population of thousands down to one person. A medical procedure code paired with a treatment date can do the same. Security researchers who study de-identification have documented this pattern consistently: healthcare teams can remove every direct identifier required under HIPAA and still leave a dataset re-identifiable, because the indirect fields were never masked.
As enterprises route more of their data through AI assistants, copilots, and RAG pipelines, this gap stops being theoretical. A support agent summarizing a patient’s history, or an internal chatbot answering a question about a medical claim, can leak exactly the kind of quasi-identifying detail that traditional masking never flagged. The model sees the field. The model outputs the field. Nothing stopped it.
What this release adds
The newest update extends Vault’s detection engine into two categories that traditional PII tooling has historically left uncovered: healthcare-specific entities and country-specific compliance identifiers.
Healthcare entities now supported:
| Entity | What it covers |
|---|---|
| BIOMETRIC_DATA | ! Physical and biological health measurements in patient records, such as BMI, height, and weight |
| BLOOD_TYPE | ! Blood group classifications |
| MEDICAL_CODE | ! ICD, CPT, and other clinical coding systems |
| MEDICAL_CONDITION | ! Diagnoses and clinical findings |
| MEDICATION | ! Drug names, dosages, and prescription data |
| MEDICAL_PROCEDURE | ! Surgical and clinical procedures |
Regional compliance identifiers now supported:
| Entity | Region |
|---|---|
| ! AADHAAR (12-digit national identity number), GSTIN (business tax registration number) |
India |
| ! UK_UTR (Unique Taxpayer Reference), UK_NIN (National Insurance Number) |
United Kingdom |
| ! US_ITIN (Individual Taxpayer Identification Number) |
United States |
| ! CANADIAN_SIN (Social Insurance Number) |
Canada |
| ! PH_TIN (Tax Identification Number) |
Philippines |
Each of these entities is detected and masked the same way Protecto Vault handles every other entity type: with context-preserving masking that keeps the surrounding data usable for AI reasoning, and consistent tokenization so the same entity maps to the same protected token every time it appears within a configured scope. Teams do not need to write or maintain custom detection logic per country or per healthcare data type. The detection is built in.
Why this matters in agentic AI, not just static datasets
This is not a database compliance problem. It is a runtime problem. In agentic AI systems, sensitive data moves through prompts, retrieved context, tool outputs, and agent memory, often across multiple systems in a single interaction. A finance agent processing a claim that includes a national tax identifier, or a healthcare agent retrieving a patient’s procedure history, is running exactly the kind of workflow where entity-based sensitive data needs enforcement at the point it moves, not a one-time review before the data is stored.
This also maps directly onto existing regulatory coverage. Under HIPAA, clinical information such as diagnoses, medications, procedures, and medical codes may constitute PHI when associated with an identifiable individual. AADHAAR maps to India’s Digital Personal Data Protection Act, which enters its enforcement phase in 2026 with rules that explicitly treat these identifiers as personal data requiring protection. Similarly, national and tax identifiers may be personal data under applicable healthcare privacy laws when they relate to an individual.
Regulatory pressure on using exactly this kind of data on AI has been building across every region. The EU AI Act’s transparency obligations land in August 2026, with high-risk system obligations following from December 2027. Regulators across sectors are converging on the same expectation: organizations need to show, concretely, what sensitive data their AI systems can see and how it is protected, not just assert that it is handled responsibly.
What doesn’t change
No breaking changes. Existing APIs and workflows built on Protecto Vault remain fully compatible. Teams already running Vault in production get the new entity coverage without re-architecting anything.
Who Benefits from This Feature
- Healthcare organizations that need to screen patient records before any AI workflow touches them.
- Financial services teams that need to detect country-specific tax identifiers alongside standard customer identity data.
- Insurance carriers whose claims processing routinely surfaces PHI.
- Government agencies whose citizen records include national identifiers by definition.
- Multinational enterprises that previously needed separate detection logic per region.
