Identity is not authorization
Identity and authorization are related disciplines. They are not the same discipline, and the industry has long treated them as if they were. That conflation is expensive.
Identity answers the question: who are you? It covers the provisioning of credentials, account creation, authentication, and the delivery of attributes about an entity — the signals, as we discussed in our first piece. And it matters enormously. You cannot make good access decisions without reliable identity signals.
But here's where the conflation creeps in: identity data is not always static, and authorization implementations are not always dynamic. In fact, organizations often build authorization systems that are rigid and assumption-heavy, long after their identity infrastructure has matured. ACLs (access control lists), role lookups, permissions hardcoded into application logic: these are static answers to a question that changes constantly.
Authorization answers the question: what are you allowed to do, right now, in this context, for this purpose? It is a decision, not a signal. And the gap between collecting the signals and making the right decisions is precisely where breaches live, where clinicians lose time, and where AI agents go rogue.
The most common example of this gap, and the one most organizations are currently grappling with, is Role-Based Access Control. It was the right answer for a long time. The problem is that most environments have outgrown it.
Why role-based access control isn't enough
Role-Based Access Control (RBAC) is not the villain of this story. It is a foundational and necessary input. The problem arises when organizations treat it as the whole answer.
A doctor's role rarely changes, but their context changes constantly: which patient they are treating, which clinic they are working from, which episode of care is active, what time it is. A static role lookup cannot account for any of that. It can tell a system that a user is a physician or a staff nurse or a hospital administrator. It cannot tell the system whether this physician should access this patient's record, right now, for this specific clinical purpose.
The same failure mode plays out in enterprise environments, often in a more subtle way. RBAC was designed to simplify access management by assigning clean, consistent permissions through roles. In practice, it rarely stays clean. As organizations grow, roles multiply until you have a separate role for every combination of job function, location, and tool access. Security teams call this "role explosion", and it is one of the more common ways a system designed to simplify access ends up making it harder to control. Role alone cannot tell you whether the right person, in the right context, for the right purpose, is making the right request — right now.
This is the insider threat reality that rarely gets discussed plainly: most breaches are not people breaking in. They are authorized users, or increasingly, authorized services and agents, doing things they should not be doing, because the authorization system was not built to ask the right questions.
It is no coincidence that healthcare became an early adopter of Zero Trust principles. When wrongful access puts a patient's safety at risk, "assume and verify later" is no longer acceptable.
Policy-based access as the unifying layer
Policy-Based Access Control does not replace RBAC. It orchestrates it — alongside Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC), which brings the end user's own consent directives into the equation.
This is what distinguishes a genuine authorization layer from a more sophisticated role lookup. PBAC evaluates all of these inputs together, in real time, at the moment of the request. The policy is not hardcoded into application logic; it is externalized, auditable, and enforced consistently across every system, service, and user type in the ecosystem.
In healthcare, this means access to this record, for this episode of care, consented to by this patient — not blanket access because someone holds a clinical title. The relationship between the provider and the patient matters. The timing matters. The patient's own directives matter.
In public sector environments, it means a social services caseworker can access a citizen's file for a specific program review, without that access automatically extending to unrelated agencies or datasets. Data can flow across departments and jurisdictions without surrendering sovereignty. Agencies do not need to share everything to share anything.
In enterprise, it means a contractor granted access to a project environment can do exactly what their role requires — and nothing more. Not because someone remembered to update a permission, but because the policy evaluated context, relationship, and scope in real time. One place to govern every human, service, and agent, regardless of how many systems, vendors, or automated processes are in play.
What makes this approach distinct is the end-user dimension. Throwing a relationship graph at authorization gets you closer, but without incorporating the user's own consent and delegation decisions, you are still building access control on behalf of people rather than with them. That distinction matters enormously in regulated environments, and increasingly in enterprise contexts where trust is a competitive differentiator.
The Zero Trust connection
Real-time, policy-based authorization is not a new idea dressed in new language. It is what Zero Trust has always pointed toward: never assume, always verify — not just at the perimeter, but at every point of access, for every request, from every entity.
What has changed is the urgency. As AI agents become active participants in enterprise and healthcare workflows, the stakes of getting authorization wrong have scaled dramatically. Agents are not cautious. They do not pause to question whether they should access a resource. Given a vague instruction and broad permissions, an agent will pursue its goal to the ends of its access, a pattern that security teams know as “lateral movement”.
Without a policy layer that evaluates intent, context, and scope at every step, the question is not whether an agent will overstep. It is when.
Moving forward
Most organizations have done the hard work on identity. They have invested in authentication, in credential management, in single sign-on. Those foundations matter and they should not be abandoned.
But identity gets you to the door. Policy-based authorization lets you do the work.
The next question — and the one we will take up in our final piece — is what happens when the entity at the door is not human at all.
About the Authors
Part One of The Architecture of Trust series, [Beyond the Handshake: Bridging the Identity Execution Gap], explored why identity alone cannot close the Execution Gap — and what it means to treat authorization as a strategic discipline.
