Head-to-head · updated 13 September 2026

DataShield vs Unity Catalog: who governs the data your agents touch off the lakehouse?

Unity Catalog is very good at its job. It is the data catalog, the permission system and the lineage recorder for the Databricks platform, and since 2025 it has grown to cover models, MCP servers and agents too. Its hero line is "Unified governance for data, apps and AI agents," and inside a Databricks estate that is close to true. ABAC is generally available, governed tags drive row filters and column masks, and lineage arrives for free because Databricks runs the compute. There is no separate licence to buy.

DataShield is not a lakehouse catalog, and we are not going to pretend to be one. We are the authorization and evidence layer for agents, and we run on our own infrastructure with our own signing keys. Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Every governed call is sealed into a hash chain you can verify yourself. Below is the honest split, including the rows Databricks takes.

DataShield vs Unity Catalog at a glanceEight questions regulated buyers ask us. Scored from each vendor's public documentation. DataShield vs Unity Catalog at a glance Eight questions regulated buyers ask us. Scored from each vendor's public documentation. DataShield Unity Catalog Tamper-evident audit chain you can verify Authority re-checked on every tool call Break-glass access for agents GDPR erasure that keeps the chain valid One policy plane past the lakehouse Row and column policy on governed tables Column-level lineage across the platform Semantic layer your agents can query shipped partial / roadmap not offered Sources at the bottom of this page.

The short version

Pick DataShield when

  • Your agents reach past Databricks. Postgres, a vendor API, an S3 drop, a SaaS record. One policy plane and one log for all of it.
  • An examiner will ask you to prove a log was not edited. Databricks stores its audit record as a system table it owns, still in Public Preview. Ours is a SHA-256 chain with signed checkpoints, and you can break it in a browser to watch the verifier catch you. Run it.
  • You need to pull an agent's authority mid-session and have the very next tool call fail closed.
  • You want the policy engine, the vault and the evidence running on your own hardware, with keys you hold. See the architecture.

Pick Unity Catalog when

  • Your data and your compute already live on Databricks. It ships with Premium and Enterprise, so there is no second vendor to buy or renew.
  • You want row filters and column masks driven by governed tags, applied to tables, materialized views and streaming tables at query time. ABAC is generally available and it is good. We do not do this.
  • You need column-level lineage from a dashboard back to the source table. Databricks captures it because it runs the query. We cannot see what we do not sit in front of.
  • You want a semantic layer your agents share with your analysts. Metric views define measures once and Genie Agents read them with synonyms and display names attached. That is a real moat and we have nothing like it.

Bottom line: Unity Catalog governs the lakehouse and everything Databricks runs. DataShield governs what an agent is allowed to do anywhere, and keeps proof of it that does not depend on the platform's word. In Databricks shops we expect to run alongside.

Feature by feature

Competitor cells describe what Databricks' public site and docs say as of the date above. If we've mischaracterised something, email support@myorg.ai and we'll correct it, credited.

What mattersDataShieldUnity CatalogEdge
Catalog scope and discoveryOntology registers a provider over a live connection, scans it in place with no row egress, and profiles assets and columns. PostgreSQL today, not your whole estate: Snowflake, BigQuery, Databricks and S3 are declared with no handler yet. Field classification is deeper, with 129 classes, checksum validators and reproducible verdicts stamped with a config digest.One metastore across every workspace, cloud and region, holding tables, files, functions, models, agents and MCP servers. Delta, Iceberg and Parquet. This is the breadth we do not have.
Fine-grained access controlScope ceilings and authority tiers on MCP tool tokens, plus quasi-identifier generalization (dates to year, decade or age band; ZIPs to 3 or 4 digits; partial phones, SSNs and emails) with a measured cardinality-reduction score per column. Masking and generalization are switches you turn on, not defaults. We do not put row filters on Delta tables.ABAC is generally available. Governed tags drive row filter and column mask policies on tables, materialized views and streaming tables, and one policy can cover a whole catalog. DENY policies are still Beta.
Lineage and business semanticsTyped lineage traversed hop by hop with access gating at each hop, derived from the pipelines that own the relationships rather than a stored graph. A business glossary materialized from entity types. No column-level lineage across a compute platform, and no metrics layer.Automated column-level lineage across tables, notebooks, dashboards and models. Metric views define measures and dimensions once and serve SQL editors, dashboards and Genie Agents from the same definition.
Audit evidenceSHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification returns a named verdict and tells tampering from insertion, deletion and truncation. Signing keys can sit in your KMS or HSM. Public demo.Rich audit events in the system.access.audit system table, which the docs mark Public Preview. We found no claim anywhere that the records are hash-chained, signed, or independently verifiable.
Agent authorizationEvery governed tool call runs a fixed pipeline before dispatch: auth gate, consented-tool narrowing, token scope ceiling, declared authority tier, revocation re-check, then metering. Delegation is RFC 8693 token exchange with an enforced scope ceiling.Grants and ABAC policies on catalog objects, plus RBAC on models, tools and connections in Agent Bricks. Unity AI Gateway adds on-behalf-of execution so an MCP call runs with the requesting user's permissions rather than a shared service account.
Break-glassScoped, time-boxed emergency access for agents. Admin plus IP allowlist plus step-up, auto-revoking, and it cannot be quietly deleted from the log.Not described in the docs we read. Ask them.
GDPR erasureCrypto-shred of the subject's key material plus ISO 27560 consent receipts. Actor identities in the chain are HMAC-committed, so the evidence still verifies after the subject is gone.Delete the rows. What erasure does to audit history, or to data already copied out of governed tables, is not documented.
Tokenization and data handlingDatasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. Tokens are deterministic, join-preserving and vault-reversible, and every lookup is audited or refused.Masking and redaction applied at query time by policy. Unity AI Gateway guardrails add PII detection and redaction on model traffic, listed as Beta in the April 2026 launch post. We found no vault-reversible token architecture with a governed detokenization path.
MCP and agentsMore than 200 MCP tools across Ontology, Auth, Corpus and Lighthouse. Auth issues MCP tool tokens with scope ceilings, and per-call metering is attributed to the agent that made the call.Managed MCP servers for Genie, AI Search, SQL, Unity Catalog functions and a code interpreter, at per-server OAuth scopes with on-behalf-of user auth. Claude and Cursor can connect today. The docs mark the feature Public Preview.
Reach beyond the platformPlatform-agnostic by construction. Auth issues the token, the governed surfaces check it on every call, and nothing requires a particular compute vendor.Lakehouse Federation gives "governed, read-only access to external data," with access controls at the table level. Catalog federation reaches Glue, Hive, Snowflake, Salesforce Data 360 and Palantir Foundry. Row and column policy stays a Databricks-object story.
DeploymentSelf-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.Databricks control plane on AWS, Azure or GCP with a customer-side data plane. The open-source Unity Catalog server is Apache 2.0 and self-hostable, but its own README says the APIs "should not be assumed to be stable," and it carries a smaller feature set than the commercial product.
Maturity and pricingLive in production (Guardian and Lighthouse since April 2026). SOC 2 not yet certified, and we say so. Published pricing and an instant quote with no call.A very large private company with a deep enterprise bench and a long compliance record. No separate licence: Unity Catalog rides on Premium and Enterprise tiers, and you pay for compute and storage. Which means you cannot price governance on its own.

◆ DataShield leads◇ Unity Catalog leads◈ comparable

Databricks claims are drawn from databricks.com and docs.databricks.com, last checked 13 September 2026. We link them below rather than paraphrase from memory.

Three things you get here that you won't get from a platform catalog

A witness that isn't the defendant

Databricks writes the audit record, stores the audit record, and holds the keys to the storage. Its own docs discourage moving that data off the platform, which is sound security advice and also means the only witness is the system under review. Our chain sits in a separate control plane with its own signing keys. Edit a record in your browser and the verifier names the exact failure. Try it, no signup.

Authority that can change mid-flight

An analyst resigns on a Friday afternoon. Their agent is forty minutes into a job. With DataShield the next governed tool call re-checks authority and fails closed. A permission change in a catalog does not reach into a query that is already running. How Auth does it.

Governance that outlives the platform choice

Okera customers learned this in 2023. You pick a governance layer, the layer gets bought, and your policy model moves to someone else's roadmap. Run the policy plane and the evidence plane on your own hardware and that stops being your problem. How we deploy.

Where Unity Catalog is genuinely stronger

Start with the obvious. If your data is on Databricks, Unity Catalog is already there, it costs nothing extra, and turning on ABAC is a configuration change. Tag a column once and the policy follows it across a catalog. Lineage is captured at column level because the platform runs the query, and no external tool can match that without sitting in the same place. Metric views are the underrated part: define a measure once, and your dashboards and your Genie Agents compute it the same way. Whoever owns the semantic layer owns what the agent believes the business means, and Databricks noticed that before most people did. The Iceberg work is real too. They bought the format's creators, then in September 2026 proposed community specs for portable policy and portable governance metadata, which is not the behaviour of a vendor trying to lock the door.

Here is the push-back, and it is narrow on purpose. Those specs standardise how policy travels and how metadata stays portable. Neither standardises evidence integrity, and nobody in that proposal is signing anything. Databricks wrote in the same post that each catalog must be able to demonstrate compliance independently without administrators reconciling audit trails across systems. We agree with the sentence and disagree about where the independent party sits. A system table in Public Preview, owned by the platform that ran the agent, is telemetry. It is excellent telemetry. It is not the artifact you hand a regulator with the claim that nothing in it could have been altered. And past the platform boundary, Federation is read-only with table-level controls, which is a long way from row and column policy on your Postgres.

Questions worth asking both of us

These are the questions we'd want answered if we were buying. Ask them on every vendor call, including ours.

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

DataShield: yes. Each record commits to the one before it, checkpoints are signed and chained, and verification tells deletion from truncation from tampering. Try it at /verify. Unity Catalog: audit events land in the system.access.audit system table, which the docs still mark Public Preview. The events are detailed and queryable. Databricks does not claim they are hash-chained or signed, and we went looking. Ask them to show you the integrity proof, not the query.

What happens to a revoked agent mid-session?

DataShield re-checks authority on every governed tool call, so a revocation bites on the very next call. Unity Catalog evaluates grants and ABAC policies when a query runs, which covers a lot of ground. We found no description of a running agent session being downgraded in flight, and no authority tiers for agents. Ask how long a compromised agent keeps working after you pull its access.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds the subject's key material and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the chain still verifies after the subject is erased. On the Databricks side, deleting rows is easy. What the docs do not cover is what erasure does to your audit history, or to data copied out of governed tables. Ask both of us.

Is DataShield a Unity Catalog alternative, or does it replace it?

It is not a replacement and we would be lying if we said it was. We do not put row filters on Delta tables, we do not do column-level platform lineage, and we have no metrics layer. What we replace is the assumption that the platform's own tables are sufficient evidence. Most Databricks customers who talk to us keep Unity Catalog and add an independent layer for agent authorization and tamper-evident proof. The longer argument is in our Unity Catalog write-up.

If we run the open-source Unity Catalog server, do we get the same governance?

No, and this one catches people. The OSS project is Apache 2.0 and genuinely open, but its README warns the APIs "should not be assumed to be stable," and the governed enterprise surface stays in the paid platform. Ask Databricks directly which of ABAC, lineage, audit and the managed MCP servers you keep if you self-host the OSS server. Then ask what your governance story is for the data that never touches Databricks at all.

Does DataShield have SOC 2?

Not yet, and we will not imply otherwise. Auth is live in production with a public threat model and a verifier anyone can run. Guardian and Lighthouse have been running since April 2026. Design-partner terms include source escrow, so a small vendor is not a single point of failure. Details on the security page.

Other head-to-heads

Same market

DataShield vs Microsoft Purview

DataShield vs Microsoft Purview: Purview governs the Microsoft estate end to end. DataShield adds per-call.

Same market

DataShield vs Snowflake Horizon

DataShield vs Snowflake Horizon: Horizon governs data inside Snowflake. DataShield adds reversible tokens,.

Same market

DataShield vs Amundsen

DataShield vs Amundsen: LF AI & Data archived Amundsen in September 2026. An honest self-hosted migration.

All

Every comparison

One honest scorecard per vendor, sources at the bottom.

Keep Unity Catalog. Then see what an independent layer adds: break a live audit chain, revoke an agent mid-session, and judge for yourself. Demo Center access is free with a work email.

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 →