Most of my recent writing has lived in the world of AI, agents, and the architectural questions that come with them. Let’s be honest, the AI hype can get really old really quick, even for me. So in the spirit of taking a break, this post is a step back, a return to some of the foundational concerns that architects deal with regardless of what wave of technology they are riding.
One of those foundational concerns is taxonomy. A significant part of what architects do for an organization is name things, group them, and establish a shared language that lets teams make decisions with confidence. Done well, taxonomy acts as an invisible infrastructure that supports smooth business operations and reduces friction, especially at the boundaries. Done poorly, it creates the illusion of clarity while quietly compounding confusion downstream.
“Taxonomy is invisible infrastructure… Done poorly, it creates the illusion of clarity while quietly compounding confusion downstream.”
The tricky part is that taxonomy is never purely academic. The categories we establish carry assumptions about how things work and how they relate to each other, and those assumptions have a way of hardening into convention before anyone stops to question them. Sometimes the purpose a category serves matters far more than whether it is technically precise.
Authorization models are a good example of this tension playing out in practice. RBAC, ABAC, ReBAC, and PBAC are regularly presented as a coherent family of peers, and for most teams that framing is good enough to get started. But for architects responsible for giving organizational direction, good enough is worth examining.
Authorization Models Example
Authorization models give architects a structured way to answer a deceptively simple question: who gets access to what, and under what conditions? Over time, a small family of models has emerged as the dominant vocabulary for answering that question, each one approaching it from a different angle.
RBAC organizes access around roles. Rather than assigning permissions directly to individuals, the model introduces roles as an intermediary layer. Users belong to roles, and roles carry permissions. RBAC tends to be appealing. Roles tend to map naturally onto how organizations already think about job functions and responsibilities, which makes RBAC relatively easy to implement, explain, and administer.
ABAC takes a more expressive approach, organizing access around attributes. Access decisions are made by evaluating characteristics of the user, the resource being accessed, and the environment in which the request is made. A user’s department, the classification level of a document, the time of day, and the network location of the request can all factor into a single access decision. That expressiveness comes with added complexity, but it also enables access control that is far more context-sensitive than roles alone can provide.
ReBAC shifts the organizing principle to relationships between entities. Access is determined not just by who you are, but by how you are connected to the thing you are trying to reach. This makes it particularly well suited to collaborative systems where ownership, delegation, and sharing are core to how the product works. Google’s Zanzibar paper, which underpins systems like Google Drive’s sharing model, brought ReBAC into mainstream architectural thinking.
PBAC rounds out the family by centering policy as the primary organizing dimension. Rather than encoding access logic directly into application code or database schemas, PBAC externalizes it into explicit, human-readable policies that can be managed independently. Access decisions are the result of evaluating those policies against the context of a given request, and the policies themselves become a first class artifact in the system.
“Externalizing access logic into policy means it can be versioned, reviewed, tested, and deployed with the same rigor we apply to any other part of the system. Access control stops being a buried implementation detail and becomes something the organization can actually govern.”
Presented this way, the four models form a tidy progression. Each one names a primary dimension, roles, attributes, relationships, or policy, and builds its decision logic around that dimension. It is a satisfying taxonomy, and for most teams it is a workable one.
Issues with Tidy Taxonomy
Tidy taxonomies have a way of becoming less tidy the moment you try to apply them to real systems. Authorization models are no exception.
RBAC systems rarely stay pure for long. As soon as an organization needs to make access decisions that depend on something other than job function, attributes start creeping in. A role might only grant access during business hours, or only from a corporate network, or only to resources tagged with a certain classification. At that point the system is still called RBAC, but it is quietly doing ABAC work underneath.
ABAC systems have the same tendency in reverse. Attributes need to come from somewhere, and one of the most common sources is a role store. A user’s department, their clearance level, their team membership: these are attributes in the ABAC sense, but they are also roles by another name. ABAC systems also frequently store and traverse relationships between entities, borrowing graph structures that would feel at home in a ReBAC implementation. ReBAC systems, for their part, still need to define the entities they connect, and those entity definitions often look remarkably like roles.
“In practice, the boundaries between these models are more like gradients than walls. Real systems borrow across them constantly, and the model name tends to reflect the primary organizing dimension rather than any strict exclusion of the others.”
So what the taxonomy is actually doing here. These models do not describe four mutually exclusive implementations. They describe four different centers of gravity. A system is RBAC because roles are doing the primary work, not because attributes and relationships are absent.
That reframing makes the question about PBAC considerably harder to answer. If the distinction between models is about primacy rather than purity, then the question becomes: what does it mean for policy to be primary? And furthermore – don’t the other models not have policy underneath as well?
An RBAC system has rules about how roles map to permissions. An ABAC system has conditions that determine how attributes combine into decisions. A ReBAC system has logic that defines which relationship types grant which kinds of access. All of these are policies in any reasonable sense of the word. They may not be called policies, and they may not be managed as explicit artifacts, but they are expressing the same thing: a set of rules that governs access decisions.
So if policy is already present in every authorization model, what exactly is PBAC’s claim to distinction?
What is a policy, anyway?
The word policy is doing a lot of work in PBAC, and it is worth slowing down to examine what it actually means in this context. In everyday language, a policy is a rule or a set of rules that governs behavior. By that definition, every authorization model is a policy model. The question is not whether policy is present but whether treating it as the primary dimension is a meaningful architectural distinction or a rebranding of something that was already there.
The case for distinction rests on a specific interpretation of policy: not policy as logic, but policy as artifact. In PBAC, the claim is not just that access decisions follow rules. It is that those rules are explicit, externalized, and managed as a first class concern. That is what separates a PBAC system from an RBAC system that happens to have some conditional logic buried in a middleware layer. The logic may be equivalent, but one can be governed and the other is not focused on that.
“The difference between policy as logic and policy as artifact is the difference between access control that exists in your system and access control that your organization can actually see, review, and change.”
That is a genuinely powerful idea, and it explains why tools like Open Policy Agent and Cedar have found real traction. But those tools also expose a tension that the tidy four-model taxonomy does not prepare you for.
OPA is commonly described as a policy engine, which places it squarely in the PBAC column. But when you look at how it is actually used, the picture gets complicated quickly. OPA can express role-based logic, evaluating whether a user holds a particular role before granting access. It can express attribute-based logic, combining characteristics of the user, the resource, and the environment into a contextual decision. In principle, you could even model relationships as data and feed them into OPA, expressing something that resembles ReBAC through a policy lens. PBAC, in this sense, is not limited to one of the other models. It can absorb any of them.
But absorbing them is not the same as replacing them, and that distinction matters in practice. Modeling relationships as flat data inside a policy engine works, but it does not scale the way a purpose-built relationship engine does. Systems like OpenFGA, which is purpose-built for relationship-based authorization, are optimized for the kind of graph traversal that ReBAC requires. Recreating that inside OPA is technically possible but architecturally awkward, in the same way that you could store time-series data in a relational database but probably should not.
“In practice, PBAC tools do not replace the other models. They sit above them, consuming their outputs and expressing the final decision. That architectural reality is hard to see when PBAC is presented as a peer in a flat taxonomy.”
What practitioners actually do is combine these tools in layers. A ReBAC system like OpenFGA resolves relationship chains. An identity provider or directory resolves roles and attributes. OPA or Cedar sits downstream, gathering those resolved inputs and evaluating them against an explicit, versioned policy to produce a final auditable decision. The policy engine is not the foundation of that stack, but rather it is the layer where everything comes together.
That practical reality sets up two very different ways of thinking about what PBAC is, and which framing you choose has real consequences for how you give architectural direction.
Two Ways to Think About PBAC
The tension we have been building toward resolves into two distinct framings.
The first framing treats PBAC as a peer model alongside RBAC, ABAC, and ReBAC. In this view, policy-as-code is the distinguishing dimension, the same way roles distinguish RBAC or attributes distinguish ABAC. What sets PBAC apart is not the presence of policy logic but the deliberate elevation of that logic into an explicit, managed artifact. The governance benefits that come with that elevation, versioning, auditability, CI/CD integration, separation from application code, are real and meaningful. Under this framing, choosing PBAC is a model selection decision, similar in kind to choosing RBAC or ABAC, and the four models sit comfortably side by side as a complete vocabulary for authorization.
This framing has practical appeal. It gives teams a clean mental model for conversations about authorization strategy. It maps onto how vendors and tools tend to present themselves. And it is not wrong, exactly. The governance benefits are genuine (although they don’t come free – subject for another day), and treating policy management as a first class concern is a meaningful architectural choice regardless of what you call it.
“The first framing is not wrong. It is just answering a different question than the one architects most need to answer.”
The second framing treats PBAC not as a peer to the other models but as an orthogonal concern. RBAC, ABAC, and ReBAC answer the question of what access depends on. PBAC answers a separate question entirely: how should access logic be expressed, governed, and managed across the organization? These are not competing answers. They operate on different axes, which means any of the models can be combined with PBAC. An organization can have RBAC with PBAC, or ReBAC with PBAC, treating the access model and the governance pattern as independent decisions that reinforce each other rather than replace each other.
This framing is less intuitive at first because it requires letting go of the four-peer mental model that the taxonomy naturally encourages. But once that shift happens, the picture actually becomes tidier. Teams can reason about which model best fits their domain, whether that is roles, attributes, or relationships, while the organization separately establishes the infrastructure and practice of policy-as-code that governs whichever model they choose. The two decisions complement each other without collapsing into one.
“Under the second framing, the question is not which model to choose instead of PBAC. It is how to govern whatever model you have chosen. That is a more useful question for an architect to be answering.”
The choice between these two framings might seem academic, but it has real consequences for how organizations make decisions about their authorization architecture.
The Architectural Pattern That Wins
The case for the second framing comes down to what architects are actually trying to accomplish when they are attempt to establish an organizational direction. Architectural guidance is most valuable when it helps teams make decisions that compound well over time, when the choices made early create options rather than constraints, and when the language used to describe a system reflects how that system actually behaves.
The peer model framing does not do that reliably. When PBAC is presented as a fourth model in a flat list, organizations tend to treat it as a mutually exclusive choice. Teams either adopt PBAC or they adopt RBAC. They evaluate OPA against their existing role model and wonder whether they need to migrate. The taxonomy implies substitution, and substitution implies a migration cost that many teams are not willing to pay, so they defer the decision entirely and the governance benefits of policy-as-code never materialize.
“Presenting PBAC as a peer model turns a governance decision into a migration decision. Most organizations will choose not to migrate, which means they will also choose not to govern.”
But deferral is not the most damaging consequence of the wrong framing. The more insidious outcome is silent misalignment. A team that deploys OPA and believes they are doing PBAC, but whose policies are entirely expressing role-based logic, is not making an obvious mistake. They are doing something reasonable that the taxonomy quietly encouraged. The problem surfaces later, as the application evolves and access requirements become more contextual or relational, and the team begins to feel friction they cannot name. The system resists change in ways that are hard to articulate, conversations about authorization become muddled, and decisions get made by feel rather than by shared understanding. The taxonomy did not cause a bad implementation. It caused an imprecise one, and imprecision compounds.
“The most expensive architectural mistakes are rarely the ones teams can see. They are the ones that have no language yet, the misalignments that live quietly in the gap between what a system is called and what it actually does.”
This is precisely what architectural direction is for. Not just to recommend the right tool or model upfront, but to establish a shared language that lets teams recognize drift, have honest conversations about why something feels hard, and course correct with clarity rather than intuition. When the taxonomy is wrong, that language fails at the moment it is needed most.
The architectural pattern framing restores that clarity. If PBAC is understood as an approach to managing and expressing access logic rather than a replacement for an existing model, then adoption becomes additive. An organization running a mature RBAC implementation does not need to dismantle it. They need to externalize its logic into a policy engine, bring it under version control, and establish the practice of reviewing and deploying access changes the way they review and deploy code. The model stays. The governance improves.
The same is true for teams building new systems. Rather than asking which model to choose, they can ask two cleaner questions independently. First, what does authorization depend on in this domain, and which model best reflects that? Second, how will the organization manage, audit, and evolve that authorization logic over time? The first question leads them to RBAC, ABAC, or ReBAC based on the nature of their domain. The second question leads them to PBAC as a governance commitment that applies regardless of which model they chose.
“Good architectural direction separates decisions that belong together from decisions that merely appear together. The model you choose and the way you govern it are related but separable concerns, and treating them as one conflates two decisions that are better made independently.”
This is also where the naming problem earns its weight. PBAC is a naming problem as much as it is an architectural one. The name places it in a category that shapes how people use it, and in this case the category is doing quiet harm by making a governance pattern look like a model selection.
All of this to say…
Authorization is not a glamorous problem. It sits beneath the features teams are excited to build, and it tends to attract attention only when something goes wrong. That invisibility is part of what makes the taxonomy matter. When a concept is rarely examined, the language used to describe it has an outsized influence on how it gets implemented, and how it gets implemented has a way of becoming permanent.
PBAC deserves a more precise home in that language. Not because taxonomical exactness is valuable for its own sake, but because the right framing unlocks a more useful conversation. When architects present PBAC as a peer model, they are answering a question about model selection. When they present it as an architectural pattern, they are answering a question about organizational capability. The second question is harder to ask, harder to answer, and considerably more important.
“The goal of architectural taxonomy is not to categorize things correctly. It is to give organizations the language to make better decisions. Sometimes those are the same thing, and sometimes they are not.”
The broader lesson extends beyond authorization. Architects regularly encounter concepts that resist clean categorization, ideas that sit awkwardly in the taxonomy because they are operating at a different level of abstraction than their neighbors. The instinct to force them into the existing structure is understandable. Taxonomies are supposed to be complete. But completeness is not the same as usefulness, and the most powerful architectural guidance often comes from recognizing when a concept belongs in a different kind of conversation altogether.
Naming is, indeed, one of the hardest problems in computer science. The consequences of naming things poorly are long, quiet, and expensive. PBAC is a good example of a concept that got placed in a reasonable category for intuitive reasons, and that reasonable placement has been quietly shaping how organizations think about authorization ever since.
Leave a Reply