Head-to-head · updated 13 September 2026

DataShield vs Tilores: your agent resolved the customer, but who said it could read the record?

Tilores is a real-time entity resolution API, and it is good at that one job. Send it records, get a resolved entity back in about 150ms, or a claimed 1ms if you run it yourself. A free local Studio covers your first 100,000 records. There is a tilores-langchain package for LangChain and LangGraph. Since July there is an MCP server that helps an assistant design and lint your matching rules. Since May 2026 they call the pattern IdentityRAG: resolve the customer first, retrieve second. It is a clean idea, and they write about it better than most.

We arrive from the governance side of the same problem. Ontology does the linkage too, with Fellegi–Sunter probabilistic record linkage and the usual comparator zoo. But the part we sell is what happens after the merge. Golden records reach agents through views that mask without asking. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Auth re-checks the agent's authority on every governed tool call. It seals the decision into a hash chain you can verify. Below is the honest split, including the rows Tilores wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

The resolved record is the sensitive thing. Our golden views mask unconditionally, and the strategies are named: dates to year, decade or age band, ZIPs to 3 or 4 digits, partial phones, SSNs and emails, each with a measured cardinality-reduction score. See the data plane.
Someone will ask you to prove which two people an agent decided were the same person in March, and that the log was not edited since. Our chain answers with math. Run the verifier.
You need to pull an agent's authority mid-session and have the next governed tool call fail. Not the next token refresh.
You want matching, field classification, tokenization, stewardship and the audit trail from one stack you host yourself, and you would like a price before a sales call.

Pick Tilores when

Latency is the whole requirement. A fraud check at checkout cannot wait for a batch job, and they publish sub-150ms end to end with matching in single-digit milliseconds.
Your team wants to try it tonight. Tilores Studio runs locally and free up to 100,000 records. We do not have that.
You are building in LangChain or LangGraph and want typed tools today. Their PyPI package is real, and our SDK story is thinner.
You need SOC 2 on the paperwork now. They have it. We do not, and we are not going to imply otherwise.

Bottom line: Tilores resolves the customer fast. We govern the record that comes out and keep proof of who read it. Their own guide to access control in a RAG pipeline lists six rules. Then it hands you four and a half of them to build. That build is our product.

Feature by feature

Competitor cells describe what Tilores publishes on tilores.io as of the date above. If we have mischaracterised something, email support@myorg.ai and we will correct it, credited.

