How Google Uses Capability-Based Access Control

Most authorization systems ask “who are you?” Google’s systems increasingly ask a different question: “what token do you hold?” This shift — from identity-first to capability-first thinking — runs through Google’s entire authorization stack, from Zanzibar to signed URLs to macaroons.

The Three Layers

Google doesn’t use a single authorization model. They layer three complementary approaches:

  1. Zanzibar — relationship-based access control for service-level authorization
  2. Macaroons — cryptographic capability tokens for delegated access
  3. Cloud IAM — fine-grained permissions bundled into roles for human management

Each layer borrows from capability theory in different ways. Together, they handle everything from “can this engineer deploy to production?” to “can this anonymous user download this file for the next 30 minutes?”

Zanzibar: Authorization as a Graph

Zanzibar is Google’s global authorization system, published at USENIX ATC 2019. It backs Google Calendar, Cloud, Drive, Maps, Photos, and YouTube. At scale: trillions of ACLs, millions of checks per second, sub-10ms at p95, five nines of availability over three years.

The core data model stores relation tuples:

document:readme#editor@bob
document:readme#viewer@group:engineering#member

The first says Bob is an editor of the readme. The second says all engineering group members are viewers. Permissions compose through graph traversal — the system walks relationships to answer “does user X have permission Y on object Z?”

This is fundamentally different from RBAC, where you’d create roles like readme-editor and assign them to users. In Zanzibar, authority derives from your position in the relationship graph. Add someone to the engineering group, and they automatically inherit viewer access to every document that group can view. No role explosion, no redundant assignments.

The capability connection: while Zanzibar is identity-based at its core (tuples reference user identities), the relationship graph acts like a capability derivation chain. Your authority isn’t a static role — it’s computed dynamically from your relationships. This is closer to how capability systems derive authority from chains of delegation than to how traditional ACLs work.

The New Enemy Problem

Zanzibar solves a subtle consistency problem. Imagine Alice removes Bob from a document, then adds a secret to it. If the permission check for Bob’s next request hits a stale replica, he sees the secret.

Zanzibar’s answer: zookies — opaque consistency tokens returned on every ACL write. Pass the zookie with subsequent checks, and Zanzibar guarantees the check reflects that write. External consistency without requiring strongly consistent reads on every check.

Macaroons: Tokens That Attenuate

Google researchers published the macaroons paper describing a credential designed for decentralized authorization. A macaroon is a bearer token built from chained HMACs with a remarkable property: anyone holding one can add restrictions, but no one can remove them.

A service mints a macaroon by HMAC-signing an identifier with a root key. The holder can then add caveats — conditions that restrict the token’s authority:

Each caveat is chained into the HMAC. Caveats can only be added, never removed. The service verifies by re-deriving the chain and checking all caveats are satisfied.

This is the principle of least privilege baked into the token format. You can delegate a subset of your authority by adding caveats before passing the macaroon along. Authority flows downward, never upward.

Third-party caveats take this further. A caveat can require a discharge token from another service, enabling cross-service delegation without the original service knowing about the third party at mint time.

Macaroons have been adopted outside Google: Fly.io uses them for platform authorization, and the Lightning Network uses them for node access control.

Signed URLs: Pure Capabilities in Production

Google Cloud Storage signed URLs are the purest capability pattern in Google’s product line. A signed URL contains:

Anyone possessing the URL can access the resource. No authentication, no identity check, no permission lookup. The URL is the authority. This is textbook capability-based access control.

Google Docs “anyone with the link” sharing works similarly. The document ID in the URL, combined with the sharing setting, acts as an unguessable capability token — though unlike signed URLs, these don’t expire.

Cloud IAM: Capabilities Organized into Roles

Google Cloud IAM structures permissions as service.resource.verb — for example, compute.instances.start. These are capability identifiers: each one describes a specific action on a specific resource type.

Pure capability-style management of hundreds of fine-grained permissions would be impractical for human administrators. So IAM bundles them into roles:

The resource hierarchy (organization → folder → project → resource) means a permission granted at a higher level flows down to everything below. This is inheritance through structure, not through role definitions.

What Makes This Different

Traditional access control systems maintain lists of who can do what (ACLs) or assign users to predefined roles (RBAC). Google’s approach differs in three key ways:

Authority derives from structure, not assignment. In Zanzibar, you don’t assign “viewer” to a user on every document. You model the actual organizational structure — teams, folders, projects — and permissions flow from relationships. Add someone to a team, and they inherit access to everything that team can access.

Delegation is built into the token. With macaroons and signed URLs, you can share a subset of your authority without involving an administrator. Add a caveat to restrict the scope, pass the token along. The recipient can further restrict it before passing it on. No central authority needs to approve each delegation step.

Permissions are composable, not enumerable. Zanzibar’s namespace configuration language lets you define how permissions compose — viewers include editors, editors include owners. You declare the rules once, and the system computes the effective permissions by traversing the graph. No need to maintain exhaustive permission matrices.

The Open Source Ecosystem

Zanzibar’s ideas have spawned several open-source implementations:

All share the core concepts: relation tuples, schema definitions, Check/Expand APIs. SpiceDB has the deepest feature set; OpenFGA is easier to get started with.

The Practical Insight

Google’s authorization architecture isn’t a pure capability system in the academic sense. It’s a hybrid that uses different models at different layers: relationship graphs for service authorization, capability tokens for delegated access, role-bundled permissions for human-managed policies.

The thread connecting all three layers is that authority is derived and delegable, not statically assigned. Whether it’s a relationship tuple granting access through group membership, a macaroon attenuated with caveats, or a signed URL shared via email — the pattern is the same. You don’t ask an administrator to grant access. You derive it from what you already have, and you can share a restricted version of it with others.

That’s the capability model’s real contribution to Google’s architecture: not a specific technology, but a design principle that scales from a single signed URL to trillions of authorization checks per second.