What Is Google Zanzibar? Definition & Examples

Google Zanzibar is a distributed authorization model designed for large-scale, fine-grained access control. It represents permissions as relationships between users, groups, and resources, then evaluates access through a central service. The approach is widely referenced for systems that need expressive authorization at scale.

Expanded Definition

Google Zanzibar is a distributed authorization model for expressing and evaluating access relationships at scale. It treats permissions as graph-like relationships among users, groups, tenants, and resources, then resolves whether a request is allowed through a centralised authorization service rather than by embedding rules in each application.

The term is often used as both a specific Google design reference and a shorthand for relationship-based access control patterns inspired by it. In practice, the boundary that matters is not whether a system is “Zanzibar-compliant” in a formal sense, because no single industry standard governs that label yet. The useful distinction is whether authorization decisions depend on relationship tuples, policy graph traversal, and consistent evaluation semantics across many services. That differs from coarse RBAC, where access is mostly role-centric, and from simple ACLs, where permissions are attached directly to objects with less expressive sharing logic.

For deeper context on the origin model, Google’s published Zanzibar paper remains the canonical technical reference for the design philosophy behind this class of authorization systems.

Examples and Use Cases

Google Zanzibar-style authorization shows up anywhere access must be precise, shared, and evaluated consistently across a large product surface.

Document, drive, or collaboration platforms use relationship checks to decide whether a user can view, edit, comment on, or share a resource.
Multi-tenant SaaS products apply the model to separate tenant scope from object-level access while still supporting delegation and nested group membership.
Developer platforms use central authorization services so APIs, UI surfaces, and background jobs all answer the same access question the same way.
Internal enterprise portals use relationship-based logic when access depends on team membership, project assignment, and resource ownership together.
Authorization engines that mirror Zanzibar principles often reduce duplicate permission logic, but they can introduce latency and consistency trade-offs if caching or tuple replication is poorly designed.

When this pattern is implemented well, it gives product teams expressive sharing without scattering authorization rules across every service. When it is implemented poorly, teams tend to recreate ad hoc exceptions in application code, which defeats the purpose of centralised authorization.

Security Implications

The main security risk is not the existence of fine-grained authorization itself, but the failure to model relationships accurately and consistently. A mistaken tuple, stale group edge, or broken inheritance path can grant access broadly across many resources, because the authorization service becomes a shared trust boundary for the whole platform.

This makes correctness, propagation delay, and observability especially important. If policy changes do not reach all evaluators quickly, revoked access may remain effective longer than intended. If applications cache decisions too aggressively, they may continue to honour permissions that no longer exist. If relationship data is incomplete, administrators may think an access path is closed when it is still reachable through another linked principal.

NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which is a useful reminder that authorization models fail loudly when privilege scope is not controlled. For Google Zanzibar-style systems, the practical symptom is often “unexpectedly valid access” rather than a visible outage.

Domain and Governance Relevance

In identity and access governance, Google Zanzibar matters because it separates authorization logic from application logic and forces organisations to treat permissions as first-class data. That changes ownership: product teams define resource relationships, platform teams govern the authorization service, and security teams must validate that policy semantics match business intent.

For NHI-heavy environments, the impact is even sharper. Service accounts, API clients, automation jobs, and agentic workflows often need permission models that are richer than a simple human-role mapping, especially when access is delegated across systems or projects. A Zanzibar-like design can help express that complexity, but it also requires strong lifecycle control over machine principals, shared memberships, and delegated relationships. For practitioners studying adjacent NHI controls, the OWASP Non-Human Identity Top 10 is a useful companion reference, and NHIMG also documents how exposed API keys can become a direct data-leak path in practice.

The governance question is therefore not just “who can access what,” but “who can change the relationship graph, how are those changes reviewed, and how quickly can they be revoked when trust changes?”

Risk and Threat Considerations

Google Zanzibar-style authorization concentrates risk in the relationship graph and the authorization service that interprets it. If tuple data, inheritance logic, or propagation mechanisms are wrong, the result can be silent over-permission rather than an obvious system failure.

Failure mechanism: attackers or insiders can abuse stale relationships, excessive delegation, or confused-sharing paths to obtain access that appears legitimate to the evaluator. In distributed systems, inconsistency between writers, caches, and readers can also preserve access after revocation, creating a short but exploitable window for misuse.

Impact: the blast radius can be large because one authorization defect may affect many applications, tenants, or resource types. The most serious outcome is unauthorised read, write, or administrative access that is difficult to detect because it looks like a valid authorization decision.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Zanzibar centralizes fine-grained access decisions and access governance.
Recommendation — Map relationship-based permissions to PR.AC and verify every delegated access path.
CIS Controls v8	6 — Access Control Management	Zanzibar governs who may reach resources through centrally managed permissions.
Recommendation — Use Control 6 to review, limit, and revoke resource access paths consistently.
NIST SP 800-63	AAL — Authentication Assurance Level	Zanzibar decisions depend on trustworthy identity assertions behind access requests.
Recommendation — Tie authorization decisions to appropriately assured identity signals before granting access.
NIST Zero Trust (SP 800-207)	3 — Zero Trust Principles	Zanzibar-style authorization enforces per-request access verification and least privilege.
Recommendation — Apply Zero Trust to re-evaluate access continuously instead of trusting network location.
OWASP Non-Human Identity Top 10	NHI-02 — Secrets and Credential Management	Machine and service principals often carry the permissions Zanzibar-style systems enforce.
Recommendation — Control machine credentials tightly so relationship-based access cannot be abused through stolen tokens.

Practitioner Guidance

Why practitioners should care: treat the authorization graph as governed infrastructure, not application metadata. The security question is whether relationship changes are reviewed, versioned, observable, and reversible with the same discipline as other high-impact control planes.

Common misunderstanding: teams often assume centralisation automatically improves security. In reality, a central authorization service only helps when tuple hygiene, cache invalidation, and exception handling are tightly controlled; otherwise, it can concentrate mistakes as well as trust.

Practitioner takeaway: define ownership for relationship data and revoke paths as explicitly as you would for credentials, because stale authorization edges can outlive the business decision that created them.

Google Zanzibar