Why Google Zanzibar Changed Security Forever

Here’s a number that should stop you cold: 94% of applications have broken access control. Not some apps. Nearly all of them. According to the OWASP Top 10, broken access control has held the number-one spot on the web security vulnerability list every single year since 2021. That means the apps you use every day, banking, healthcare, collaboration tools, are statistically speaking, leaking access to data they shouldn’t.

In 2024, attackers breached over 160 Snowflake customer environments, including AT&T and Ticketmaster, not through exotic zero-day exploits, but through plain old missing access validations. Billions of records exposed. The problem wasn’t sophisticated. The defense just wasn’t there.

Now zoom out. Google manages authorization for Gmail, Drive, Calendar, Maps, YouTube, and Photos, services used by literally billions of people, simultaneously, across every timezone on the planet. Every time you share a document, every time you add someone to a group, every time an app checks whether you can view a file, that’s an authorization decision. Google makes millions of these decisions per second. And they need every single one to be correct.

So how do you build something like that? How do you make authorization fast, consistent, and correct at a scale that breaks every traditional model ever designed?

In 2019, Google answered that question publicly. The paper was called Zanzibar: Google’s Consistent, Global Authorization System, presented at the USENIX Annual Technical Conference. And honestly, the security world hasn’t been the same since.

This article goes deeper than the surface-level summaries floating around. We’re going to cover what Zanzibar actually solved, how it works under the hood, why the open-source ecosystem it inspired is now a multi-billion dollar industry, and critically what it means for your systems right now.

The Authorization Crisis That Made Zanzibar Necessary

The Piecemeal Permission Nightmare

Before Zanzibar, authorization at large organizations was, to put it plainly, a mess. Each product team built its own permission system. YouTube had one. Gmail had another. Drive had yet another. None of them talked to each other in any coherent way.

This isn’t a uniquely Google problem. It’s what happens naturally when organizations grow fast. Teams ship features, and access control gets bolted on as an afterthought, usually a roles table in a database, some middleware checking it, and a prayer that nobody finds a gap. It works fine on a small scale. Then the cracks appear.

The dominant model for decades was Role-Based Access Control (RBAC). The idea is simple: assign users to roles, assign permissions to roles, done. For a small system with a handful of roles, RBAC is perfectly reasonable. But as soon as you try to apply it to fine-grained, resource-level permissions across millions of objects, you run into what engineers call role explosion.

Think about a collaborative document platform. You need to define who can view, comment, or edit each individual file. Across billions of distinct documents, each with different owners, different sharing settings, and different inherited permissions from parent folders, you’d need millions of distinct, highly specific roles. Roles rarely get deleted. Exceptions keep getting added. The authorization matrix collapses under its own weight.

The alternative Attribute-Based Access Control (ABAC) tried to solve this with runtime evaluation. Instead of pre-assigned roles, a policy engine evaluates attributes at check time: user’s department, resource sensitivity, time of day, location. Flexible in theory. But every check now requires querying multiple external sources to fetch real-time attributes, turning your authorization path into a slow, complex rule-engine bottleneck.

And both of these models completely fall apart when you need to traverse deep hierarchical relationships. “Does this user belong to a group nested inside another group that has been granted access to this folder’s parent directory?” In a relational database, that’s a recursive SQL join, potentially 5 to 50 milliseconds per check, and every user interaction triggers one. That’s not acceptable when authorization sits on the critical path of literally every API request.

The Real Cost: Measuring Role Explosion

Here’s a concrete way to think about why RBAC breaks at scale. The number of distinct roles you theoretically need grows multiplicatively:

Plug in realistic numbers for a mid-sized SaaS platform, 500 resource types, 3 permission levels, 200 user groups, and you get 300,000 distinct roles. At Google’s scale with billions of objects, this number becomes practically infinite. That’s the wall RBAC hits.

Zanzibar’s solution? Stop modeling permissions as roles entirely. Start modeling them as relationships.

What Google Zanzibar Actually Is (Beyond the Wikipedia Summary)

The Core Innovation: Relationships, Not Roles

Zanzibar treats authorization data as a globally replicated directed graph. Every permission fact in the system is stored as a simple three-part relationship, called a (relation tuple) that connects a resource, a relationship type, and a user.

The syntax looks like this:

object#relation@user

So doc:budget_2026#viewer@user:alice means Alice is a viewer of the budget document. That’s it. One atomic fact.

But here’s where it gets interesting. The “user” part of a tuple doesn’t have to be an individual. It can be a userset, a reference to an entire group membership. So you can write:

doc:budget_2026#viewer@group:finance#member

This means every member of the finance group is a viewer. And if that group is itself nested inside another group? Zanzibar traces that graph automatically. No special-case code needed. It’s all just paths on the same relationship graph.

Object-to-object relationships work the same way. A document belonging to a folder? That’s just another tuple:

doc:budget_2026#parent@folder:finance#

Now permissions can flow down through hierarchies, a folder’s viewer permissions propagate to every document it contains, all through standard graph traversal, without duplicating tuples for every child resource.

This is the Relationship-Based Access Control (ReBAC) model. And it’s not just more flexible than RBAC, it’s structurally better suited to how real collaborative software actually works.

How a Permission Check Actually Works

When your application asks Zanzibar “can Alice view this document?”, here’s what happens at a high level:

1. Zanzibar receives the tuple check request.
2. It looks up the relevant relation tuples for that document.
3. It expands userset references, checking group memberships, parent folder permissions, and computed relations.
4. It traverses the relationship graph using the Leopard indexing subsystem (more on this shortly).
5. It returns a binary: yes or no.

The whole thing completes in under 10 milliseconds at the 95th percentile. Across millions of simultaneous requests. Globally.

Section summary: Zanzibar didn’t improve authorization, it replaced the fundamental abstraction. Permissions became graph edges, not role assignments. That one shift changes everything downstream.

The Five Technical Breakthroughs That Made It Work

Breakthrough 1: Relation Tuples as a Universal Language

The genius of relation tuples isn’t just their simplicity. It’s that they’re composable. Complex authorization policies, “editors of a workspace can view all projects in that workspace, and project viewers can comment on all tasks within”, express naturally as a set of interlocking tuples and userset rewrite rules. No special code. No application-specific hacks. Just graph relationships.

Namespace configurations define the rules for how relations inherit and compose. Userset rewrite rules let you declare things like “all owners are also editors” without duplicating data, Zanzibar resolves those implications at query time.

Breakthrough 2: The Zookie Protocol (Solving the New Enemy Problem)

This is the one most articles barely touch on, and it’s arguably Zanzibar’s most important security contribution.

Here’s the problem in plain terms. Imagine Alice revokes Bob’s access to a confidential folder. Then, one millisecond later, Alice uploads a new document into that folder. In a distributed system with geographically replicated databases, a different region’s replica might not have received Alice’s revocation yet. If Bob’s access check gets routed to that stale replica, he sees the new document he should never have access to.

This is the new enemy problem, and it’s not theoretical. It’s a real vulnerability in any distributed authorization system that relies on asynchronous replication.

Zanzibar solves it with two components working together.

First, it’s built on Google Cloud Spanner, which uses GPS receivers and atomic clocks via the TrueTime API to assign globally synchronized, microsecond-resolution timestamps to every database write. Every permission change gets a globally meaningful commit timestamp. There is a total causal ordering of all modifications.

Second, when an application writes a permission change or creates new content, Zanzibar returns a Zookie, an opaque token encoding that operation’s commit timestamp. The application stores this Zookie alongside the content.

On the next access check, the Zookie is forwarded to Zanzibar, which guarantees the check evaluates against a snapshot at least as fresh as the Zookie’s timestamp. If a regional replica is behind, Zanzibar waits until it catches up. The new document cannot be read before the revocation is reflected.

Simple token. Profound security guarantee. This is what “globally consistent authorization” actually means in practice.

Breakthrough 3: Leopard Indexing for Nested Groups

Nested group memberships are a performance nightmare for graph traversal engines. “Is user Alice a member of the Engineering group, which is a sub-group of the All-Staff group, which has access to this document?” That’s a recursive traversal. At scale, it becomes a bottleneck.

