AuthZed (SpiceDB)

Researched 2026-06-28. Primary category: authorization-engine. Independent, VC-backed (Series A).

One-liner — A Google-Zanzibar-style permissions database (open-source SpiceDB) that stores relationships between users, resources, and groups and answers fine-grained “who can access what” at scale — relationship-based access control (ReBAC).

What it does

AuthZed builds and commercializes SpiceDB, an open-source implementation of Google’s Zanzibar model (the system behind Google Drive/Docs sharing). Unlike a stateless policy engine, SpiceDB is a database: you write relationship tuples (“user X is editor of doc Y,” “team A owns folder Z”) and a schema, then query permissions; it computes answers across deep relationship graphs consistently and quickly. This makes it the natural choice when access is fundamentally about relationships and nesting (sharing, hierarchies, multi-tenancy) rather than role/attribute rules alone.

Where it sits in the stack

Primary authorization-engine — the ReBAC/Zanzibar member of the category. Layer: model-prompt. Lethal-trifecta role: constrains the sensitive-data and egress legs by deciding whether a principal (user or agent) may access a specific resource; not prompt-content inspection (that’s ai-runtime-security / agent-runtime-security). For agents, it answers “may this agent, acting for this user, see this exact record?” — relevant to entitlement-aware designs (cf. entitlement-aware-rag).

Deployment & architecture

Open-source SpiceDB (Apache-2.0) self-hosted; AuthZed offers managed Dedicated (single-tenant cloud), Serverless, and on-prem Enterprise editions with SLAs. Stores its own relationship data (stateful) backed by Postgres/CockroachDB/Spanner-class stores; exposes a gRPC/HTTP permissions API with Zanzibar-style consistency tokens (zookies). Pairs with your IdP for identity; it stores the relationships, not credentials. Current site markets it as “the authorization platform for AI and modern applications.”

Positioning & differentiators

The Zanzibar/ReBAC specialist — deepest fit when permissions are relationship-graph-shaped at scale. Versus open-policy-agent / cerbos (stateless policy engines that evaluate rules over attributes you supply but don’t store relationships), oso (Polar DSL, does ReBAC too but less Zanzibar-purist), permit-io (managed wrapper over OPA/Cedar), styra (enterprise OPA). The tradeoff: SpiceDB owns a stateful permissions store (more power for relationship data, more to operate) where stateless engines push data-fetching to the caller.

Ownership, funding & M&A

Founded 2020 by Jimmy Zelinskie, Jake Moshenko, and Joseph (Joey) Schorr/Zwicker — ex-CoreOS/Quay infrastructure engineers. HQ New York, NY (some sources list SF). Raised ~$16M: Series A $12M (2024-06, led by General Catalyst, with Work-Bench, Y Combinator, Amplify Partners). No M&A — independent (no seed flag). Confidence high.

CTO / hedge-fund lens

Day-2. The right pick specifically when your authorization is relationship/sharing-heavy — document/folder hierarchies, nested teams, multi-tenant data — and you want consistent, fast checks an agent can call before reading a record. Heavier to run than a stateless engine (it’s a database you operate, or you buy the managed tier). For a fund doing entitlement-aware RAG over shared content, SpiceDB-style ReBAC is a strong primitive; for simple role/attribute checks, cerbos / open-policy-agent are lighter. Series-A vendor — manage vendor-risk, though the OSS core limits lock-in.

Competitors / alternatives

open-policy-agent, cerbos, oso, permit-io, styra.

Open questions / to verify

  • Exact NY-vs-SF HQ and any funding since the 2024 Series A.
  • Production references for agent authz specifically (vs application ReBAC).

Sources

History

  • [2026-06-28] Stub created from seed registry.
  • [2026-06-28] Researched; established 2020 founding, NY HQ, founders (ex-CoreOS/Quay), ~$16M funding (Series A $12M 2024 General Catalyst), SpiceDB/Zanzibar/ReBAC positioning. No M&A — independent. Confidence high.