Head-to-head · updated 13 September 2026
DataShield vs AuthZed: who decides, and who can prove it later?
AuthZed builds SpiceDB, an open-source permissions database modelled on Google's Zanzibar. It is very good. If your permission model is a graph of people, groups, folders and documents, SpiceDB answers "can this subject see this object?" in single-digit milliseconds across billions of relationships. For permission-aware RAG, where an agent must filter a million documents down to the ones its user could already open, that is the right tool.
DataShield is not a permissions database. We're the control plane around the agent itself: who issued its credential, what scope ceiling the token carries, whether its authority still holds on this call, and what proof survives a year later. SpiceDB answers "allowed?" and stops there, on purpose. Most of the work we sell starts after that answer.
The short version
Pick DataShield when
- You need the agent to have an identity in the first place: SSO, passkeys, RFC 9068 tokens, MCP tool tokens with a scope ceiling. SpiceDB assumes you already solved that. 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 authority mid-session and have the very next tool call fail closed, not wait for a token to expire.
- You need break-glass, GDPR crypto-shred, and 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 and Cedar-style rules fit it badly.
- You're doing permission-aware RAG at scale. Materialize pre-computes transitive relationships so 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, runs anywhere, and costs nothing to try. That's a level of trust a closed platform can't buy.
- You care about the New Enemy problem. ZedTokens give you a defined consistency guarantee. Most authorization products don't even name this failure mode.
Bottom line: SpiceDB is a decision engine. DataShield is the control plane that issues the agent's identity, enforces the ceiling, catches revocation mid-job, and seals the result into a chain you can verify. These stack. If you're choosing one and your exposure is agents rather than document graphs, start here.
Feature by feature
Competitor cells describe what AuthZed's public site, blog and docs say as of the date above. If we've mischaracterised something, email support@myorg.ai and we'll correct it, credited.
| What matters | DataShield | AuthZed | Edge |
|---|---|---|---|
| Permission modelling | Cedar policies for admin, config, and token decisions, with policy_explain giving human-readable reasoning per decision. Good for rules. Not a relationship graph. | Zanzibar-style ReBAC. Objects, relations, permissions, with union, intersection, exclusion and graph traversal. Caveats attach typed CEL conditions to a relationship. | ◇ |
| 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 relationships in production. Materialize went GA on 10 September 2026 and pre-computes transitive relationships for 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. Published agentic RAG walkthroughs, plus LangChain, LangGraph and Pinecone integrations. | ◇ |
| Agent identity | Auth issues the identity: SAML, OIDC, WebAuthn passkeys, RFC 9068 JWTs, API keys, MCP tool tokens, JWKS rotation. Plus a Connection Vault for encrypted per-subject downstream credentials. | Out of scope. They say plainly that security isn't a property you get from connecting an agent to an identity provider. You bring your own identity layer. | ◆ |
| Agent authorization at the tool call | Every governed tool call passes a token scope ceiling, a declared authority tier, and a revocation re-check before dispatch. Revocation lands mid-session. | A check API you call from your own code. Explicit delegation means a sub-agent only reaches what its own relationships reach. Enforcement is yours to wire in. | ◆ |
| Audit evidence | SHA-256 hash chain with Ed25519-signed checkpoints that are themselves chained. Verification names the failure: tampering, insertion, deletion, or truncation. Public verifier. | We found no tamper-evident audit mechanism in their public material. Decision logs and observability, yes. Cryptographic proof, not that we could find. | ◆ |
| Break-glass | Scoped, time-boxed emergency access for agents that auto-revokes and can't be quietly deleted from the log. | Not described. You'd model it as a relationship and remember to remove it. | ◆ |
| GDPR erasure | Crypto-shred of per-subject key material plus ISO 27560 consent receipts. Actor IDs are HMAC-committed, so the chain still verifies after erasure. | Delete the relationships. Effect on decision history isn't documented. | ◆ |
| Tokenization and data handling | Datasets are tokenized at ingest; agents query tokenized data over MCP; detokenization is a privileged, audited operation. 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. | Not a data platform. SpiceDB stores relationships, not the protected data itself. | — |
| MCP and agents | Native MCP endpoints on Auth, Ontology and Lighthouse. MCP tool tokens with scope ceilings, per-call metering attributed to the agent. | Strong point of view, published in December 2025: MCP specs authentication and leaves authorization to implementers. The fix they sell is the check, not the MCP surface. | ◈ |
| Deployment | Self-hosted in your own cloud or data center, or on a dedicated single-tenant server we operate. Your keys. | Apache-2.0 SpiceDB anywhere, AuthZed Cloud usage-based, Self-Hosted with support, or Dedicated Cloud. The widest range in this market. | ◇ |
| Maturity signals | Auth, Guardian and Lighthouse are live in production (Guardian and Lighthouse since April 2026). SOC 2 not yet certified, and we say so. | SpiceDB open-sourced in 2020, large OSS community, Netflix and Turo cited as implementation examples, OpenAI and Workday named on their site. | ◇ |
| Pricing | Published model, scoped instant quote, no sales wall. | Published tiers. Open source free, Cloud usage-based from $2 an hour, Self-Hosted per region and per vCPU, Dedicated custom. Refreshingly plain for this market. | ◈ |
◆ DataShield leads◇ AuthZed leads◈ comparable
AuthZed claims are drawn from authzed.com, its pricing page and its blog, 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 permissions database
An identity for the agent
A check API needs a subject. Someone has to mint it, scope it, rotate it, and store the downstream credentials it uses. 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, and the verifier tells you what went wrong, not just that something did. That's the property EU AI Act Article 12 and HIPAA §164.312(b) reviewers look for. 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 authority on the next governed tool call and fail closed. Delete the relationship in a permissions database and you still have to ask: did anything already in flight stop? See the architecture.
Where AuthZed is genuinely stronger
Let's be blunt about the parts we'd lose. Zanzibar is a proven design and SpiceDB is the best open implementation of it. If your permissions live in a graph, folders inside folders, teams inside teams, sharing links that inherit, then rules-based policy gets ugly fast and relationships don't. Their ZedToken consistency story is careful work that most vendors in this market don't even acknowledge. Materialize, which went GA in September 2026, is a serious answer to the RAG filtering problem: pre-compute the transitive closure so an agent searching a million documents doesn't pay graph-traversal cost per hit. And the whole core is Apache-2.0. You can read it, run it, and leave. We can't say that.
The push-back is about scope, not quality. In February 2026 they argued that policy engines don't work for AI authorization because you can't predict what an agent will do. Fair point, and it doesn't land on us, because our enforcement seam isn't a policy evaluated per tool call. It's a token scope ceiling, a declared authority tier, and a revocation re-check, with Cedar handling admin, config and token decisions. More to the point, being right about the decision is only half the job. The regulator's question isn't "was your model correct?" It's "show me the March logs, and prove nobody touched them." A permissions database, by design, has no answer to that. Neither does it issue the agent's credential, nor give you a break-glass path at 2am, nor let you erase a data subject without wrecking your evidence. Those are our rows. They're not trying to win them.
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 apart from truncation and from tampering. Run it against a sample chain at /verify. AuthZed: we found no tamper-evidence mechanism in their public material. SpiceDB is a decision engine, and that's a fair scope choice. If you need the proof, ask them where it would come from.
What happens to a revoked agent mid-session?
DataShield re-checks authority on every governed tool call, so revocation bites on the next call. With SpiceDB you delete or change the relationship and the next check returns false. That's fast and 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. If access flows through relationships, use ReBAC and SpiceDB is the best of them. If access flows through attributes and roles, rules are simpler. We'd add a third thing: for MCP tool calls, the useful control isn't the model 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, caps what its tools can reach, catches revocation, and seals the outcome. We don't have a packaged SpiceDB connector today, so 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 and issues an ISO 27560 consent receipt. Actor identities in the chain are HMAC-committed, so the evidence stays verifiable after the subject is gone. AuthZed: deleting relationships is straightforward, but we found nothing about what happens to decision history. Ask whether erasing a subject leaves you unable to answer an examiner.
Does DataShield have SOC 2?
Not yet, and we won't imply otherwise. Auth is live a public threat model and a verifier anyone can run. Guardian and Lighthouse have been in production since April 2026. Design-partner terms include source escrow, so a small vendor isn't a single point of failure. Details on the security page.
- AuthZed positions itself as "authorization infrastructure for modern applications" and develops SpiceDB, inspired by Google's Zanzibar. — authzed.com, 13 Sep 2026
- AuthZed Materialize reached general availability, pre-computing transitive relationships for single-digit millisecond checks at agent and RAG scale. — AuthZed blog, 10 Sep 2026
- SpiceDB names relationship graphs, ZedToken consistency, caveats, and 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. Authorization, the actual permission decisions, is left entirely to implementers." — 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." — AuthZed blog, 18 Feb 2026
- Published 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
DataShield vs Permit.io
Authorization as a service, versus the control plane that enforces and proves it.
PolicyDataShield vs Styra / OPA
Rego everywhere is a fine answer. It still isn't evidence.
PolicyDataShield vs Amazon Verified Permissions
Same Cedar language, very different job at the tool call.
AllEvery comparison
One honest scorecard per vendor, concessions included.
See both mechanisms run in your browser: break a live audit chain, revoke an agent mid-session, then decide. Demo Center access is free with a work email.
Get free Demo Center accessYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →