What do teams get wrong when they try to use Zanzibar-style authorization for every access control decision?

A common mistake is treating Zanzibar as a universal replacement for other authorization models. It is strong for relationship-driven access and implicit hierarchies, but weaker when policies must also consider attributes such as time, location, or broader policy logic. Teams also underestimate the complexity of integrating it with existing policy-as-code systems.

Why This Matters for Security Teams

Zanzibar-style authorization is powerful because it gives teams a consistent way to answer relationship questions like who can view, edit, or share a resource across a large graph of users, groups, tenants, and objects. The mistake is assuming that a relationship graph can absorb every decision rule without loss of clarity or control. Once teams force time windows, location checks, risk scoring, or business exceptions into the same model, the policy becomes harder to reason about and harder to audit. That is where drift starts: engineers add special cases in code, while the authorization layer becomes only one part of the decision path.

For broad access control governance, teams usually still need a separate policy layer for contextual rules, especially where control decisions must change by environment or session state. General control catalogs such as NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Controls v8 are useful reminders that access control, auditability, and account management are broader than one authorization engine. In practice, teams get into trouble when they treat Zanzibar as a policy language rather than a relationship engine, then discover that the real exceptions live outside the graph.

How It Works in Practice

Zanzibar-style systems work best when the access question is mostly about relationships, inheritance, and scope. For example, a user can access a document because they are the owner, a member of the project, or part of an organization that inherits access through a hierarchy. The model is efficient when the answer can be derived from graph traversal and explicit tuples, because the logic stays predictable and the system can evaluate authorization at scale.

The problem starts when teams try to encode broader policy logic directly into that graph. Common failure patterns include:

Using relationships to represent contextual checks that really belong in a decision engine.
Encoding temporary exceptions as durable graph edges, which makes access linger longer than intended.
Mixing human-readable business policy with low-level relation tuples, which makes reviews and testing harder.
Relying on the graph for coarse authorization while leaving session, request, or environment checks scattered across services.

A better operating model is to let Zanzibar answer the relationship question, then combine that result with separate policy logic for attributes, request context, and conditional enforcement. That keeps the graph focused on stable resource relationships while allowing time-based, location-based, or risk-based decisions to evolve independently. The design also becomes easier to observe because reviewers can tell whether a deny came from missing relationship state or from contextual policy. The OWASP ASVS is a useful external reference point for keeping authorization and session controls testable rather than implicit. These controls tend to break down when one authorization layer is expected to compensate for inconsistent data modelling across many services.

Common Variations and Edge Cases

Tighter relationship-based authorization often increases modelling overhead, so teams have to balance a clean graph against the cost of maintaining separate policy layers. That trade-off is most visible in systems that combine static sharing with dynamic constraints. A product team may want one rule model for everything, but the practical reality is that some access decisions are stable and relationship-driven, while others are conditional and should not be flattened into the same structure.

Edge cases usually appear in three places:

Context-sensitive access: If the decision depends on time, device posture, location, or transaction risk, keep that logic outside the relationship graph unless the condition is truly stable and reusable.
Exceptional access: Short-lived approvals are often better handled as time-bound policy state than as permanent graph relationships.
Migration and coexistence: Existing policy-as-code systems rarely disappear, so Zanzibar often becomes one input into a broader authorization architecture rather than a replacement.

The strongest implementations treat Zanzibar as a precise answer to a narrow question, not as a universal policy substrate. The OWASP Top 10 is a helpful reminder that access control failures usually emerge when assumptions are too broad and enforcement is too fragmented. Teams get this wrong most often when they optimize for a single elegant model and only later discover that real-world authorization still needs multiple decision sources.

Standards & Framework Alignment

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

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorization	Zanzibar-style decisions affect authorization governance across systems.
Recommendation — Use PR.AC-4 to keep authorization decisions explicit, least-privileged, and reviewable.
CIS Controls v8	6.3 — Access Control Management	The question centers on where access decisions should be enforced and managed.
Recommendation — Apply CIS 6.3 to separate durable access rules from contextual exceptions.
NIST SP 800-63	AAL — Authentication Assurance Level	Contextual access often depends on authentication strength before authorization is granted.
Recommendation — Require stronger authentication where authorization depends on higher-risk conditions.
OWASP Agentic AI Top 10	A4 — Identity and Authorization Abuse	Authorization engines fail when identity and decision logic are overextended.
Recommendation — Limit autonomous access decisions to tightly scoped authorization logic and review overrides.

Practitioner Guidance

What to prioritise: Keep the relationship graph limited to decisions it can express cleanly and auditably. If a rule depends on context, risk, or session state, separate that logic before it accumulates into untestable graph exceptions.

Decision rule: If the access answer can be stated as “who relates to what,” Zanzibar is a strong fit. If the answer also needs “under what conditions, at what time, or from where,” treat Zanzibar as one input rather than the whole policy.

What to verify: Verify that teams can explain every allow decision from the graph plus the external policy inputs, with no hidden service-side overrides. If reviewers cannot reconstruct the decision path, the authorization design is already too distributed.

Practitioner takeaway: The safest pattern is to make Zanzibar authoritative for relationships and keep conditional policy in a separate, explicit control path, so neither model has to do the other’s job.