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. It is good at that one job. Send it records. Get a matched record back in about 150ms. Run it yourself and they claim 1ms. Their site says 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 too. It helps an assistant design and lint your matching rules. Since May 2026 they call the pattern IdentityRAG. Match the customer first, fetch second. It is a clean idea. They write about it better than most.

We come at the same problem. But as a master data platform built for agents. Ontology does the linking too. It uses Fellegi-Sunter statistical record linking and the usual comparator set. What we sell is wider than the match, though. An agent can build the model with you. It interviews a business user. It writes a plan. Then it walks a decision gate you approve one answer at a time. One save writes the entity types and trees. Plus draft match setups and check rules. None of it goes live until it passes a test run. After that, a golden record still has to earn the right to be read. It clears six quality checks. It clears a consent check that can block it. Then it comes back through a view that masks it. Data gets tokenized at intake. Agents query tokenized data over MCP. Detokenizing is a locked-down, logged step.

Auth re-checks the agent's power on each controlled tool call. Below is the honest split. It includes the rows Tilores wins.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

You need the model built, not just the matches. An agent interviews a business user. It writes a plan. It walks a decision gate with you. Reset one answer, and each linked answer flips back for review. Then one save writes the entity types, trees, draft match setups, reference links, and check rules. All of it lands as a draft. See the data plane.
The matched record is the sensitive thing. A golden has to earn the right to be read by an agent. Six quality checks, all above their floors. Plus a consent check that fails closed with no lawful basis on file. The golden consumption view and the SQL views mask in the view and the reader role. Not in a setting.
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. You can pull an agent's power mid-session, too. The next controlled tool call then fails. Run the verifier.
You want matching, stewardship, field classification, tokenization and the audit trail from one stack. You host it 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. They publish sub-150ms end to end, with matching in single-digit milliseconds.
Your team wants to try it tonight. Tilores Studio runs locally, 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. Our SDK story is thinner.
You need SOC 2 on the paperwork now. They have it. We do not. We are not going to imply otherwise.

Bottom line: Tilores matches the customer fast. That is a real job. We build the model with you instead. We make the golden record pass a gate before an agent reads it. We keep proof of who read it, too. 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
Standing up the model	An agent does it with you. `mdm_project` interviews a business user and writes a plan. It presents a gate, one step after another. Each step shows a what, why, impact and alternatives body. You confirm or reset it. A reset flows through to each linked step. There is deliberately no accept-all button. Then one clean save creates the entity types and trees. It also creates draft match setups, reference links and check rules. Each object lands with an honest gate state. The builder never promotes a setup on its own. It never runs matching on its own. It never skips the test run. 15 commands, no implementation services.	Tilores Studio and the MCP server help a developer design and lint matching rules. The docs are good. There is no interview, no plan and no built model. The schema and the rules are yours to write.	◆
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 fuzzy record linking. Per-field comparison levels, with m and u odds. Match weight is log2(m/u), added across fields. Comparators: exact, Jaro-Winkler, normalized Levenshtein, Soundex, Double Metaphone, n-gram and date proximity. LSH blocking caps bucket size, so common names do not blow up. Settings are trained against a frozen holdout. A trained polarity flip is a hard refusal. No setup reaches production without a green paired-gate test run through the real scoring path. A trial is read-only. It warns when your blocking yields zero pairs. Population Stability Index drift watch checks each promoted setup. It flags; it never acts on its own. Checked against roughly 370,000 real public records across three City of Chicago data sets. We publish no record-count ceiling and no accuracy figure.	Deterministic plus ML-based fuzzy matching, with explicit, auditable rules. The method is named well in their content. But the internals are not named the way ours are. Their own 2025 post claims 150 million records at 99.5% accuracy in 36 hours. That figure is theirs, not ours to check.	◆
Multidomain modelling	An open entity-type list, with three wired matching modes per type. Business groups are People, Places and Things. They are held as table rows, not an enum you have to bend. Trees are parent-scoped. A child setup matches inside its parent's scope at a base threshold. Across parents, it matches at a stricter one, with rollups. Links carry two-sided validity. Domains carry an owner and a rule set. You model your domain. We do not ship a packaged Customer 360 you have to unpick.	There is a matched-record layer with per-field credit. That is the right building block. Trees, links with validity dates and domain ownership are not product surfaces we could find.	◆
Ingestion and binding	Six on-ramps: inline records, a URL, batch ingest, storage watch sources, a file repo. Plus a catalog link to a live PostgreSQL object, with no rows leaving it. Link a table to an entity type once. Mastering then stays fresh on a set schedule. It runs under an `auto`, `agent_review` or `steward_review` remaster rule. A weekly full pass cleans up deletes. Partial loads mark deleted source records stale and updated records for a re-check. Delta matching refuses rather than quietly growing into a full scan. That is PostgreSQL today, not your whole estate. We are not an ETL product and will not sell you one.	Prebuilt connectors, webhooks and sub-300ms ingest on their hosted service. For a team streaming events at a fraud check, that on-ramp is better than ours.	◈
Golden records and survivorship	Five set survivorship rules: most trusted, most recent, longest, most frequent and combined. Each is written as a plain fold function, so the same spec compiles to SQL. Most trusted uses measured source trust, not a hand-ranked list. That means how often a source's calls get overturned in stewardship. A top identifier tier means a clean identifier hit never blind-merges. A contradicted pair goes to review, tagged with its conflict type. Merge, separate, defer and link are all first-class calls with inverses. Link keeps two records apart while noting the link they share. Confidence is honest. A fuzzy match carries a number. A steward match carries null, never a fake 0.0. Version history is append-only and survives deletion. A tombstone records the reason and what came after.	Matched records with per-field credit. Plus a public set of survivorship rules for safe CRM merges. Stewardship workflow is not a product surface we could find.	◆
Stewardship and trust	Stewards review patterns with proof, not items one at a time. A counter-check scan keeps each proposal honest. One human call closes out a pattern. A three-rung trust ladder controls automation. 50 approvals at a 98% rate, with zero pushback, promotes a pattern. A single pushback demotes it. At the top rung, a fixed sampler routes 10% of auto-closed items to human audit. That way you can prove why any item was picked. Standing disposal rules start staged. They need a second, clear release call. They auto-pause on an audit overturn, and you can undo them. Each dry run is provably side-effect-free. It runs the writer's own gate function. So a preview cannot say yes and then refuse. There is a dashboard, too. A flow map, a per-gate workbench, and a records view. It is MCP-first, so an agent can work the same queue.	Matched records with per-field credit. Plus a public set of survivorship rules for safe CRM merges. A stewardship product surface is not something we could find in their public docs.	◆
The agent-admission gate	A golden record has to earn the right to be read by an agent. Combined trust of at least 0.70 over six named quality checks. Each check must clear its own floor. Plus a consent block that fails closed. One rule enforces it, shared by the SQL and the TypeScript paths. That way the two cannot drift. Consent rests on a lawful-basis base. It covers all six GDPR Art. 6(1) bases across nine purposes. It is add-then-replace: one live fact per subject and purpose. No recorded basis means no permission. Only the derived consent score crosses the masking line. The consent facts themselves are not handed to the golden-view reader. Accuracy and conformity score only where you have written check rules, and we say so.	No equal. Field access is limited by a rule you set up. Data quality and consent are not gates on the read.	◆
Masking on the matched record	The golden consumption view and the versioned SQL views mask with no exceptions. The mask lives in the view and the reader role. The reader has no grant on the base table. It cannot be bypassed, even from SQL. Masking is byte-identical between the SQL views and the app's read path. It is enforced as a fail-closed release gate. Derived phonetic and n-gram fields inherit their base field's PII verdict. That means a name cannot be rebuilt from its Soundex. And `golden_read` tells you what it left out and why. It does this per exclusion type, under your own filters. A matching field tokenized at rest 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 set up, not defaults you inherit.	◆
Agent authorization	On Auth's MCP surface each controlled tool call passes a scope ceiling. It also passes a power tier and a mid-session revocation check before dispatch. Then it gets metered and tied to the agent. Ontology's own MCP server checks in with scoped API keys and per-tool tier gating instead. That is a weaker seam, and we would rather say so than blur it. Under both, the mastering side keeps its own guardrails. Guarded steps clear a canary before they ramp up. Scope-keyed pause and kill flags stop a run mid-flight. A microbatch can roll back to its pre-image marker.	Their access-control guide tells you to bind fetches to the requester's permissions. It says to scope the query itself, too. The enforcement logic is yours to write.	◆
Audit evidence	SHA-256 hash chain, with Ed25519-signed checkpoints that are themselves chained. Checking it returns clean, marked damage or tampered, and names gaps left by truncation. Underneath it, each in-place control change writes a fixed before-and-after row. Both land in the same save. So a merge, an unmerge, a pin and a reset all leave a record. You never had to remember to keep it. 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 proof, signing, or chaining is shown.	◆
Break-glass	Scoped, time-boxed emergency access for agents, admin and IP-allowlist gated, step-up challenged, fully audited, auto-revoking.	Not shown in their public docs.	◆
GDPR erasure	Crypto-shred of per-subject key material, plus ISO 27560 consent receipts. This sits over a base of consent facts. It records a lawful basis per subject and purpose. The change stream carries no values by design, so it needs no purge cascade. Golden version history survives the delete as a tombstone with the reason and what came after. The audit chain still checks out afterwards. Recommendations never auto-act on a person. A pinned firewall keeps the scorer out of the decision writer. That is GDPR Art. 22 by design.	GDPR compliance is claimed and they write well about deletion duties. The erasure step on a matched record is not spelled out.	◆
Tokenization and classification	Data gets tokenized at intake. Agents query tokenized data over MCP. Detokenizing is a locked-down, logged step. Fields are classified against 129 built-in PII, PHI, financial and secret classes. It happens the same way every time, with repeatable verdicts. Matching then runs on real source values. A matching field tokenized at rest makes the run refuse instead. It throws a typed error. It never merges everything into one blob.	Neither is in scope. Tilores resolves identities. Deciding which fields are sensitive is your job. Or another vendor's.	◆
MCP and agents	143 MCP commands for master data alone. That is 32% of the platform's agent surface. It sits inside more than 200 tools across Ontology, Auth, Corpus and Lighthouse. Agents build the model. They train and test a setup end to end. They run matching, work stewardship queues, and read goldens. All under tool tokens. Reads are agent-shaped too. A value-free CloudEvents 1.0 outbox carries 21 event types. Delivery is exactly-complete, in commit order. RAG grounding documents come only from agent-ready goldens. Chunks get hard-deleted when a record leaves the gate. Golden-to-source lineage is there for you to trace. A masked golden view can be joined in DuckDB. The reader role provably cannot select the base table.	An MCP server since 21 July 2026, honestly scoped. Stateless, read-only, no customer data. Tools for features, query recipes, parameter checks and rule linting. The endpoint is public and needs no API key. Their own advice is to keep personal data out of it. Plus a tilores-langchain package with typed tools. It is a build-time surface, not an agent data plane.	◆
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 checks. Ed25519 audit-signing keys stay on your instance, in a key folder you control. Kid-keyed rotation fails closed on an unknown key. KMS or HSM custody is a built-in seam in Auth, not a shipped link. 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 each page.	Founded 2021. Their site says SOC 2 certified, and names Exiger, Inato, Grover and Cofinity-X as customers. Carahsoft has sold to US government agencies since March 2026. Their own 2025 post claims 150 million records matched in 36 hours.	◇
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, not raw rows. 10 million rows that resolve to 4 million people bill as 4 million. That unit is fair and clearly explained. No figures are shown.	◆

◆ 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 model an agent builds with you

Most mastering projects stall before the first match. Everyone is stuck in a room arguing about what a customer is. Our answer is a conversation. An agent interviews the business user, writes a plan, and walks a decision gate. Each step says what it is and why. It says what it affects and what else you could pick. You confirm or reset it. Then one clean save writes the entity types, trees, draft match setups and check rules. All as drafts, none promoted. How the data plane works.

A golden record that has to earn the read

Matching makes data more sensitive, not less. Three partial records become one person. That person has a name, a birth date and a card. So the record has to pass a gate before any agent sees it. Six quality checks above their floors. Plus a consent check that fails closed when no lawful basis is on file. Then it comes back through a view that masks. The reader role has no grant on the table underneath. How Auth carries the power.

Proof of the merge, not just an explanation of it

Tilores is right that a reviewer should be able to rebuild 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. The verifier names the failure. Each merge, unmerge, pin and reset also writes a before-and-after row in the same save. Try it in your browser, no signup.

Where Tilores is genuinely stronger

Their speed 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 setup, with no cluster to babysit. If the match sits inside a checkout flow, that number is the rule. Everything else is decoration. We do batch and on-demand matching. That's not a sub-second stream engine. We will not pretend to be. 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 matched people, not raw rows. Their site says they are SOC 2 certified. They reach US agencies through Carahsoft, on four contract paths. They name customers we do not have yet.

Their 2025 post claims 150 million records in 36 hours. Our public check covers roughly 370,000 real public records across three data sets. We show no ceiling above that.

Here is the push-back, and it comes from their own writing. In August they published six rules. Rules for controlling access to matched customer data in a RAG pipeline. Bind fetches to the requester's real permissions. Scope the match query rather than filtering after the fact. Keep the enforcement line inside infrastructure you control. Log what was fetched 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 to build. So is the query-time authorization. So is the prompt trimming. Same for the log that records why access was allowed. So the matched record lands in your agent's context. It is the most re-identifying object in your estate. It lands with whatever controls your team built last sprint. A matching API hands you a match.

It does not hand you the model. Nor the stewardship ladder, the quality gate, or the proof itself. That is the half we build. We would rather build 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 each 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. Checking it tells deletion apart from truncation and from tampering. Each control change also writes a before-and-after row in the same save as the change. 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 shows no signing, chaining, or tamper proof. Ask them what stops an admin editing the row.

What happens to a revoked agent mid-session?

DataShield re-checks power on each controlled tool call, so revocation lands on the next call. A mastering run has its own brakes as well. A scope-keyed pause or kill flag stops it mid-flight. A microbatch rolls back to its pre-image. Tilores narrows OAuth tokens per requester. It restricts fields with a @hasPrivilege directive. Both are set before the call. We found no mid-session revocation step in their public docs. Ask how long a compromised agent keeps reading matched 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. Underneath, consent is a lawful-basis record per subject and purpose. It covers all six GDPR Art. 6(1) bases across nine purposes. No recorded basis means no read. Actor identities in the chain are HMAC-committed. The change stream carries no values. So the proof still checks out once the subject is gone. Tilores claims GDPR compliance and writes well about deletion. We could not find the step for erasing a person from a matched record. Nor one for keeping the match history solid after. 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, and more than an engine. Fellegi-Sunter fuzzy record linking. Jaro-Winkler, Levenshtein, Soundex and Double Metaphone comparators. LSH blocking, trained settings, five survivorship rules, drift watch. Plus a paired-gate test run each setup must pass before it goes live. Around it sits the part a matching API leaves out. A guided build. A stewardship trust ladder. A quality and consent gate on the read. And the audit chain. What it is not is a low-latency API for a checkout path. It has been checked against roughly 370,000 real public records. Not a number we will round up. If you need an answer in 100ms inside a payment flow, buy Tilores. If it then feeds agents, analysts and an auditor, the control layer 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. A public endpoint, no API key needed. Its tools help an assistant discover features and build GraphQL recipes. They also check search parameters and lint rules. Good design for build time. Their own advice is to keep personal data out of it. Ours is where the controlled data is actually mastered and read. 143 of our MCP commands are for master data alone. That is 32% of the whole agent surface. An agent can interview a user and draft a model. It can train and test a setup end to end. It can run matching, work the stewardship queue, and read goldens. Each call sits under a tool token. Each gets sealed into the chain. If you want an agent to help write your matching rules, use theirs. Want it to build and run the model, under a policy you can later prove? Use ours.

Does DataShield have SOC 2?

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

Tilores positioning: "One trusted view of each <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. Plus a tilores-langchain package for LangChain and LangGraph. - tilores.io, 19 May 2026
The Tilores MCP server is stateless and read-only. It stores no customer data, and its endpoint is public with no API key. Its tools cover feature 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 is the customer's build. So is query-time authorization and the "why was this allowed" audit log. - 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 shown. - tilores.io/pricing, 13 Sep 2026
Carahsoft appointed Master Government Aggregator for Tilores. Distribution runs 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 →