Get an instant quote

DataShield Ontology v0.24.1

The governed data plane for AI

Classify PII/PHI, tokenize at ingest, generalize to k-anonymity — agents get answers, not identifiers. Detokenization is a privilege, not a default.

Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation.

Verify a sample audit chain yourself Read the architecture
PII in, tokens out Source rows are classified, deterministically tokenized, and generalized at ingest; agents query governed Parquet over tokens, joins still work, and detokenization is a gated privileged operation. Source data Jane Doe · 1985-03-02 MRN 88231 INGEST PIPELINE Classify NAME · DOB · MRN Tokenize deterministic HMAC Generalize k-anon: 1985-03-02 → 1980s TOK_9c1f… · TOK_44ab… · TOK_e07d… Governed Parquet tokens only Agent via MCP Analytical DB query over tokens TOK_9c1f… = TOK_9c1f… ⋈ joins still work Token vault crypto-shred = GDPR erasure audit chain survives privileged? logged? detokenize unauthorized EVIDENCE LANE Ed25519 checkpoint verify_chain → VALID

PII tokenization at ingest: deterministic, join-preserving, reversible under policy

Tokenization happens at ingest, per dataset. Identifiers are replaced with deterministic HMAC-derived tokens (TOK_ prefix), so the same value always maps to the same token — joins across datasets still work, but the identifier is gone from the query path.

The token vault makes tokenization reversible under policy: detokenization is a privileged, audited operation, gated and logged like any other governed call. One-way redaction can't do this — once redacted, the data is destroyed for every downstream use. Reversible tokenization is the pseudonymization pattern EU regulators name as a GDPR mitigation (EDPB Opinion 28/2024).

Erasure is crypto-shred: destroy the key material and the tokens become irrecoverable, while the audit chain survives intact.

Tokenized data changes your breach math An exfiltrated raw-PII dataset is a notifiable trove of identifiers with full breach-notification and fine exposure; an exfiltrated tokenized dataset is a token set, not identifiers — and EU regulators (EDPB 28/2024) name pseudonymization as a GDPR mitigation before an incident. Join-preserving tokens keep analytics and entity resolution working. IF THE DATA PLANE IS BREACHED Raw PII dataset exfiltrated → a notifiable trove of identifiers full breach-notification and fine exposure Tokenized dataset exfiltrated → a token set, not identifiers EDPB 28/2024: regulators name pseudonymization as a GDPR mitigation — before an incident Same value → same token joins and entity resolution still work — analytics intact Smaller blast radius. Lower notification and fine exposure. The data stays useful.

PHI de-identification for AI agents: classification, k-anonymity, and governed access

PII/PHI classification and fingerprinting

Datasets are scanned at ingest: fields classified (NAME, DOB, MRN, and the rest) and fingerprinted, so tokenization and access policy operate on what the data actually is, not on column names.

k-anonymity generalization

Quasi-identifiers are generalized to a configured k — a birth date becomes a decade, a ZIP becomes a region — so a tokenized row can't be re-identified by combination.

RAG and golden records, governed

RAG retrieval and MDM/golden-record mastering run inside the same data plane, over tokenized data, with the same classification-aware access rules and dataset lifecycle controls.

The DataShield Analytical DB: analytics over MCP

Agents query governed Parquet datasets over MCP through the embedded DataShield Analytical DB — full analytical SQL over tokenized data, with every query metered and sealed into the audit chain by Auth.

Performance sidebar: 175M rows in 627ms on the DataShield Analytical DB — methodology in the engineering blog. That benchmark measures the analytics path; tokenization happens at ingest, not per query.

Need documentation, agent definitions, and skills served to agents with the same governance? See Corpus, now shipped.

Warehouse-class analytics, no warehouse bill The DataShield Analytical DB queries 175.8 million rows in 627ms on a single VPS, with no separate database to license or run. Queries stay metered and sealed into the audit chain, and benchmark numbers are published with hardware and warm/cold state or not at all. ANALYTICS IN THE GOVERNED PLANE 627ms to query 175.8M rows DataShield Analytical DB · on one VPS No separate database to license or run Queries stay metered and sealed into the audit chain Cold + warm numbers published with hardware — or not at all Warehouse-class speed at the cost of a file on disk. No warehouse bill.

Ontology v0.24.1 — in production. Authorization and evidence by Auth; supervised by Guardian.

Tokenize at ingest, query over MCP, detokenize only under audit — on your infrastructure, with your keys.

See pricing

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →