Compare role-based, attribute-based and relationship-based access control as ways to express permissions, and describe how you would choose between them for a multi-tenant product that supports sharing and delegation.

## What each model actually is **Role-based.** Permissions attach to named roles; principals hold roles. The model is finite and closed, which is its whole value: access reviews, audits and 'who has this permission' are enumerations over data you own. It works well for operation-level rules that do not depend on which record is involved. **Attribute or policy-based.** A policy evaluates attributes of the subject, resource, action and environment. It expresses conditions no role can - clearance versus classification, business hours, device posture, whether the requester is in the same region as the data. The cost is that the policy is a program: reasoning about the whole system means reasoning about a program's behaviour over all inputs rather than reading a table. **Relationship-based.** Access derives from a graph of tuples: this user owns that document, this group contains that user, this folder is the parent of that file. It answers 'can this principal do this' by traversal and, importantly, also answers 'list everything this principal can see', which listing endpoints need and which policy engines are notoriously bad at. ## How the differences bite - **Role explosion.** As soon as permission depends on the record - project, tenant, region, lifecycle state - roles multiply combinatorially, and the enumerability that justified the model disappears into thousands of near-identical roles nobody can audit. - **Reverse queries.** Roles answer them by lookup, graphs by traversal, attribute policies often not at all without brute-force evaluation. If your product must show 'who has access to this file', that requirement alone constrains the model. - **Consistency.** A relationship store has a genuine ordering problem: if a share is revoked and a check reads a stale replica, access persists after the user was told it was removed. Systems that take this seriously return a consistency token from the write and require it on subsequent checks, so a decision is never made from state older than the revocation. - **Attribute trust and freshness.** An attribute policy is only as good as its inputs. If attributes arrive in a credential minted earlier, the policy is deciding on stale facts; if any attribute is client-supplied, it is not an input, it is an attack. ## The architectural split, and its cost Separating the decision point from the enforcement point lets policy be authored, versioned and tested centrally while every service enforces it. The costs are real and must be decided rather than discovered: latency on every request; an availability dependency where you must choose in advance whether enforcement fails closed and takes an outage or fails open and takes a breach; and cache staleness if you soften either. Sidecar or in-process evaluation with a distributed policy bundle trades freshness for availability; a central service trades the reverse. ## Choosing for the product described Multi-tenancy first: tenant isolation should not be a policy decision at all but a structural one, enforced by scoping data access so a cross-tenant read cannot be expressed. Layering it as one more rule in a policy engine puts your strongest boundary at the mercy of a policy bug. Above that: roles for coarse operation-level authority (billing administrator, auditor, member), because it is auditable and users understand it. A relationship model for object-level access, because sharing, folder inheritance and delegation are relationships, and modelling them as roles produces exactly the explosion described. Attribute conditions as a thin overlay for context - require a recent strong authentication for exports, deny outside permitted regions - because those are conditions on a permission rather than a source of one. ## The failure mode that actually kills systems Two half-models. Some checks in a policy engine, others hand-written in handlers, a third set implied by data scoping, and no single vocabulary for resources and actions. Then nobody can answer what a principal can do, migrations stall, and each new service invents its own dialect. Pick one enforcement architecture, name resources and actions once, and require every service to go through it - the coherence is worth more than the expressiveness of any individual model.