Google Zanzibar Explained: Architecture, ReBAC, Tuples, Zookies, and Open-Source Alternatives

Google Zanzibar is often described as a relationship-based access control system. That description is useful, but incomplete.

The public paper describes something much larger: a Google-internal, globally replicated authorization service that stores relationships, evaluates permission graphs, coordinates freshness, serves checks through distributed infrastructure, and protects applications from stale access-control decisions.

That distinction matters. A tuple such as document:42#viewer@user:alice is only the visible edge of the design. The difficult engineering begins when the system must answer questions such as:

1. Is Alice a viewer directly, through a group, or through a parent folder?
2. How fresh must the authorization decision be after a revocation?
3. What happens when relationship data lives outside the authorization service?
4. Can an application prevent a revoked user from seeing a document that was indexed yesterday?
5. Is an open-source Zanzibar-inspired engine equivalent to Google’s internal system?

This guide answers those questions from the original Google Research publication and the 2019 USENIX ATC paper. It also connects the paper to current implementation choices involving OpenFGA, SpiceDB, multi-tenant SaaS, enterprise RAG, and AI agents.

What is Google Zanzibar?

Google Zanzibar is a globally distributed authorization system for storing and evaluating access-control lists across many Google services. The public paper describes a uniform data model and configuration language used by hundreds of client services, including historically named services such as Drive, Calendar, Photos, Maps, YouTube, and Cloud-related systems.

The important word is system. Zanzibar combines a relationship model with storage, graph evaluation, consistency controls, caching, indexing, APIs, quotas, isolation, and client-side protocols. Calling it only “Google’s ReBAC model” hides the parts that make the design useful at large scale.

It is also important to separate authorization from authentication. Authentication answers who a principal is. Authorization evaluates whether that identified principal may perform an action on a resource. Zanzibar does not replace OAuth, identity proof, credential issuance, or token exchange. Readers who want a short primer on that boundary can review authentication versus authorization in APIs.

Google Zanzibar is best understood as a distributed authorization service built around relationships, not as a public Google product that developers can simply install.

Why did Google need Zanzibar?

Large product ecosystems tend to accumulate separate permission systems. A document service may understand folders and editors. A video service may understand channels and subscribers. A photo service may understand albums and collaborators. A cloud service may understand projects, roles, and inherited permissions.

That fragmentation creates several problems:

• Permission logic is duplicated across services.
• Every product invents a different authorization vocabulary.
• Cross-product relationships become difficult to evaluate.
• Revocations can race with content reads.
• A change in group membership may need to reach many enforcement points.
• A role hierarchy may not express a user’s relationship to a specific resource.

Traditional RBAC works well when access maps cleanly to roles such as admin, editor, or viewer. But real products often need rules such as:

A user may edit a document if they are an editor of its parent folder, a member of a group with editor access, or the direct owner of the document.

That is a graph problem. The answer depends on relationships between principals, groups, folders, documents, organizations, and sometimes other resources.

Google’s approach was to give many client services a common model while allowing each service to define its own namespaces and relationships. A calendar service and a document service do not need identical business rules. They need a shared way to describe and evaluate those rules.

The Zanzibar model: objects, relations, and usersets

The basic Zanzibar notation is a relation tuple:

Text notation:

object#relation@user

A simple example is:

Text notation:

document:report-42#viewer@user:alice

It means that Alice has the viewer relationship to the document identified as report-42.

A group relationship can be represented as a userset reference:

Text notation:

document:report-42#viewer@group:security#member

This does not mean the group object itself is reading the document. It means members of the security group are included in the document’s viewer set.

The distinction between stored relationships and computed usersets is central. A system might store that a group is a member of a folder and that a document belongs to the folder. It can then compute which users may view the document without materializing a separate direct tuple for every user.

A practical authorization design worksheet

Before choosing an authorization engine, write down the model in plain language. This small worksheet prevents a common mistake: selecting a product before understanding the relationships the product must represent.

If the answers are unclear, the design is not ready for a product comparison. Clarify the domain model and ownership boundaries first.

Namespace configurations and rewrites

Zanzibar’s namespace configuration describes what relations mean and how effective permissions are computed. The paper discusses mechanisms including:

• Direct membership.
• Computed usersets.
• Tuple-to-userset traversal.
• Union.
• Intersection.
• Exclusion.

A simplified policy might say:

Text notation:

viewer = direct_viewer OR editor OR parent_folder.viewer

The syntax above is explanatory notation, not a claim about a current public product language. OpenFGA and SpiceDB use their own model languages and APIs, so their documentation must be followed for executable schemas.

The value of this design is composability. You can describe permissions through a resource hierarchy rather than copying every effective permission into every object. The cost is that evaluation can become expensive when graphs are deep, wide, highly nested, or poorly bounded.

Tuples are the input vocabulary. Namespace rewrites and graph evaluation turn those relationships into effective permissions.

Google Zanzibar is not just a tuple store

Many explainers stop after showing a tuple. That is the first major content gap in the topic.

A production authorization system must answer four separate questions:

1. What relationships exist? This is the tuple and relationship-data problem.
2. How are permissions derived? This is the model and graph-evaluation problem.
3. How fresh must the answer be? This is the consistency and revocation problem.
4. How does the service survive real traffic? This is the storage, caching, indexing, quota, isolation, and operations problem.

The Google paper describes internal components such as Zanzibar’s serving path, distributed caches, lock tables, consistent hashing, request hedging, quotas, throttling, and client isolation. It also discusses Leopard, a system for serving deeply or widely nested sets through offline snapshot-built shards and an incremental Watch-fed layer, and Slicer, which helped manage large relationship sets.

Those details matter because a small authorization demo can look correct while hiding the difficult production behavior. A graph check that works for ten relationships may behave very differently with deep inheritance, group nesting, hot resources, cross-region reads, or a sudden revocation wave.

A useful mental model is:

Zanzibar = relationship model + graph evaluator + consistency protocol + distributed serving system + client cooperation.

Removing any one of those layers can change the security and performance properties.

How consistency and zookies work

The most important technical idea in the paper is not the tuple format. It is the way authorization freshness is connected to content freshness.

Suppose a user has access to a document through a group. An administrator removes the user from that group. At nearly the same time, the user requests a document that was written or indexed before the removal.

If the content service reads a stale authorization snapshot, it might allow access based on the old relationship. That is the New Enemy Problem: stale authorization data can expose content that should no longer be visible after a relationship change.

Zanzibar addresses this with external consistency, snapshots, and opaque zookies. A zookie acts as an at-least-as-fresh lower bound. A client can associate a content-change zookie with content and later provide that bound when asking for an authorization decision.

The practical meaning is narrower and more precise than “strong consistency everywhere.” A check is evaluated at a snapshot that is no older than the supplied lower bound. Some requests can be served regionally when their freshness requirements are satisfied. More recent requests may require additional coordination or cross-region work.

This design creates a useful separation:

• Safe: the application can use a snapshot old enough to satisfy the content’s causal requirement.
• Recent: the application asks for a newer view, potentially paying more latency or coordination cost.

The security lesson is simple: authorization freshness is part of the data flow. It cannot be treated as an afterthought attached to a token or cache.

The zookie protocol is a causal freshness mechanism. It is valuable because it connects authorization state to the version of the content being protected.

Historical scale: impressive, but easy to misuse

The 2019 paper reports substantial internal production figures. It describes more than two trillion relation tuples, more than 10 million client queries per second, more than 10,000 servers, replication in more than 30 locations, and availability above 99.999% over the reported period.

The abstract also highlights authorization latency below 10 milliseconds at p95. The detailed measurements provide more context: a Safe Check sample reached roughly 11 milliseconds at p95, 20 milliseconds at p99, and 93 milliseconds at p99.9. Different API mixes, freshness classes, and workloads produce different results.

These figures should be cited as historical Google-reported observations from the internal system described in the paper. They are not:

• Current 2026 Google SLOs.
• A benchmark that any Zanzibar-inspired product should match.
• A guarantee for OpenFGA, SpiceDB, or Ory Keto.
• Evidence that every authorization request is below 10 milliseconds.
• A Cloud Spanner performance claim.

The paper distinguishes Google’s internal use of Spanner from Cloud Spanner. That boundary should remain explicit.

Before and after: why the boundary matters

Before careful interpretation:

“Zanzibar handles millions of checks per second at under 10ms, so an open-source Zanzibar implementation will provide the same performance.”

After careful interpretation:

“Google’s 2019 paper reports more than 10 million client queries per second and a headline Safe Check p95 below 10ms for its internal workload. Public engines use different storage, caches, APIs, consistency modes, and deployment topologies, so they require workload-specific testing.”

The second version is less dramatic, but it is more useful to an architect making a production decision.

Google Zanzibar compared with OpenFGA and SpiceDB

OpenFGA and SpiceDB are public Zanzibar-inspired systems. They borrow important ideas from the paper, especially relationship-based modeling and graph-derived permissions. They should not be presented as Google Zanzibar itself.

Their model languages, APIs, datastores, caches, consistency controls, operational tooling, and release behavior differ. Even when two systems use similar tuple concepts, their guarantees may not be interchangeable.

The right selection depends on workload and ownership questions, not brand similarity:

• Who owns relationship data?
• Is the source of truth a transactional database, directory, or authorization service?
• Are writes synchronous, asynchronous, or event-driven?
• What happens during a projection lag or datastore outage?
• Which consistency modes are available in the exact release you will deploy?
• How are model changes tested and rolled back?
• How will you measure graph depth, branching, cache hit rate, and tail latency?

The official OpenFGA Zanzibar guide is useful for understanding the model-to-product boundary. The SpiceDB Zanzibar documentation is useful for tracing how another public engine maps the paper’s ideas into its own system.

Choose a public engine for its documented behavior and operational fit, not because it uses the word “Zanzibar.”

The production problem most tutorials skip: relationship-data ownership

A Zanzibar-inspired service can reduce authorization logic inside transactional applications. But moving permission evaluation out of a service does not make relationship data disappear.

A SaaS application still needs to know when:

1. A user joins or leaves an organization.
2. A folder moves to another parent.
3. A document is deleted.
4. A customer changes plan limits.
5. A role is renamed or removed.
6. A tenant is suspended.
7. A service retries an event after a partial failure.
8. A backfill must rebuild relationship data.

This creates a second lifecycle for authorization data. Practitioners in discussions such as this SpiceDB/OpenFGA integration thread on Reddit repeatedly raise the same questions: Should relationship writes happen synchronously with Postgres transactions? Should the system use CDC or an outbox? How are deletes replayed? How do teams reconcile drift? What happens when the authorization service is temporarily unavailable?

There is no universal answer. Synchronous writes improve coupling and freshness but increase transaction dependencies. Asynchronous projection reduces coupling but introduces lag, ordering, replay, and reconciliation work.

A practical architecture review should draw two separate flows:

1. Decision path: principal → authorization check → resource allow/deny.
2. Data path: business transaction → event/outbox/CDC → relationship projection → authorization store.

Teams often model the first flow carefully and treat the second as plumbing. In production, the second flow determines whether the first flow is trustworthy.

Relationship-data lifecycle matrix

The authorization check is only the visible part of the system. The relationship-data lifecycle determines whether that check remains trustworthy after the business state changes.

A design that has no answer for one of these events has an authorization lifecycle gap, even if its normal Check response is correct.

How Zanzibar-style authorization fits enterprise RAG

RAG systems make authorization mistakes especially dangerous because retrieval can expose sensitive text before the language model generates an answer.

A vector similarity score answers a relevance question:

Which chunks resemble the query?

Authorization answers a different question:

May this principal see those chunks in this context?

That is why a relationship-based authorization check can be useful in document-aware RAG. A tuple might connect a user or group to a document, folder, project, or tenant. The retrieval layer can then filter candidates against current permission state before protected text reaches the model.

For a deeper application-level treatment, see document-level access control in RAG. The article explains why relevance and visibility are separate decisions and why permission-aware retrieval must be enforced before generation.

A production RAG design should also consider enterprise RAG security architecture and ACL propagation, especially when source-system permissions are projected into an index. The critical questions are:

• Are chunks tied to stable parent-document identifiers?
• Can a permission change reach the retrieval path quickly enough?
• Does a stale vector index fail closed or continue returning old content?
• Are semantic-cache keys isolated by tenant and authorization context?
• Are post-retrieval checks treated as a backup rather than the only boundary?
• Can the system prove which permission decision allowed a result?

A metadata field such as department=finance is not itself authorization. Metadata can help filter candidates, but current permission evaluation still needs an authoritative policy or relationship decision.

In RAG, Zanzibar-style authorization is not a replacement for retrieval. It is the visibility boundary that determines which retrieved objects may enter the model context.

RAG permission boundary check

A vector database can identify relevant text; it does not automatically decide whether the current principal may see that text. Use this short review before treating metadata filtering as authorization.

A system should not pass this review merely because a permission field exists in the vector metadata. The team must test current decisions, propagation, cache behavior, and the final trust boundary.

Applying the model to AI agents and tools

AI agents introduce more principals and more relationships. The relevant graph may include:

• A human user.
• An agent identity.
• A workload or service account.
• An MCP server.
• A tool.
• An action.
• A resource.
• An approval or environment constraint.

An OAuth token can establish identity and delegated context, but it does not automatically answer whether a specific agent may call a specific tool with a specific resource. That final decision still belongs at the resource boundary.

If the article’s application includes agents, securing non-human identities for agentic AI provides useful context on delegation, revocation, and last-hop authorization. For an MCP example, see MCP security, tool permissions, and OAuth boundaries.

A Zanzibar-style relationship model may express relationships such as:

Text notation:

agent:researcher#member@user:alice
mcp-server:finance#caller@agent:researcher
report:quarterly#reader@mcp-server:finance

The exact syntax is illustrative. Public systems require their own schema language and validated implementation details.

The deeper point is that authorization should follow the action’s real path. If an agent can call a tool that reaches a downstream database, checking only the agent’s initial token is not enough. The downstream resource still needs a decision based on actor, action, resource, scope, and current policy.

Three documented case studies: from Google’s system to practical designs

The examples below are deliberately different. The first is a primary-source account of Google’s internal system. The second is a documented public implementation pattern. The third is an application architecture for permission-aware retrieval. They should not be read as equivalent benchmarks or as proof that one design works for every workload.

Case study 1: Google Zanzibar unified authorization across Google services

Problem. Google’s product ecosystem contained many services with different access-control needs. A shared document, group, folder, or account relationship could affect decisions across service boundaries. The paper’s motivation was to provide a uniform way for client services to store and evaluate access-control relationships without forcing every product into the same business policy.

Decision. Google built Zanzibar as a globally distributed authorization service with a common relation-tuple model, namespace configurations, recursive userset evaluation, APIs, distributed storage, caching, indexing, quotas, and client protocols. The system also introduced externally consistent snapshots and zookies so clients could connect authorization freshness to content changes.

Result. The Google Research record and USENIX paper report more than two trillion relation tuples, more than 10 million client queries per second, more than 10,000 servers, replication in more than 30 locations, and availability above 99.999% over the reported period. The paper also reports workload-specific latency measurements, including a headline Safe Check p95 below 10 milliseconds and a detailed sample with different tail values.

Lesson. The result was not produced by tuples alone. The case demonstrates the importance of the consistency protocol, serving infrastructure, caching, graph indexing, quotas, client isolation, and operational controls. It also demonstrates why these historical Google figures must not be copied into a comparison as if they were current public benchmarks.

Case study 2: OpenFGA applies Zanzibar-inspired modeling to multi-tenant relationships

Problem. A multi-tenant application may need to represent organizations, teams, plans, features, roles, permissions, folders, and resources. A flat role table becomes difficult to maintain when the same permission depends on both tenant membership and a resource relationship.

Decision. OpenFGA’s official Zanzibar learning guide uses a model-and-tuples approach in which application relationships are represented explicitly and authorization checks are evaluated against that model. This is a public, Zanzibar-inspired implementation path, not Google’s internal Spanner-backed architecture.

Result. The documented model can express relationships such as organization membership, group membership, and resource permissions in a reusable authorization layer. The official documentation provides the implementation concepts and APIs, but it does not establish a universal latency, availability, or business-outcome result for every multi-tenant deployment. Actual behavior depends on the OpenFGA release, datastore, model shape, tuple volume, cache state, consistency choice, and application integration.

Lesson. OpenFGA shows the practical value of separating relationship modeling from application business code, while also exposing the work that remains: relationship synchronization, versioned model changes, test coverage, datastore operations, and workload-specific benchmarking. “Zanzibar-inspired” is a design lineage, not a performance guarantee.

Case study 3: RAG access control moves the decision before model generation

Problem. A RAG system can retrieve text because it is semantically relevant even when the current user is not allowed to see it. If the unauthorized chunk reaches the model context, a later answer filter may be too late. Stale permissions in a vector index can also create a data-leak path after a user is removed from a group or a document changes ownership.

Decision. The architecture described in Vertex Frontier’s Document-Level Access Control in RAG separates relevance from visibility. A permission-aware retrieval path evaluates the principal’s access to the document or resource before protected content is passed to generation. The broader enterprise RAG security architecture adds source-of-truth, ACL propagation, pre-filtering versus post-filtering, drift, and audit considerations.

Result. The documented outcome is an architectural control: unauthorized documents or chunks should be excluded before they become model context, and permission changes should be treated as a freshness and propagation problem rather than as static metadata. The public material does not provide a universal leakage rate or benchmark, so no such number should be inferred.

Lesson. Zanzibar-style authorization can provide the relationship decision, but it does not automatically secure a RAG pipeline. Stable resource identifiers, current permission checks, tenant isolation, cache boundaries, revocation handling, and fail-closed behavior still have to be implemented and tested.

Common mistakes when adopting Zanzibar-style authorization

Mistake 1: Treating ReBAC as a universal replacement

ReBAC is a strong fit when permissions follow relationships among resources, groups, tenants, and folders. It is not automatically the best fit for every attribute rule, network policy, feature flag, or database constraint.

Hybrid systems are common. RBAC may express coarse organizational roles. ABAC may express time, region, device, or risk conditions. ReBAC may express resource ownership and inheritance.

Mistake 2: Copying Google’s historical numbers into a product comparison

Google’s figures came from a specific internal workload, fleet, topology, and measurement period. They cannot establish that another engine will deliver the same throughput or tail latency.

Benchmark your own graph depth, branching factor, tuple cardinality, datastore, cache state, freshness mode, region layout, and request mix.

Mistake 3: Ignoring the write path

A permission check can be fast while the relationship projection is stale. Design event delivery, retries, idempotency, backfill, delete handling, reconciliation, and rollback before declaring the system production-ready.

Mistake 4: Confusing authentication with authorization

An identity provider can issue a token. An API gateway can validate it. Neither automatically proves that the caller may access a specific document, row, chunk, tool, or customer tenant.

Mistake 5: Assuming a public implementation has Google’s guarantees

The phrase “Zanzibar-inspired” describes lineage, not equivalence. Read the current product documentation for the exact release, datastore, API, consistency mode, and operational behavior.

Mistake 6: Allowing unbounded graph traversal

Deep or wide relationship graphs can create fan-out, latency, and hot-spot problems. Set modeling boundaries, test pathological cases, and monitor tail behavior rather than relying on average latency.

Mistake 7: Testing only successful access

Authorization tests must include revoked users, moved resources, deleted groups, stale projections, unauthorized tenants, partial outages, retries, and cache isolation. A model that passes the happy path can still leak data during lifecycle transitions.

Who should use Zanzibar, and who should not?

A relationship-based authorization system earns its operational cost when the product already contains a meaningful relationship graph. The name of the technology is not the decision criterion; the shape and lifecycle of the permissions are.

Zanzibar-style authorization is a strong candidate for

• Multi-tenant SaaS: organizations, teams, sub-teams, projects, tenants, and delegated administration often create relationships that are difficult to keep in a flat role table.
• Folders and inherited resources: documents, repositories, dashboards, and cases may inherit access from parent folders, projects, or workspaces.
• Group-based sharing: a user may gain access through a group, nested group, or organization membership rather than a direct grant.
• Delegated access: one actor, service, or agent may act on behalf of another within a defined resource boundary.
• Multiple services: a shared authorization vocabulary can reduce duplicated permission logic when several services need to evaluate the same resource relationships.
• Permission-aware RAG and agents: documents, chunks, tools, and downstream resources may need checks tied to the current principal and action.

It may be the wrong choice when

• Permissions are almost entirely simple, stable role checks such as admin, editor, and viewer.
• The team has no owner for relationship-data synchronization, retries, reconciliation, deletion, and backfill.
• The relationship graph is unbounded, poorly understood, or likely to create uncontrolled traversal and fan-out.
• Most decisions depend on rapidly changing attributes that are not naturally represented as relationships.
• A central authorization dependency would be unacceptable and there is no tested outage or fail-closed strategy.
• The additional service would add more operational complexity than the permission problem justifies.

A hybrid model is often more realistic than a single-model replacement. RBAC can handle coarse organizational roles, ABAC can express context such as region or device risk, and ReBAC can handle ownership, inheritance, sharing, and delegation.

Decision rule: choose Zanzibar-style authorization when the relationship graph is the problem and centralized evaluation is worth the data-lifecycle cost. Do not introduce it merely because traditional roles sound inelegant.

A practical implementation workflow

The following workflow is intentionally implementation-neutral. It applies whether the chosen engine is OpenFGA, SpiceDB, another product, or an internal service.

Step 1: Identify resources and actions

List the protected resources first: tenants, projects, folders, documents, rows, tools, or API operations. Then list actions such as read, write, share, delete, or execute.

Avoid starting with roles. Roles are one possible way to derive relationships; they are not the whole domain model.

Step 2: Map direct and inherited relationships

Document direct grants, group membership, parent-child inheritance, organization membership, delegation, and exclusions. Mark which relationships are stored and which are computed.

Step 3: Choose the source of truth

For every tuple or relationship, specify whether the authoritative owner is the application database, directory, billing system, document repository, or authorization service.

Step 4: Define freshness requirements

Separate ordinary checks from security-sensitive transitions. Decide what must happen after revocation, deletion, tenant suspension, folder moves, and role changes.

Step 5: Design synchronization and recovery

Choose synchronous writes, an outbox, CDC, or another projection mechanism. Define idempotency, ordering, replay, backfill, reconciliation, dead-letter handling, and rollback.

For permission-aware ingestion, stable document identifiers and authorization references should travel with the content pipeline. Advanced RAG data preprocessing provides relevant context on provenance, versioning, and permission-aware metadata.

Step 6: Test the graph and the lifecycle

Test both permission semantics and operational transitions:

1. Direct allow.
2. Inherited allow.
3. Group removal.
4. Resource move.
5. Tenant boundary crossing.
6. Deleted principal.
7. Stale projection.
8. Authorization-service timeout.
9. Cache reuse under a different principal.
10. Model migration and rollback.

Step 7: Run a practical authorization testing matrix

A production authorization test suite should prove more than a successful allow. It should test the transitions that create stale state, unintended inheritance, tenant bleed, cache confusion, and fail-open behavior.

Run this matrix against direct checks, list/filter operations, background jobs, exports, search, RAG retrieval, agent tools, and administrative interfaces. A passing single-object Check does not prove that list endpoints or vector retrieval enforce the same boundary.

Production readiness gate

Do not describe an authorization design as production-ready because a demo returns the expected allow or deny result. Mark a high-risk scenario ready only when it has all of the following:

The most useful readiness question is not “Can the system answer a check?” It is: Can the team explain, test, recover, and audit what happens when the relationship changes?

Step 8: Measure the real workload

Record check latency by percentile, graph depth, branching factor, request type, cache state, datastore, region, consistency mode, and failure mode. Do not publish “fast” without defining the workload.

A benchmark protocol you can actually reproduce

No independent benchmark was supplied for this article, so the safe addition is a protocol rather than a performance number. Run it against the exact engine release, datastore, hardware, region layout, and model you intend to operate.

Repeat each scenario enough to separate warm-up from steady state, publish the raw workload definition, and compare only like-for-like runs. A result without these conditions is an observation about one test, not a universal product claim.

A decision guide: when should you consider Zanzibar-style authorization?

Consider a Zanzibar-inspired approach when several of these conditions are true:

• Permissions depend on resource relationships, not only user roles.
• Users belong to groups, organizations, teams, or nested tenants.
• Resources inherit access from folders, projects, or parent objects.
• Multiple services need a common authorization vocabulary.
• You need centralized policy evaluation with auditable decisions.
• Your product must support direct sharing and delegated access.
• You can operate or purchase a reliable relationship-data lifecycle.

Be cautious when:

1. Access decisions are mostly simple role checks.
2. The team cannot own synchronization and reconciliation.
3. The graph is not bounded or understood.
4. Authorization depends heavily on rapidly changing attributes that are not naturally represented as relationships.
5. A central authorization dependency would be unacceptable without a clear failure strategy.

The contrarian insight is this:

The strongest reason to adopt Zanzibar-style authorization is not that roles are ugly. It is that your product already has a relationship graph, and you need one place to evaluate it consistently.

If the product does not have that graph, introducing one may add operational complexity without solving a real problem.

Final perspective

Google Zanzibar changed the way engineers think about authorization because it treated permissions as a globally evaluated relationship graph rather than a collection of isolated role checks.

But the lesson is not “replace RBAC with ReBAC.” The more durable lesson is to separate the layers:

• Model the relationships your product actually has.
• Keep stored relationships distinct from computed permissions.
• Define freshness as a security requirement.
• Treat synchronization as a first-class data pipeline.
• Test revocation, deletion, inheritance, outages, and cache isolation.
• Attribute Google’s historical metrics to the original workload.
• Evaluate OpenFGA, SpiceDB, and other alternatives by their current documented behavior.
• Enforce the final decision at the resource boundary, including RAG documents, database rows, tools, and agent actions.

For a product with simple, stable role checks, Zanzibar-style authorization may be unnecessary complexity. For a multi-tenant product with folders, groups, delegated access, inherited permissions, and many services, it may provide the missing organizing model.

The decision should begin with the relationship graph, not with the name of the tool.

Frequently asked questions

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →