Human Managed’s move from RBAC to ABAC exposes policy limits

At a glance

What this is: Human Managed’s authorization story shows why RBAC was too rigid for customer-specific API access and why policy-driven ABAC became the practical alternative.

Why it matters: IAM teams should read this as a governance signal: once authorization must reflect customer context, product packaging, and operational state, static roles become a maintenance problem across human and non-human access models.

👉 Read Cerbos's full success story on policy-driven authorization at Human Managed

Context

Authorization breaks down when business logic has to reflect role combinations, customer context, and changing operational conditions. In this case, Human Managed was trying to avoid hard-coded permission logic in APIs while still tailoring access for different clients, which is a familiar pattern for teams that outgrow simple RBAC.

For IAM and application security teams, the real issue is not whether a policy engine exists, but whether access decisions can keep pace with product variation without forcing code changes. That tension shows up in both human access governance and non-human access control, especially when the same API layer must support multiple customer states and entitlement models.

The article is ultimately about policy abstraction, not vendor novelty. Human Managed chose a model that could express conditional access in a maintainable way because the older approach would have produced role nesting, brittle logic, and expensive change cycles.

Key questions

Q: How should security teams replace RBAC when access rules depend on customer context?

A: Teams should replace RBAC only where roles are being used to model business conditions rather than stable duties. The practical move is to keep identity in the application, move conditions into a policy layer, and evaluate access with attributes such as customer tier, resource type, and request context.

Q: Why do role-based models become hard to govern in multi-tenant applications?

A: Role-based models become hard to govern because each new customer rule can create another role combination or exception path. That quickly obscures effective permissions, increases review effort, and pushes authorization logic into code that is expensive to change safely.

Q: What signals show that authorization has outgrown static roles?

A: Warning signs include role nesting, repeated code changes for permission updates, inconsistent access logic across APIs, and frequent questions about who really has administrator access. When those appear, the access model needs policy abstraction rather than more roles.

Q: How do policy-driven authorization controls improve access governance?

A: Policy-driven controls improve governance by making rules explicit, testable, and versioned. That gives teams a cleaner change process, stronger auditability, and a way to update access decisions without rebuilding the application each time the business changes.

Technical breakdown

Why RBAC breaks down in customer-specific authorization

Role-based access control assigns permissions through predefined roles, which works when access patterns are stable and easy to model. It becomes brittle when the same user must receive different rights based on customer tier, transaction context, API route, or operational state. In that situation, roles either multiply uncontrollably or start embedding business logic, which turns authorization into a maintenance burden. The article’s example shows the classic role explosion problem: too many combinations, too little clarity, and no easy way to tell what effective access a user actually has.

Practical implication: if roles are starting to encode business exceptions, move those conditions out of application code and into a policy layer.

How ABAC separates identity from decision logic

Attribute-based access control evaluates decisions using attributes such as user identity, request context, resource metadata, and environment state. That separation matters because it lets the application ask a simple yes-or-no question while the policy layer handles the decision rules. In the article, the API fetches identity and metadata, sends the request to Cerbos, and receives a boolean result. That architecture keeps the application thin and makes policy changes faster because the code does not need recompilation every time access logic changes.

Practical implication: model entitlements as attributes and evaluate them outside the application path wherever policy churn is expected.

Why policy as code changes the authorization operating model

Policy as code moves access rules into versioned, testable files, which makes authorization more like software delivery than manual administration. The article describes YAML-based policies validated in CI and deployed through Git-driven workflows, with runtime decisioning handled separately from application logic. That approach improves reviewability and change control, but it also means the governance team must treat policies as production artefacts. The advantage is not just cleaner code. It is a more defensible change process for access decisions that evolve quickly.

Practical implication: put authorization policies under source control, test them in pipeline, and govern them with the same discipline as other production code.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

RBAC failures are often policy-design failures, not implementation failures. Human Managed’s problem was not that roles were missing, but that roles could not express customer-specific authorization without collapsing into nested exceptions. That is the point where RBAC stops being a governance model and becomes a hidden business logic layer. The practitioner lesson is to recognise when access design is carrying product complexity that should live elsewhere.

ABAC becomes the right control pattern when authorization must reflect changing business context. The article shows access decisions being driven by user data, backend metadata, and request context rather than static role membership. That is a stronger fit for environments where product packaging, customer segmentation, and operational conditions shift often. The implication is that entitlement governance must move from role assignment to attribute quality and policy discipline.

Policy-as-code is the real governance shift, not just a new decision engine. Human Managed describes a model where policies are written in YAML, validated in CI, and deployed independently of application releases. That reduces the blast radius of authorization change and shortens operational feedback loops. The practitioner conclusion is that access control should be managed as a controlled software asset, not as embedded logic scattered through services.

Authorization maintenance belongs in the same lifecycle conversation as entitlement sprawl. When policy updates can be made in minutes instead of code deployments, the control problem changes from editing applications to governing policy quality, review, and drift. That makes access review, change approval, and policy testing part of the IAM operating model. The practitioner takeaway is to treat authorization as a living control plane, not a one-time design choice.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how quickly access governance weakens when controls are handled informally.
• Policy abstraction matters when access logic is changing quickly, and the same pressure shows up in non-human governance across Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Policy abstraction is becoming a governance requirement, not an implementation preference. As product packaging, customer segmentation, and API behaviour become more dynamic, authorization models that depend on static role maps will keep failing under operational change. Teams should expect more pressure to move decision logic into versioned policy layers and to manage those policies with the same discipline as other production assets.

With 59.8% of organisations already seeing value in dynamic ephemeral credentials in our research, the broader pattern is clear: identity controls are shifting toward context-aware decisions rather than permanent entitlements. That shift affects human, workload, and service access alike, especially where access must reflect short-lived business state.

Role explosion is the hidden cost of trying to simplify access too early. Once teams start using roles to represent customer exceptions, the access model becomes harder to certify, harder to audit, and easier to break during change. A policy-led architecture gives practitioners a cleaner path to scale without turning authorization into a code maintenance problem.

For practitioners

• Map where RBAC is carrying business logic Inventory APIs and services where roles are being used to encode customer tier, product packaging, or request context. Those are the candidates for attribute-based policy decisions instead of role expansion.
• Move authorization rules into version-controlled policy files Store access logic in source control, test it in pipeline, and require review before policy changes reach production. This makes access changes auditable and reduces hidden drift.
• Define the attributes your access decisions actually need Identify which user, resource, and environmental attributes are required for accurate decisions, then standardise how the API fetches and validates them. Poor attribute quality makes ABAC brittle.
• Separate decision-making from application code Keep the application responsible for requesting an authorization decision and let a dedicated policy layer return allow or deny. That preserves maintainability when rules change frequently.

Key takeaways

• Human Managed’s story shows how RBAC becomes brittle when authorization must reflect customer-specific conditions and changing operational context.
• The operational value comes from moving access decisions into policy as code, where changes are easier to test, review, and deploy without rewriting application logic.
• For IAM teams, the practical signal is clear: when effective permissions become hard to explain, the model has outgrown static roles.

Key terms

• Role-Based Access Control: A permission model that grants access through predefined roles instead of evaluating each request in context. It works well for stable job functions, but it becomes brittle when business rules, customers, or application paths change faster than role definitions can be maintained.
• Attribute-Based Access Control: A decision model that evaluates identity, resource, and environment attributes before allowing access. In practice, it lets teams separate policy from application code so authorization can change as business context changes without rebuilding the product.
• Policy as Code: An operating model where access rules are written, reviewed, tested, and deployed like software. It improves auditability and change control, and it becomes especially useful when entitlement logic is too complex to safely maintain inside application code.
• Effective Permissions: The real access a user or system has after all roles, rules, exceptions, and inherited entitlements are combined. This is the number that matters in governance, because it often differs from the access that appears on paper or in a role catalogue.

Deepen your knowledge

Policy-driven authorization and ABAC design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving away from hard-coded access logic, the course is a useful next step.

This post draws on content published by Cerbos: Human Managed's authorization story and its move from RBAC to ABAC. Read the original.