DataShield Ontology v2.2.0
The governed data plane for AI
Ontology is agent-led MDM. It's the governed data plane your agents query. We find the PII and PHI in your data. Then we swap it for tokens at ingest. We widen the quasi-identifiers. So no one row stands out. Your agents get answers, not identifiers. To turn a token back, you need the right. That right is never the default.
We tokenize datasets at ingest. Agents then query that tokenized data over MCP. Detokenization is a special, audited act.
PII tokenization at ingest: the same token every time, joins still work, and you can turn it back under policy
Tokenization happens at ingest, one dataset at a time. We swap each identifier for a token. It carries a TOK_ prefix. The token comes from an HMAC. So it stays the same each time. The same value always maps to the same token. That means joins across datasets still work. The raw value itself never reaches the query path.
The token vault makes tokenization reversible under policy. Detokenization is a special, audited act. We gate and log it, like any other governed call. One-way redaction can't do that. Redact a field once, and you lose it. Gone for every later use. Reversible tokenization is the pseudonymization pattern. EU regulators name it as a GDPR fix (EDPB Opinion 28/2024).
Erasure is crypto-shred. Throw away the key data. The tokens can never come back. The audit chain lives on, whole.
Agent-led MDM and PHI de-identification: classification, quasi-identifiers, golden records
PII/PHI classification and fingerprinting
We scan each dataset at ingest. We label fields as NAME, DOB, MRN, and the rest. Then we fingerprint them. So tokenization works on what the data really is. Access policy does too. Not on the name at the top of the column.
Quasi-identifier generalization
We generalize quasi-identifiers to a configured k. A birth date turns into a decade. A ZIP turns into a region. No one can pin a tokenized row on a person. Not by lining up its fields.
RAG and golden records, governed
RAG retrieval and MDM golden-record mastering run together. Same data plane. Both run over the same tokenized data. They use the same access rules. Those rules know what each field is. They use the same dataset lifecycle controls, too.
The DataShield Analytical DB: analytics over MCP
Agents query governed Parquet datasets over MCP. They go through the DataShield Analytical DB. It ships built in. They get the full SQL they'd get on raw data. But we tokenize the data first. Auth meters each query. It seals each one into the audit chain.
Performance sidebar: 175M rows in 627ms on the DataShield Analytical DB. The method is in the engineering blog. That test measures the query path. Tokenization happens at ingest, not per query.
Want docs, agent definitions and skills served to agents with the same rules? See Corpus, now shipped.
Agent-led MDM is what makes the analytical DB trustworthy. Governed agents master the golden records it serves. A human steward handles the exceptions.
Questions data teams ask first
What is agent-led master data management?
It is MDM where an agent builds it with you. Not a consultant who builds it for you. The agent talks to a business user. It drafts a spec. Then it walks you through a decision gate. Each proposal says what it does, and why. It says what it hits, too. And what else you could pick. You confirm it, or you overrule it. One transaction writes the entity types and hierarchies. It also writes draft match configs and reference bindings. Validation rules land in the same draft. The agent never promotes a config. It never runs resolution on its own.
How does tokenization at ingest protect PII and PHI?
We swap each identifier for a token. This happens as the dataset lands. The raw values never reach the query path. The same value always maps to the same token. So joins still work. Detokenization is a special, audited act, not a default. Throw away the key data. The tokens can never come back. The audit chain stays whole.
Ontology v2.2.0 is in production. Authorization and evidence come from Auth. Agent sessions run from Commander.
Tokenize at ingest. Query it over MCP. Detokenize only under audit. On your own kit, with your own keys.
See pricingYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →