Head-to-head · updated 13 September 2026

DataShield vs AuthZed: who decides, and who can prove it later?

AuthZed builds SpiceDB. It's an open-source permissions database, modeled on Google's Zanzibar. It is very good. Genuinely. Say your permission model is a graph. People, groups, folders, documents. SpiceDB answers "can this subject see this object?" It is fast. In single-digit milliseconds. Across billions of links, too. Take permission-aware RAG. An agent must filter a million documents. Down to the ones its user could already open. That's the right tool for it. No argument there.

DataShield is not a permissions store. We're the control plane around the agent itself. Who issued its credential? What scope ceiling does the token carry? Does its access still hold on this call? What proof survives a year later? SpiceDB answers "allowed?" and stops there, on purpose. Most of our work starts right after that answer.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

You need the agent to have an identity in the first place. Think SSO, passkeys, RFC 9068 tokens, MCP tool tokens with a scope ceiling. SpiceDB assumes you solved that already. See Auth.
An auditor or the EU AI Act's Article 12 will ask you to prove a decision log wasn't edited. Our chain answers that with math. Run the verifier.
You need to pull an agent's access mid-session. The very next tool call should fail closed. Don't wait for a token to expire.
You need break-glass. GDPR crypto-shred, too. Plus a Connection Vault, for the credentials the agent uses downstream.

Pick AuthZed when

Your hard problem is modelling permissions as a graph. Nested groups, shared folders, org trees, inherited roles. Zanzibar was built for exactly this problem. Cedar-style rules fit it badly.
You're doing permission-aware RAG at scale. Materialize pre-computes the links ahead of time. An agent can filter millions of documents, fast. That's a real engineering answer to a real bottleneck.
You want open source. SpiceDB is Apache-2.0. It runs anywhere. It costs nothing to try. That's a level of trust. A closed platform can't buy it.
You care about the New Enemy problem. ZedTokens give you a defined consistency guarantee. Most authorization products don't even name this failure mode. AuthZed does.

Bottom line: SpiceDB is a decision engine. DataShield is the control plane. It issues the agent's identity. It enforces the ceiling. It catches a pulled grant, mid-job. It seals the result into a chain you can verify. These stack. Choosing just one? Is your exposure agents, not document graphs? Start here.

Feature by feature

Competitor cells describe what AuthZed's public site says. Blog and docs too. We use the date above. If we got something wrong, email support@myorg.ai. We'll fix it and credit you.

What matters	DataShield	AuthZed	Edge
Permission modelling	Cedar policies cover admin, config, and token decisions. policy_explain gives you the reasoning. In plain terms. Per decision, every time. Good for rules. Not a relationship graph.	Zanzibar-style ReBAC. Objects, relations, rights. Union, intersection, exclusion, and graph traversal. Caveats attach typed CEL conditions to a relationship, too.	◇
Scale of authorization checks	Per-call checks in the MCP dispatch path. Sized for tool calls. Not for filtering million-document result sets.	Billions of links, in live use. Materialize went GA on 10 September 2026. It pre-computes the links ahead of time. That gives single-digit millisecond answers.	◇
Permission-aware RAG	Ontology exposes RAG and dataset tools over MCP. On tokenized data. We filter on dataset and tool scope. Not on a per-document relationship graph.	A first-class use case. Public agentic RAG walkthroughs. Plus LangChain, LangGraph, and Pinecone integrations.	◇
Agent identity	Auth issues the identity. Think SAML, OIDC, and WebAuthn passkeys. Plus RFC 9068 JWTs and API keys. MCP tool tokens, JWKS rotation, too. Plus a Connection Vault, for encrypted per-subject downstream credentials.	Out of scope. They say plainly: security isn't a property you get. Not from connecting an agent to an identity provider. You bring your own identity layer.	◆
Agent authorization at the tool call	Each checked tool call passes a token scope ceiling. It also passes a declared access tier. Plus a revocation re-check. That happens before dispatch. Revocation lands mid-session.	A check API you call from your own code. Explicit delegation means a sub-agent reaches only its own links. Nothing more. Enforcement is yours to wire in.	◆
Audit evidence	A SHA-256 hash chain, with Ed25519-signed checkpoints. Those checkpoints are themselves chained. Verification names the exact failure. Tampering. Insertion. Deletion. Or truncation. Try the verifier.	We found no tamper-evident audit method. Not in their public docs. Decision logs, yes. Observability, yes. Cryptographic proof? Not that we could find.	◆
Break-glass	Scoped, time-boxed emergency access for agents. It auto-revokes on its own. It can't be quietly deleted. Not from the log.	Not described. You'd model it as a link. Remember to remove it, yourself.	◆
GDPR erasure	Crypto-shred of per-subject key material. Plus ISO 27560 consent receipts. Actor IDs carry HMAC tags. The chain still verifies after erasure.	Delete the links. Effect on decision history isn't documented.	◆
Tokenization and data handling	We tokenize datasets at ingest. Agents query tokenized data over MCP. Turning a token back into real data: that's privileged. It's audited, always. We generalize quasi-identifiers, too. Dates become year, decade, or age band. ZIPs become 3 or 4 digits. Phones, SSNs, and emails get partial masking. Each column gets a measured cardinality-reduction score.	Not a data platform. SpiceDB stores links, not the protected data itself.	n/a
MCP and agents	Native MCP endpoints sit on Auth, Ontology, and Lighthouse. MCP tool tokens carry scope ceilings. Per-call metering ties right back to the agent, always.	A strong point of view, from December 2025. MCP specs authentication. It leaves the call to implementers, they say. The fix they sell is the check. Not the MCP surface.	◈
Deployment	Self-hosted. In your own cloud or data center, your call. Or a dedicated single-tenant server we operate. Your keys, always.	Apache-2.0 SpiceDB, anywhere. AuthZed Cloud, usage-based. Self-Hosted with support. Or Dedicated Cloud. The widest range in this market, by far.	◇
Maturity signals	Auth, Guardian, and Lighthouse are all live in production. Guardian and Lighthouse have run since April 2026. SOC 2 isn't certified yet, and we say so.	SpiceDB open-sourced back in 2020. A big OSS crowd backs it. Netflix and Turo show up as implementation examples. OpenAI and Workday are named on their site.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Their tiers are public. Open source is free. Cloud runs usage-based, from $2 an hour. Self-Hosted runs per region and per vCPU. Dedicated is custom. Refreshingly plain, for this market.	◈

◆ DataShield leads◇ AuthZed leads◈ comparable

AuthZed claims come from authzed.com. Plus its pricing page and its blog. Last checked on 13 September 2026. We link them below. Not just a paraphrase from memory.

Three things you get here that you won't get from a permissions database

An identity for the agent

A check API needs a subject. Someone real, or something real, has to mint it. Scope it. Rotate it. They also have to store the credentials it uses, too. That's Auth. Passkeys and SSO for humans. RFC 9068 tokens and MCP tool tokens for agents. A Connection Vault for the rest. How it fits together.

Proof that survives an audit

A decision log you can edit proves nothing. Ours is a hash chain with signed checkpoints. The verifier tells you what went wrong. Not just that something did. That's the property EU AI Act Article 12 reviewers want. Same for HIPAA §164.312(b). Try it in your browser, no signup.

Authority that can change mid-flight

An analyst quits on a Tuesday. Their agent is halfway through a 40-minute job. We re-check access on the next checked tool call. It fails closed. Delete the link in a permissions store, though. One question remains. Did anything already in flight actually stop? See the architecture.

Where AuthZed is genuinely stronger

Let's be blunt about the parts we'd lose. Zanzibar is a proven design. SpiceDB is the best open implementation of it. Say your permissions live in a graph. Folders inside folders. Teams inside teams. Sharing links that inherit. Rules-based policy gets ugly fast, there. Relationships don't. Their ZedToken consistency story is careful work. Most vendors don't even acknowledge it. Theirs does. Materialize went GA in September 2026. It's a serious answer. A real fix for the RAG filtering problem. Pre-compute the links ahead of time. Then an agent, searching a million files, skips that cost. No graph-traversal cost per hit. And the whole core is Apache-2.0. You can read it. You can run it. Then you can leave. We can't say that.

The push-back is about scope, not quality. In February 2026, they made an argument. Policy engines don't work for AI authorization, they said. You can't predict what an agent will do. Fair point. We'll give them that. It doesn't land on us, though. Our enforcement seam isn't a rule, checked per tool call. It's a token scope ceiling. Plus a declared access tier and a revocation re-check. Cedar handles admin, config, and token decisions. More to the point: being right is only half the job. Proof is the rest. Proof is the other half. The regulator's question isn't "was your model correct?" It's different. It's "show me the March logs, and prove nobody touched them." Nothing fancier. A permissions store has no answer to that, by design. It doesn't issue the agent's credential, either. It gives you no break-glass path at 2am. It won't let you erase a data subject. Not without wrecking your evidence. Those are our rows. They're not trying to win them. Fair enough.

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, it can. Each record commits to the one right before it. Checkpoints are signed and chained. Verification tells deletion apart from truncation and from tampering. Run it against a sample chain at /verify. AuthZed: we found no tamper-evidence method in their public docs. SpiceDB is a decision engine. That's a fair scope choice. No shame in it. Need the proof? Ask them where it would come from.

What happens to a revoked agent mid-session?

DataShield re-checks access on each checked tool call. Revocation bites on the very next call. With SpiceDB, you delete or change the link. The next check returns false. That's fast. That's clean, at the check. The gap is everything that isn't a check. A long-running job, holding a credential. A cached result. A token nobody re-validates. Ask both of us who enforces, and where.

Should we use ReBAC? Or a policy engine, for agent permissions?

Honestly, it depends. On your data shape. Does access flow through links? Use ReBAC, and SpiceDB is the best of them. Does access flow through attributes and roles instead? Rules are simpler. We'd add a third thing. For MCP tool calls, the useful control isn't the model. Not at all. It's a scope ceiling on the token the agent holds. Pick the model for your resources. Pick the ceiling for your tools.

Can DataShield sit on top of SpiceDB?

That's the arrangement we'd expect. In a large deployment. SpiceDB answers document-level questions inside your app. Auth issues the agent's identity. It caps what its tools can reach. It catches a pulled grant. It seals the outcome. We don't have a packaged SpiceDB connector today. Ask us about it, rather than assuming it. We'd rather say that. Than imply an integration we haven't shipped.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds per-subject key material. Then it issues an ISO 27560 consent receipt. Actor identities in the chain carry HMAC commitments. The evidence still checks out, after the subject is gone. AuthZed: deleting links is simple, on their side. But we found nothing about what happens to decision history. Ask whether erasing a subject leaves you stuck. Unable to answer an examiner.

Does DataShield have SOC 2?

Not yet. We won't imply otherwise, ever. Plain and simple. Auth ships with a public threat model. Plus a verifier anyone can run. Guardian and Lighthouse have run since April 2026. Design-partner terms include source escrow. That way, a small vendor isn't a single point of failure. Details on the security page.

AuthZed positions itself as "authorization infrastructure for modern applications". It develops SpiceDB, inspired by Google's Zanzibar. - authzed.com, 13 Sep 2026
AuthZed Materialize reached general availability. It pre-computes the links ahead of time. That gives single-digit millisecond checks, at agent and RAG scale. - AuthZed blog, 10 Sep 2026
SpiceDB names relationship graphs, ZedToken consistency, and caveats. Plus explicit delegation, as its AI authorization mechanisms. Identity, audit, and revocation aren't in scope. - AuthZed blog, 10 Sep 2026
AuthZed argues MCP "handles authentication." It says: "Authorization, the actual permission decisions, is left entirely to implementers." That's their read. - AuthZed blog, 1 Dec 2025
AuthZed's case against policy engines for AI: "If you could predict what agents would do ahead of time, they'd just be workflows." Their words, not ours. - AuthZed blog, 18 Feb 2026
Listed tiers: open source free. Cloud usage-based, from $2 an hour. Self-Hosted per region and per vCPU. Dedicated custom. - authzed.com/pricing, 13 Sep 2026

Other head-to-heads

Policy

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 →