Zanzibar’s solution is a specialized background subsystem called Leopard. Rather than computing these traversals in real time, Leopard periodically reads snapshots of relation tuples and tracks live change logs. It denormalizes the relationship graph into in-memory adjacency lists, precomputing transitive group closures. When a live check comes in, evaluating a deeply nested group membership becomes a simple set-intersection operation, near-constant time, no recursive database queries required.

This design is why Zanzibar can answer “is this user in any of these nested groups?” as fast as it answers a direct relationship check.

Breakthrough 4: Global Consistency via Spanner and TrueTime

Most distributed databases offer eventual consistency, data propagates across replicas eventually, with no hard guarantees on timing. Zanzibar demands something stronger: external consistency, meaning the system behaves as if all operations happen in a single, globally ordered sequence.

Spanner delivers this through TrueTime, which bounds clock uncertainty to microseconds using GPS and atomic clocks. Every write gets a commit timestamp that is guaranteed to be greater than any previously committed timestamp, globally, across every data center. This is what makes Zookies meaningful. A Zookie isn’t just a version number; it’s a globally verifiable timestamp embedded in an opaque token, giving the authorization engine a precise, unforgeable reference point.

Breakthrough 5: Sub-10ms at 10 Million Requests Per Second

These guarantees would be meaningless if the system were slow. Zanzibar’s architecture is engineered for performance at every layer.

ACL servers use consistent hashing based on object IDs, routing checks for the same resource to the same server nodes. This maximizes local cache hits. Request hedging duplicates slow requests to multiple servers, reducing tail latency. Per-client CPU budgets throttle non-critical traffic under load. Concurrent read throttling prevents hot-spot latency from individual popular resources.

The result? 95th-percentile latency under 10 milliseconds. Greater than 99.999% availability over three years of production use. More than 2 trillion relation tuples are stored. Tens of millions of authorization checks per second. These aren’t theoretical numbers, they’re from the original USENIX paper.

Section summary: Zanzibar’s performance is not an accident. Every component, Leopard indexing, Zookies, consistent hashing, TrueTime, was purpose-built to deliver consistency without sacrificing speed.

Why This Matters More Than You Think

Broken Access Control Is the #1 Security Vulnerability

The OWASP Top 10 documents the most critical web application security risks. Broken access control has held the top position since 2021. Not SQL injection. Not cryptographic failures. Access control.

Why does this keep happening? Because authorization is genuinely hard to get right, and most teams treat it as a feature rather than infrastructure. One team’s authorization logic doesn’t talk to another team’s. Permissions get out of sync. Revocations don’t propagate. And then someone gets access to data they shouldn’t.

Zanzibar reframes this entirely. Authorization isn’t an application concern, it’s a distributed systems problem. And it requires a distributed systems solution.

The Authorization Debt Crisis

Every application-level permission check added to your codebase is a form of technical debt. It’s inconsistent with other services’ checks. It’s hard to audit. It doesn’t propagate across product boundaries. When you need to add a new permission type, you touch a dozen files. When you need to revoke access instantly, you’re not sure which systems to update.

This is authorization debt, and most engineering organizations are swimming in it. The research shows that 62% of teams have built custom authorization solutions, and 75% of those teams would switch to a centralized SaaS authorization service if they could. The pain is real.

Zanzibar’s model offers a way out: move all authorization into a single, centralized relationship graph. One system of record. One place to update. One place to audit.

AI Agents Make This Urgent Right Now

Here’s the angle almost nobody is covering: AI agents fundamentally change the authorization threat model.

A human with wrong permissions can cause limited damage within their work hours. An AI agent with wrong permissions can cause orders of magnitude more damage, at machine speed, with zero sleep. A compromised or misconfigured agent can query, exfiltrate, or modify data across an entire organization before any human notices.

As described in the NIST Zero Trust Architecture guidelines, modern security requires continuous verification of every access request, not perimeter-based trust. AI agents need delegated permissions that are:

• Scoped to exactly what the task requires
• Time-bounded and automatically expiring
• Instantly revocable if the agent behaves unexpectedly
• Traceable through a complete delegation chain

These are exactly the properties Zanzibar’s relationship graph model supports naturally. An AI agent is just another node. Its permissions are just edges on the graph. Revoke the edge, revoke the access, globally, in milliseconds.

The Open-Source Explosion: An Industry Born from One Paper

