Every enterprise permission system in production today rests on roles. Salesforce has a role hierarchy. Snowflake grants roles. Entra assigns them, SharePoint inherits them, and the service desk provisions them on somebody’s first morning.
This is not a legacy choice nobody got round to replacing. Roles are the thing that worked.
The org chart becomes the permission model
The idea is older than most of the systems running it. Role-based access control “began with multi-user and multi-application on-line systems pioneered in the 1970s”, as Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman put it in Role-Based Access Control Models, the paper that formalised the family of models, published in IEEE Computer in February 1996.
What it replaced was worse. Before roles, a permission attached to a person, and every joiner, mover and leaver meant editing lists by hand across every system that held one.
Roles moved the attachment point. Permissions belong to a job function, users belong to the function, and the two change at different speeds. The 1996 paper notes that permissions assigned to roles change slowly while membership churns constantly.
That single move is why roles are everywhere. It took a problem that scaled with headcount and made it scale with the org chart instead.
A NIST study of 28 organisations, cited in the same paper, found most based access decisions on “the roles that individual users take on as part of the organization”. It also found something that has aged unnervingly well: organisations “typically viewed their access control needs as unique and felt that available products lacked adequate flexibility”.
The exception that becomes a role
Roles decide by job title, and job titles are a coarse instrument. The finance analyst who needs one account in one region gets the role covering every account in every region, or gets an exception. Exceptions become roles. Roles multiply until the set of them is no more legible than the list of people it replaced.
There is a sharper limit, and the 1996 paper is the one that states it. RBAC supports least privilege and separation of duties, but “RBAC cannot enforce application of these principles. The security officer could configure RBAC so it violates these principles.” Roles are a mechanism. Whether they are tight depends on how somebody configured them, on a Tuesday, years ago.
The authors were also plain that roles were never meant to answer alone:
RBAC is not a panacea for all access control issues… Other forms of access control can be layered on top of RBAC for this purpose… We view control of sequences of operations to be outside the scope of RBAC, although RBAC can be a foundation on which to build such controls.
They went further, describing roles coexisting with the older discretionary and mandatory models, where “access is allowed if and only if permitted by RBAC, MAC, and DAC”. Three systems, each holding a veto. Reconciliation was in the design from the beginning.
XACML, and the cost of a policy language
The first serious answer was to decide on attributes rather than titles. Attribute-based access control, with XACML as its policy language, lets a rule read the request itself: the record’s owner, the user’s department, the time of day.
It is more expressive than roles. It is also a language, which means somebody has to write policy in it and keep writing it as the business changes, and that cost lands on whoever already owns the backlog.
Zanzibar decides per object
The second answer came from Google. A team formed in the 2010s to secure objects across the company’s products, where a single object might be handled by several systems at once: the core product, and the search index that makes it findable. What they built became Zanzibar, published at the USENIX Annual Technical Conference in 2019.
Zanzibar decides by relationship. Access is not “you are a manager” but “you are an editor of the folder this document sits in”. The permission attaches to the thing, follows the chain, and answers per object.
The approach predates the paper. Carrie Gates described relationship-based access control in 2006. Zanzibar is what put it behind Google’s own products and then published how.
Two properties make it tighter than roles. A decision is about one object, so nobody is granted a region in order to reach an account. And relationships compose, so the chain that grants access is also the explanation of it: ask why, and the answer is a path rather than a shrug.
It is also a superset. Relationship-based models can express role-based and attribute-based ones, which makes roles one shape a relationship can take rather than a rival to it. Comparisons that pit the two against each other are describing a contest the literature does not have.
Zanzibar carries a warning as well as a design. The paper names the new enemy problem: Alice removes Bob from a folder’s access list, then asks Charlie to move some documents into that folder. If those two changes are not ordered correctly, Bob reads documents he was never meant to see. Nobody attacked anything. Every permission was correct on its own, and the sequence was wrong.
The migration nobody has a spare year for
The design is public and there are open implementations to build on. What adopting one inside a large organisation actually costs is worth setting out, because the obstacles are structural rather than technical.
Adopting it internally means re-expressing your permissions as relationships. Every system, every object, every inherited grant somebody set in 2019 and left behind. Then keeping that expression in sync with the systems it came from, forever, because the moment it drifts you are enforcing a decision your source of truth no longer agrees with.
Google could do this. Google was also building the products at the same time, on one identity system, with the authors of the paper in the building.
The enterprise case differs in a way that matters more than scale. Most systems holding your data are not yours to change. Salesforce enforces its own sharing rules inside Salesforce, and Snowflake evaluates its own row access policies at the moment the query runs, so the most you can do is mirror those rules somewhere else and hope the copy stays true.
Then there is the question of who owns the work. Cross-system permissions belong to no one team. The Salesforce administrator knows the sharing rules and does not run the warehouse; the data engineer knows the row policies and has never seen the service desk’s provisioning logic; security is accountable for all of it and has write access to almost none.
A programme needing three teams for a year, with nothing to demo at the end, does not survive its first roadmap review.
The systems you actually run make it harder still. A mature permission model is rarely one model. It is roles, plus groups, plus direct grants to individuals, plus scoping by site or region, plus a house rule for when two of those disagree. Usually the most generous wins, except for the pairs where it must not.
That accretion is not a failure of discipline. It is what happens when a system serves a real organisation for a decade.
So the better model sits where better models often sit: correct, demonstrated, and priced in a migration nobody has the year to spend.
Sharing rules, row policies, access lists
Most enterprises already bought fine-grained control years ago, and are running it today.
Salesforce has sharing rules sitting on top of its role hierarchy. Snowflake has row access policies on top of its grants. Google Drive has per-file access lists owing nothing to anybody’s job title. These are per-object decisions, made correctly, by systems that know their own data better than any external model would.
Every one of them answers about itself. None of them answers about the others. The finance analyst’s entitlement is true in four places and assembled in none, and the only thing that ever reconciled it was a person with enough context to hold four answers at once and decide.
The agent asks all four at once
An agent asks on behalf of a person, across several of those systems, in a single breath, at a rate no person could. Every individual system answers correctly. The question nobody’s stack was built to answer is the one that spans them.
That question does not require rebuilding anyone’s permission model, which is fortunate, because nobody is going to. The rules are already written. They are fine-grained, they are current, and the systems that own them hold them.
Lattuss reads what those systems already say, reconciles it into one answer, and decides at the moment the agent asks. Nothing gets ripped out. The model underneath stays exactly as it is, including whatever somebody configured on a Tuesday years ago.
Roles were always meant to be a foundation. The people who defined them said so in 1996.