What matters	DataShield	Tilores	Edge
Resolution latency	Matching runs inside Ontology against real source values. We publish no latency figure and will not invent one. This is not a sub-second fraud-check engine.	The core claim and a good one: sub-150ms end to end on the hosted GraphQL API, matching itself in single-digit milliseconds, sub-300ms ingest.	◇
Matching method	Fellegi–Sunter probabilistic record linkage with Jaro-Winkler, Levenshtein, Soundex and Double Metaphone comparators, LSH blocking, EM-trained m and u parameters, and Population Stability Index drift monitoring on every promoted match config.	Deterministic plus ML-based fuzzy matching with explicit, auditable rules. The method is described well in their content, but the internals are not named the way ours are.	◆
Golden records and survivorship	Five declarative survivorship strategies, an absolute-identifier tier that routes identifier conflicts to a review queue instead of merging them blind, confirmed goldens, governance overrides, and a stewardship queue with a blast-radius dry run before you commit.	Resolved entities with per-attribute attribution, and a published set of survivorship rules for safe CRM merges. Stewardship workflow is not a product surface we could find.	◆
Masking on the resolved record	The golden view family masks unconditionally and ignores the deployment posture by design. A tokenized-at-rest matching field makes the run refuse with a typed error rather than mega-merge.	A @hasPrivilege GraphQL directive can restrict fields, and OAuth tokens can be narrowed. Both are things you configure, not defaults you inherit.	◆
Agent authorization	On Auth's MCP surface every governed tool call passes a scope ceiling, an authority tier and a mid-session revocation re-check before dispatch, then gets metered and attributed to the agent. Ontology's own MCP server authenticates with scoped API keys and per-tool tier gating, which is a weaker seam, and we would rather say so than blur it.	Their access-control guide tells you to bind retrieval to the requester's permissions and scope the query itself. The enforcement logic is yours to write.	◆
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification returns clean, attested damage or tampered, and names truncation gaps. Try the verifier.	A thoughtful post on what a match audit trail should hold: record IDs, normalized values, rule versions, scores, threshold bands, reviewer paths. No tamper evidence, signing or chaining is described.	◆
Break-glass	Scoped, time-boxed emergency access for agents, admin and IP-allowlist gated, step-up challenged, fully audited, auto-revoking.	Not described in their public material.	◆
GDPR erasure	Crypto-shred of per-subject key material plus ISO 27560 consent receipts, and a consent-validity substrate recording a lawful basis per subject and purpose. The audit chain still verifies afterwards.	GDPR compliance is claimed and they write well about deletion duties. The erasure mechanism on a resolved entity is not spelled out.	◆
Tokenization and classification	Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Fields are classified against 129 built-in PII, PHI, financial and secret classes, deterministically, with reproducible verdicts.	Neither is in scope. Tilores resolves identities; deciding which fields are sensitive is your job or another vendor's.	◆
MCP and agents	More than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse, including 99 MDM commands. Agents read goldens, work stewardship queues and act, under tool tokens.	An MCP server since 21 July 2026, honestly scoped: stateless, read-only, no customer data, tools for capabilities, query recipes, parameter validation and rule linting. The endpoint is public and needs no API key. Plus a tilores-langchain package with typed tools.	◈
Deployment	Self-hosted in your own cloud or data center, or a dedicated single-tenant server we operate. Docker images for Auth, Ontology, Corpus and Lighthouse, with a signed deploy manifest Guardian verifies. Ed25519 audit-signing keys can live in your KMS or HSM. HMAC tokenization keys sit in your environment today, not in a KMS.	Managed AWS, your own AWS account, another cloud, or fully on-prem and air-gapped. AWS Marketplace listing and an AWS partnership.	◈
Maturity and compliance	Live in production, with Guardian and Lighthouse running since April 2026. SOC 2 not yet certified, and we say so on every page.	Founded 2021, SOC 2 certified, named customers including Exiger, Inato, Grover and Cofinity-X, and Carahsoft distribution to US government agencies since March 2026.	◇
Pricing	Published model and a scoped instant quote with no sales wall.	Free Studio to 100,000 local records, then quote only. Paid pricing counts Unified Customer Records, so 10 million rows that resolve to 4 million people bill as 4 million. That unit is fair and clearly explained. No figures are published.	◆

◆ DataShield leads◇ Tilores leads◈ comparable

Tilores claims are drawn from tilores.io and its content library, last checked 13 September 2026. We link the sources below rather than work from memory.

Three things you get here that you won't get from an entity resolution API

A golden record that arrives already masked

Resolution makes data more sensitive, not less. Three partial records become one person with a name, a birth date and a card. Our golden views mask without consulting any posture setting. A matching field that is tokenized at rest refuses the run rather than merging everything into one blob. How the data plane works.

Authority that can change mid-flight

An analyst leaves on a Friday. Their agent is 20 minutes into a 40-minute reconciliation job. With DataShield the next governed tool call is re-checked against current authority and fails closed. A field-level directive set at build time does not know anything has changed. How Auth does it.

Proof of the merge, not just an explanation of it

Tilores is right that a reviewer should be able to reconstruct a match without guessing. We agree. Then we ask the next question. How do you know the record of that match is the one you wrote? Ours is a hash chain with signed checkpoints, and the verifier names the failure. Try it in your browser, no signup.

Where Tilores is genuinely stronger

Their latency story is real and we cannot match it. Sub-150ms end to end. Single-digit milliseconds for the match itself. Sub-300ms ingest, on a serverless AWS architecture, with no cluster to babysit. If the resolution sits inside a checkout flow, that number is the requirement. Everything else is decoration. The developer on-ramp beats ours too. A free local Studio to 100,000 records. A LangChain package on PyPI. An MCP server for design work. A pricing unit that counts resolved people, not raw rows. They are SOC 2 certified. They reach US agencies through Carahsoft on four contract vehicles. They carry customer names we do not have yet. A smaller team than most of their rivals has shipped a lot.

Here is the push-back, and it comes from their own writing. In August they published six rules for controlling access to resolved customer data in a RAG pipeline. Bind retrieval to the requester's real permissions. Scope the resolution query rather than filtering after the fact. Keep the enforcement boundary inside infrastructure you control. Log what was retrieved and why. We would sign all six. What Tilores ships against that list is a field-level GraphQL directive and OAuth token narrowing. The permission context is yours. So is the query-time authorization, the prompt trimming, and the log that records why access was allowed. So the resolved entity, the most re-identifying object in your estate, lands in your agent's context. It gets whatever controls your team got around to building last sprint. That is the gap we fill, and we would rather fill it than pretend the match itself is the hard part.

Questions worth asking both of us

These are the questions we would want answered if we were the ones buying. Ask them on every call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes. Each record commits to the one before it, checkpoints are Ed25519-signed and chained, and verification tells deletion apart from truncation and from tampering. Run it against a sample chain at /verify. Tilores sets a good bar in their June 2026 post: an audit trail should let a future reviewer reconstruct the match without guessing. It describes no signing, chaining or tamper evidence. Ask them what stops an admin editing the row.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so revocation lands on the next call. Tilores narrows OAuth tokens per requester and restricts fields with a @hasPrivilege directive, both set before the call. We found no mid-session revocation mechanism in their public material. Ask how long a compromised agent keeps reading resolved customers after you pull its access.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds per-subject key material and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the evidence still verifies once the subject is gone. Tilores claims GDPR compliance and writes well about deletion. We could not find the mechanism for erasing a person from a resolved entity while keeping the match history defensible. Ask for the mechanism, not the policy.

Is DataShield a real entity resolution engine, or is this a governance wrapper?

It is a real engine. Fellegi–Sunter probabilistic record linkage. Jaro-Winkler, Levenshtein, Soundex and Double Metaphone comparators. LSH blocking, EM-trained parameters, five survivorship strategies, and drift monitoring on promoted configs. What it is not is a low-latency API for a checkout path. If you need a resolution answer in 100ms inside a payment flow, buy Tilores. If the resolved record then feeds agents, analysts and an auditor, the governance is the harder half and it is ours.

Tilores ships an MCP server too. What's different?

Theirs, from July 2026, is deliberately narrow. Stateless, read-only, no customer data, and a public endpoint with no API key. Its tools help an assistant discover capabilities, generate GraphQL recipes, validate search parameters and lint rules. Good design for build time, and their own advice is to keep personal data out of it. Ours is where the governed data is actually queried. The tool token carries a scope ceiling, the call is authorized before dispatch, and the decision is sealed into the chain. If you want an agent to help write your matching rules, use theirs. If you want an agent to read resolved people under a policy you can later prove, use ours.

Does DataShield have SOC 2?

No, and Tilores does, so score that row for them. What we offer instead is checkable. A published threat model. A verifier anyone can run in a browser. Auth live in production, with Guardian and Lighthouse since April 2026. Design-partner terms with source escrow, so a small vendor is not a single point of failure. Details on the security page.

Tilores positioning: "One trusted view of every <customer>", real-time entity resolution with ~150ms query response, 1ms self-hosted, and SOC 2 certification. — tilores.io, 13 Sep 2026
IdentityRAG: resolution before retrieval, sub-150ms end to end, matching in single-digit milliseconds, with a tilores-langchain package for LangChain and LangGraph. — tilores.io, 19 May 2026
The Tilores MCP server is stateless and read-only, stores no customer data, and its endpoint is public with no API key; its tools cover capability discovery, query recipes, parameter validation and rule linting. — tilores.io, 21 Jul 2026
Six rules for access control on resolved customer data. Tilores supplies a @hasPrivilege field directive and OAuth token narrowing; permission context, query-time authorization and the "why was this allowed" audit log are the customer's build. — tilores.io, 25 Aug 2026
"An audit trail should make a future reviewer able to reconstruct the match without guessing." No tamper evidence, signing or chaining is described. — tilores.io, 15 Jun 2026
Pricing counts Unified Customer Records, not raw rows: 10 million records resolving to 4 million customers bills as 4 million. Tilores Studio is free locally to 100,000 records. No figures published. — tilores.io/pricing, 13 Sep 2026
Carahsoft appointed Master Government Aggregator for Tilores, distributing via ITES-SW2, NASPO ValuePoint, TIPS and OMNIA Partners vehicles. — tilores.io, 19 Mar 2026

Other head-to-heads

Entity resolution

Get free Demo Center access

You've seen the proof

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

Get your quote →