Google published the Zanzibar paper in 2019. They did not publish the code. What happened next is one of the more interesting stories in recent software history.

The paper was clear enough in its design that other engineers started building their own implementations almost immediately. By 2021, there were multiple production-grade open-source alternatives. By 2026, the fine-grained authorization market is tracking toward $13–15 billion by 2032, growing at over 10% annually. Venture capital has flowed into companies like AuthZed ($15.8M in funding) and Permit.io ($14M), all building on Zanzibar’s foundational ideas.

Here’s how the main open-source implementations compare:

SpiceDB is the closest implementation to the original Zanzibar paper. It uses ZedTokens (its equivalent of Zookies) and supports at_least_as_fresh and fully_consistent semantics. OpenAI uses SpiceDB to power ChatGPT Enterprise’s fine-grained permission system, handling tens of billions of permission records in production.

OpenFGA, now a CNCF Incubating project, prioritizes developer experience. The schema language is friendlier, the REST API is simpler to integrate, and you can get a working prototype in hours rather than days. The trade-off is a more relaxed consistency model by default. Adopted by Docker, Grafana Labs, and Canonical, among others.

One thing worth noting: a common mistake is assuming these open-source implementations are drop-in equivalents of Google’s internal Zanzibar. They’re not. They replicate the data model faithfully. They cannot replicate the operational guarantees that come from running on Spanner with TrueTime-backed external consistency across 10,000+ servers in 30+ geographic locations. Understanding that gap is critical before you commit to any implementation.

The Dual-Write Problem: The Hidden Trap in Adoption

When you introduce an external authorization engine, you face a subtle but serious architectural challenge. Your application records live in one database (say, PostgreSQL). Your permission tuples live in another system (say, SpiceDB). What happens if your app creates a document but the permission write fails?

The document exists. No one can access it. Or worse, the permission write succeeds but the application write rolls back, leaving orphaned tuples pointing to resources that don’t exist.

This is the dual-write problem, and it’s one of the most common failure modes when adopting Zanzibar-style systems. There are a few standard approaches to solving it:

The transactional outbox pattern is the most practical starting point for most teams. Write your application record and a “pending permission” event to the same database transaction. A background process (like Debezium) tails that event and writes to your authorization engine. If the application crashes mid-write, the outbox event survives and gets replayed. Clean, reliable, and doesn’t require rearchitecting your entire write path.

Myths vs Reality: What People Get Wrong About Zanzibar

Myth 1: “Zanzibar replaces RBAC.”

Not quite. RBAC doesn’t disappear in a Zanzibar model, it gets subsumed. Roles are just one type of relationship in the graph. A user being a “member” of a “role:admin” group is still modeled as a relation tuple. Your existing role concepts survive; they just become more expressive and composable.

Myth 2: “Zanzibar is only for Google-scale problems.”

This one is more nuanced. Google’s specific implementation requires planetary infrastructure. But the model, relation tuples, userset rewrites, graph traversal, is valuable at any scale where you have collaborative, resource-level permissions with hierarchical inheritance. A 20-person startup building a SaaS platform with folder-level sharing and team roles can benefit from OpenFGA in an afternoon.

Myth 3: “Open-source Zanzibar clones solve the same problem.”

The data model, yes. The operational guarantees, no. Most implementations reproduce relation tuples and graph traversal faithfully. Very few replicate the combination of Spanner-backed external consistency, TrueTime-synchronized Zookies, and Leopard-style precomputed indices. Understand what you’re getting before committing to a consistency model.

Contrarian but true insight: The most underreported impact of Zanzibar was not technical, it was cultural. The paper proved, with production data at unprecedented scale, that authorization deserves to be first-class infrastructure. Not a feature. Not a library. Infrastructure, like databases, message queues, and observability platforms. That cultural shift is what sparked the $5 billion industry around fine-grained authorization.

The Five Biggest Mistakes When Adopting Zanzibar-Style Auth

Mistake 1: Modeling Too Much at Once

Schema design is where most teams get into trouble. They try to model every permission edge case, every future scenario, every inherited attribute, all in the initial schema. The result is a deeply nested graph that’s technically correct but cognitively impenetrable. Start with the smallest schema that covers your core access checks. Evolve it.

Mistake 2: Ignoring the Consistency Model

Not all implementations treat consistency the same way. OpenFGA defaults to eventual consistency, which is fine for many use cases, but not if you have security requirements around instant revocation. If someone’s access is revoked, how quickly does that need to propagate? Answering that question determines your implementation choice.

Mistake 3: Skipping Authorization Observability

Here’s a dark pattern that emerges at scale: your authorization graph becomes too complex for any human to audit manually. Nested groups, inherited permissions, computed usersets, the graph gets deep fast. Without proper tooling to trace “why did this user get access to this resource?”, debugging a security incident becomes a forensic nightmare. Build observability from day one. Log every check. Trace every path.

Mistake 4: Forgetting About the Dual-Write Problem

Covered above, but worth emphasizing: if you write to your application database and your authorization engine separately without a synchronization strategy, you will eventually have a crash that causes data drift. This isn’t speculation, it’s a predictable failure mode. Choose your synchronization pattern before you write your first permission tuple.

Mistake 5: Treating Authorization as an Implementation Detail

The biggest mistake isn’t technical. It’s organizational. Authorization schema is security-critical infrastructure. It should be reviewed like code, tested like code, and governed like code. Misconfigured userset rewrites can grant unintended access to entire organizational hierarchies. Schema changes need automated validation and rollback plans. This is not the place to move fast and break things.

The Authorization Maturity Model: Where Are You Today?

Most teams sit at Level 2 or 3. The industry is actively moving toward Level 4. If you’re building collaborative features, multi-tenant access, or AI agent workflows, you need to be at Level 4 today.

The Future: Zero Trust, AI Agents, and the Governance Problem Nobody Talks About

Zero Trust Got Its Infrastructure

The principles of Zero Trust architecture, continuous verification, least privilege, no implicit trust, have been discussed for years. But they were often aspirational rather than practical, because the infrastructure to support real-time, fine-grained authorization at service scale didn’t exist.

Zanzibar gave Zero Trust its infrastructure. The same principles that power Google Drive’s sharing model can enforce micro-perimeters in a cloud-native application: every service call is authorized explicitly, every relationship is queryable, every permission change propagates globally in milliseconds.

The Governance Problem Nobody Talks About

Here’s the uncomfortable truth that research surfaces but most vendor content ignores: as authorization systems get more expressive, they become harder for humans to reason about.

A deeply nested permission graph with hundreds of namespaces, computed usersets, and inherited relationships becomes effectively opaque. Security teams increasingly cannot answer basic questions like “why does this user have access to this resource?” or “which relationship chain caused this authorization?” without specialized tooling.

This isn’t a theoretical concern. Teams adopting Zanzibar-style systems regularly report that debugging permission issues becomes a forensic investigation rather than a five-minute config check. The industry solved the machine scalability problem before it solved the human comprehensibility problem. That gap is the next frontier.

Permission explainability tools, systems that can trace the exact graph path that caused an authorization decision, are emerging, but still immature. This is one of the most significant open problems in modern security infrastructure.

Centralization as a Double-Edged Sword

One more thing worth acknowledging honestly: centralizing your authorization layer improves consistency and auditability, but it also concentrates risk. A bug in your central authorization engine doesn’t affect one service, it affects all of them simultaneously. The blast radius of a misconfigured userset rewrite is your entire product suite.

This doesn’t mean you shouldn’t centralize. It means you need to treat your authorization service with the same rigor as your identity provider, monitoring, alerting, canary deployments, rollback plans, and regular audits. The benefits are real. So is the responsibility.

Conclusion: Authorization Is Now Infrastructure

So, here’s where we land. Google Zanzibar didn’t improve authorization, it reclassified it. Authorization stopped being an application feature and became a distributed systems infrastructure problem. That shift in framing has consequences that are still rippling through the industry in 2026.

The security crisis is real. Broken access control is the top vulnerability in modern web applications, and the traditional models, RBAC, ABAC, hand-rolled ACL checks, were never designed for the complexity of collaborative, multi-tenant, cross-service software.

Zanzibar’s answer, model permissions as relationships, replicate them globally, enforce consistency via cryptographic timestamps, traverse the graph in milliseconds, is now accessible to every engineering team through open-source projects like SpiceDB and OpenFGA.

But the real lesson isn’t technical. It’s that authorization deserves the same engineering rigor as your database, your observability stack, and your identity provider. It’s not a detail to defer. It’s infrastructure that every user interaction depends on.

The teams that internalize this early will build more secure, more scalable, and more trustworthy products. The teams that keep treating it as an afterthought will keep appearing in OWASP statistics.

Assess your authorization maturity today. The calculator above will tell you whether you’re already in role explosion territory. If you are, you know what to do next.

If you want to understand why Google Zanzibar changed security forever, and how you can leverage its lessons for your own systems, this is the only guide you need.

❓ Frequently Asked Questions — Click to Expand

What is Google Zanzibar in simple terms?

Google Zanzibar is a globally distributed authorization system that determines who can access what across all of Google’s products. Instead of storing permissions as static role assignments, it stores them as relationship tuples — simple three-part facts like “Alice is a viewer of this document.” These relationships form a graph that Zanzibar traverses in milliseconds to answer access control questions at any scale.

What is the “new enemy problem” and why does it matter?

The new enemy problem occurs when a user’s access is revoked, but new content is immediately created and a stale replica — one that hasn’t yet received the revocation — serves the access check. The revoked user can see content they shouldn’t. Zanzibar solves this with Zookies: consistency tokens that force authorization checks to evaluate against a replica that is at least as fresh as the permission change.

Is Google Zanzibar open source?

Google has not released Zanzibar as open-source software. However, the 2019 research paper provided enough detail that the community has built several high-quality open-source implementations. SpiceDB (by AuthZed) is the closest to the original design. OpenFGA (a CNCF Incubating project backed by Okta) prioritizes developer experience and easier adoption. Both are production-ready and widely used.

When should I use ReBAC instead of RBAC?

Consider moving to a Zanzibar-style ReBAC model when you need resource-level sharing (not just application-level roles), hierarchical permission inheritance (folders, workspaces, teams), cross-service authorization checks, or instant, globally consistent permission revocation. For simple applications with stable, coarse-grained roles and fewer than a few hundred thousand permission records, enhanced RBAC is often simpler and equally effective.

What companies use Zanzibar-style authorization in production?

OpenAI uses SpiceDB for ChatGPT Enterprise, handling tens of billions of fine-grained permissions. Airbnb built an internal Zanzibar-inspired system called Himeji, processing approximately one million authorization checks per second. Docker, Grafana Labs, and Canonical use OpenFGA. IBM’s AI Data & Model Factory platform and Red Hat’s Insights Platform run on SpiceDB. Carta, operating in regulated financial services, also adopted a Zanzibar-inspired model to meet compliance requirements.

How do you handle authorization for AI agents in a Zanzibar model?

AI agents are modeled as subjects in the relationship graph, just like users. Their permissions are expressed as delegated relationship tuples — the agent has access to exactly the resources its principal human has granted. The key advantages: delegation chains are traceable, permissions are instantly revocable by deleting the relevant tuples, and access scope can be constrained to exactly what the agent needs for a specific task. This is significantly safer than granting agents broad service-account permissions.

SpiceDB or OpenFGA — which should I choose?

Choose SpiceDB if you have strong consistency requirements (security-critical revocation), need multi-region deployment with CockroachDB, or are operating at enterprise scale where operational tuning is justified. Choose OpenFGA if you want faster onboarding, a simpler REST API, already use Auth0/Okta, or are building a prototype. OpenFGA’s CNCF Incubating status provides long-term project governance assurance. If you’re unsure, start with OpenFGA and migrate to SpiceDB if you hit consistency or performance boundaries.

What is the biggest hidden cost of adopting Zanzibar-style auth?

Cognitive complexity. The infrastructure is manageable. The operational tooling is maturing. What surprises most teams is how quickly a permission graph becomes difficult for humans to audit. As the graph deepens — nested groups, inherited permissions, computed usersets — debugging why a user has access to something becomes genuinely hard. Investing in authorization observability tooling, permission tracing, and schema documentation from day one is not optional. It’s the difference between a system that’s powerful and one that’s ungovernable.