What is the difference between policy-based access control and Zanzibar-inspired relationship-based access control?

Policy-based access control evaluates declarative rules against input data, usually in an engine, sidecar, or proxy. Zanzibar-inspired relationship-based access control stores authorization facts as relationships in a graph and evaluates permissions by traversing those relationships. The practical difference is that PBAC is rule-centric, while Zanzibar-style systems are relationship-centric.

Why This Matters for Security Teams

These two models solve different authorisation problems, so the choice changes how teams design, audit, and debug access. Policy-based access control is useful when decisions depend on contextual rules such as role, resource attributes, request time, or environment. Zanzibar-inspired relationship-based access control is better when authorisation depends on who is related to what, such as ownership, membership, delegation, or hierarchy. That difference affects not only expressiveness, but also how teams reason about consistency, review, and scale.

In practice, teams usually notice the distinction when a simple rule engine starts accumulating exceptions that really belong in a relationship graph, or when a relationship model becomes awkward because the organisation needs context-heavy policy logic.

How It Works in Practice

Policy-based access control evaluates a rule set against request attributes and environment signals. The policy can say that a user may read a record if they belong to a certain role, operate from an approved network, and request during business hours. The access engine returns a decision by combining the rule outcome with the current input data. This makes the model flexible for central policy teams, because the logic is expressed directly and can be reused across services.

Zanzibar-inspired relationship-based access control stores authorisation facts as graph edges and derives permissions by traversing them. A service can ask whether a subject is allowed to act on a resource, and the system resolves that answer through relations such as parent, owner, editor, viewer, or member. The strength of this model is that it reflects organisational relationships naturally, which is especially useful when permissions are inherited, delegated, or shared across many objects.

PBAC is usually strongest when the key question is, “Does this request satisfy the policy conditions?”
Relationship-based access control is usually strongest when the key question is, “How is this subject connected to this resource?”
PBAC tends to centralise decision logic; Zanzibar-style systems tend to centralise relationship facts.
PBAC often fits well with coarse-grained controls, while relationship-based systems handle large-scale sharing and inheritance more naturally.

That difference also affects auditability. PBAC reviews focus on whether the rule was correct and complete. Relationship-based reviews focus on whether the graph facts are accurate, current, and properly scoped. If the source data is stale, both models can deny or grant access incorrectly, but the failure mode is different: PBAC fails through bad policy logic, while Zanzibar-style systems fail through incorrect relationship data or traversal rules. These controls tend to break down when organisations try to mix rich contextual policy and dense relationship graphs in the same decision path without clear ownership.

Common Variations and Edge Cases

Tighter access control often increases implementation and governance overhead, requiring organisations to balance expressiveness against operational complexity. In practice, many systems are hybrids, with relationship facts determining the base entitlement and policy rules applying extra conditions such as device posture, location, or step-up checks.

That hybrid pattern is often the best fit when permissions are relationship-heavy but enforcement still needs contextual safeguards. For example, a document-sharing platform may use a Zanzibar-inspired graph to determine who can reach a document, then apply policy rules to require stronger checks for sensitive actions such as export, delete, or admin changes. Likewise, PBAC can still be the better choice when access decisions depend mainly on dynamic context rather than object-to-object relationships.

The edge case to watch is when teams assume these models are interchangeable. They are not. A graph model can express some policies indirectly, but if the access decision depends on too many non-relational conditions, the relationship graph becomes a poor substitute for policy logic. Current guidance suggests choosing the model that matches the dominant authorisation signal, then adding the other layer only where it clearly improves control.

Risk and Threat Considerations

The main security risk is not the label, it is misalignment between the authorisation model and the real access problem. PBAC can become brittle when policy rules grow into a maze of exceptions, while relationship-based systems can expose too much access if the relationship graph is over-permissive or stale. Both patterns can create privilege creep, incorrect inheritance, and hard-to-audit access paths.

Failure mechanism: In PBAC, attackers or insiders may exploit policy gaps, inconsistent rule evaluation, or overlooked attributes to reach data they should not access. In Zanzibar-style systems, exposure usually comes from incorrect relationships, excessive delegation, or stale graph facts that preserve access after business changes.

Impact: The result can be unauthorised access, broken segregation of duties, hidden shared-access paths, and weak audit confidence when reviewers cannot easily explain why a decision was made.

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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Access control model choice directly shapes how access is governed and enforced.
	GV.OC — Organizational Context	Selecting PBAC or relationship-based control depends on business and access context.
	PR.PT — Platform Security	The decision model depends on secure enforcement points and consistent policy handling.
Recommendation — Define and enforce the access model that best fits your authorization signals. Align the authorization model with the organization’s access and governance context. Implement access enforcement consistently at trusted policy decision points.
NIST SP 800-63	Digital Identity Guidelines	Identity proofing and authentication underpin who can receive access decisions.
Recommendation — Use authenticated identity signals as trusted inputs to authorization decisions.
NIST Zero Trust (SP 800-207)	AC-1 — Access Enforcement	Both models are authorization enforcement mechanisms within a zero trust design.
Recommendation — Enforce access at decision points that continuously validate each request.
CIS Controls v8	6.1 — Establish and Maintain an Inventory of Accounts	Authorisation models depend on accurate account and entitlement records.
	6.4 — Least Privilege Access	PBAC and relationship-based systems both aim to restrict access to need-to-know.
	5.4 — Secure Configuration of Enterprise Assets and Software	Access engines and graph stores require controlled, reviewable configuration.
Recommendation — Maintain current account and entitlement inventory to support access decisions. Apply least privilege to every rule and relationship that grants access. Harden and review the configuration of authorization services and data stores.
OWASP Non-Human Identity Top 10	NHI-04 — Secrets and Credential Management	Authorisation systems often depend on machine credentials and tokens for enforcement.
	NHI-08 — Privilege Creep and Excessive Permissions	Relationship graphs and policies both risk granting access beyond intended scope.
Recommendation — Rotate and scope machine credentials used by authorization services. Review entitlements regularly to remove access that exceeds business need.

Practitioner Guidance

What to prioritise: Start by identifying whether the dominant authorisation driver is contextual rules or object relationships. If your reviewers spend most of their time arguing about business logic, PBAC is usually the cleaner fit; if they spend time untangling sharing, inheritance, and delegated access, a relationship model is usually the better base.

What to verify: Confirm that the chosen model can answer three questions without ambiguity: who can access what, why that access exists, and how quickly changes take effect. If the answer cannot be reconstructed from logs and source data, the design is too opaque for reliable governance.

Practitioner takeaway: The right model is the one that makes the dominant authorisation fact simplest to govern, not the one that can be stretched to represent everything.