RBAC, ABAC and PBAC: what access control models mean for NHI governance

At a glance

What this is: This is an analysis of RBAC, ABAC, and PBAC as access-control models, with the key finding that hybrid policy-driven governance is often the practical answer to role bloat and audit pressure.

Why it matters: For IAM and NHI practitioners, the article frames a familiar human-identity problem that also shows up in service accounts, bots, and agents: static permissions age badly when access changes faster than teams can review it.

👉 Read Clarity Security's analysis of RBAC, ABAC and PBAC for access governance

Context

Access control is the decision layer that determines who or what can reach a system, data set, or workflow. In NHI governance, the same logic applies to service accounts, API keys, tokens, certificates, and AI agents, which often inherit access patterns from human-centric IAM designs that were never built for scale, speed, or context.

The practical gap is not whether organisations can assign permissions. It is whether they can explain and revoke them cleanly as identities change, tasks shift, or automation expands. That is why RBAC, ABAC, and PBAC are more than architecture terms. They are governance choices that shape auditability, least privilege, and the blast radius of both human and non-human access decisions.

Key questions

Q: How should security teams decide between RBAC, ABAC, and PBAC?

A: Start with the stability of the access pattern. Use RBAC for broad, repetitive entitlements, ABAC for decisions that depend on context, and PBAC when you need readable policy logic across both. Most organisations need a hybrid model because no single approach handles every lifecycle and audit requirement well.

Q: When does RBAC create more risk than it reduces?

A: RBAC becomes risky when exceptions outnumber standard cases, because teams compensate by creating duplicate roles and retaining access longer than intended. At that point, the model increases review effort, hides over-privilege, and makes revocation slower. That is a governance problem, not just a directory problem.

Q: What is the difference between ABAC and PBAC in practice?

A: ABAC decides access by evaluating attributes such as role, location, device, or time. PBAC expresses the decision as a policy that may use those same attributes, which makes the logic easier to read and audit. In mature environments, PBAC often acts as the control layer over ABAC-style inputs.

Q: How can organisations reduce role bloat without losing control?

A: Limit roles to stable, high-level access and move exceptions into policy rules tied to identity attributes or lifecycle events. That keeps the directory cleaner and makes access changes easier to govern. The goal is to reduce custom roles without creating unmanaged special cases.

Technical breakdown

RBAC vs ABAC vs PBAC: how the decision logic differs

RBAC grants access through membership in roles, which makes it straightforward but rigid. ABAC evaluates attributes such as department, location, device, or time, allowing the decision engine to respond to context. PBAC sits closer to the policy layer, where rules can combine roles and attributes in a readable form. In practice, PBAC can be the governance wrapper while ABAC supplies the decision inputs. The technical trade-off is between simplicity and precision. The more static the model, the more likely teams will create exceptions; the more dynamic the model, the more the environment depends on clean identity data and policy hygiene.

Practical implication: Treat the model choice as an operating decision, not a terminology preference, and map it to the systems that actually issue and review access.

Why role bloat appears in static access models

Role bloat happens when a static role cannot express real-world exceptions, so teams create near-duplicate roles for one-off cases. Over time, the directory becomes crowded with narrowly scoped groups that are hard to audit and harder to retire. This is especially damaging when temporary projects, contractor access, or departmental changes occur frequently. The core failure is not the role itself. It is using roles as a substitute for policy logic. Once exceptions become normal, the access model stops reflecting how work is actually done and starts reflecting accumulated administrative work.

Practical implication: Use role minimisation as a design goal and reserve roles for broad entitlements, not exception handling.

Attribute and policy-based access for dynamic identities

ABAC and PBAC are better suited to environments where access needs to change with the user, device, time, or business state. That matters for remote work, complex approval paths, and lifecycle-driven access changes, because the policy can react when source attributes change. For NHI governance, the analogy is strong: service accounts, bots, and AI agents also need task-scoped access that expires or changes when context changes. The technical requirement is reliable source data, consistent normalization, and clear policy evaluation so that access is not frozen in time after the original request.

Practical implication: Connect policy evaluation to authoritative identity sources and lifecycle events so access changes automatically instead of waiting for tickets.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hybrid access governance is now the default posture, not a compromise. Static roles still have value for broad, low-risk entitlements, but they are too blunt for modern access decisions. Organisations that try to force every exception into RBAC usually create operational debt that later shows up as audit pain and overexposure. The practical conclusion is that access control should be layered, with roles for baseline access and policies for the edge cases.

Policy-based access control is where auditability and adaptability meet. When policies are written in human-readable form, reviewers can trace why access exists instead of reconstructing a decision from tickets and group membership. That matters for governance because explainability is not a cosmetic requirement. It is what allows organisations to prove least privilege and support access review at scale. Practitioners should treat policy readability as a control objective, not a convenience feature.

Ephemeral access patterns expose the weakness of role-centric thinking. As organisations automate more workflows, access is increasingly tied to time-bound tasks, changing context, and delegated decisioning. That makes rigid group models less useful and more dangerous. The access model must follow the lifecycle of the identity, including creation, change, review, and removal. Teams that ignore that lifecycle will keep compensating with manual exceptions.

Access control design is becoming an NHI governance problem as much as a human IAM problem. Service accounts, API keys, and AI agents do not fit neatly into organisational charts, but they still require decisions about who can create, use, and revoke access. If teams rely only on RBAC logic, they risk extending human-admin patterns into machine identities that need faster review and tighter scoping. Practitioners should align access design with identity lifecycle control, not with convenience in the directory.

Role explosion is really a symptom of missing policy discipline. The industry often treats role sprawl as an operational nuisance, but it is usually evidence that the access model is not expressive enough for the business. Once the exception rate rises, the identity stack starts encoding process debt. The better answer is to define where roles stop and policy logic begins, then enforce that boundary consistently. That is the difference between a manageable directory and an access estate that grows faster than governance can follow.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• For a broader governance baseline, Top 10 NHI Issues helps teams map access-control choices to the most common NHI failures.

What this signals

Access-control modernisation is becoming a lifecycle problem, not a permission problem. As organisations add more dynamic identities, the real question is whether access can be created, changed, reviewed, and removed at the same speed as the work itself. That is where policy-driven models outperform static directories, especially when paired with NIST Cybersecurity Framework 2.0 governance expectations.

Identity blast radius is the concept teams should start measuring. The more exceptions, duplicates, and lingering entitlements an access model allows, the more damage a single compromised identity can do. For machine identities in particular, the boundary between human IAM and NHI governance is fading, which means access policy design needs to account for bots, service accounts, and agents as first-class identities.

A practical next step is to make policy coverage measurable across both human and non-human identities. Teams that can show where RBAC ends, where attribute logic begins, and how access is revoked will be better positioned to defend least privilege in audits and incident reviews.

For practitioners

• Separate baseline access from exception handling Use RBAC only for broad, stable access like common productivity tools, and move departmental, device, time, or location-based decisions into policy logic.
• Reduce role bloat before expanding the directory Review existing roles for one-off exceptions, duplicated entitlements, and temporary project access that should become attribute or policy rules instead.
• Tie access changes to authoritative identity events Connect joiner, mover, and leaver workflows to HR or directory source events so access updates automatically when identity attributes change.
• Document why access exists in policy form Record access decisions as readable policies with the minimum attributes needed for approval, review, and revocation so auditors can follow the logic.
• Apply the same lifecycle discipline to NHIs Give service accounts, tokens, and AI agents time-bound access, explicit owners, and revocation triggers so machine identities do not inherit permanent privileges.

Key takeaways

• Static RBAC models are easiest to understand, but they become fragile when exceptions, remote work, and lifecycle changes multiply.
• ABAC and PBAC improve precision and auditability, but only if identity data is clean and policy logic is maintained.
• For NHI governance, the same access-control debate applies to service accounts, tokens, and AI agents that need time-bound, reviewable privileges.

Key terms

• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: A model that evaluates identity and environmental attributes, such as department, device, location, or time, before granting access. It gives teams more precision than static roles and is better suited to dynamic environments. The main dependency is reliable attribute data that can be trusted at decision time.
• Policy-Based Access Control: A model that expresses access decisions as readable policies, often combining roles and attributes into a single rule set. It is valuable when organisations need both flexibility and auditability. The policy layer should be clear enough for reviewers to understand why access was granted or denied.
• Role Bloat: The accumulation of too many similar or narrow roles created to handle exceptions that a static model cannot express cleanly. It is a sign that access governance has become administrative maintenance rather than controlled design. Role bloat increases review overhead and makes revocation harder to reason about.

What's in the full article

Clarity Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how RBAC, ABAC, and PBAC behave across common business scenarios.
• Audit-oriented comparisons that show how reviewers trace access decisions under each model.
• Guidance on using hybrid access models for role changes, temporary access, and exceptions.
• Product-specific workflow details for automating access reviews and revocation.

👉 The full Clarity Security article covers role bloat, audit evidence, and hybrid access patterns in more detail.

Deepen your knowledge

RBAC, ABAC and PBAC are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing access governance for human and non-human identities together, it is worth exploring.