TL;DR: C1.ai shows cloud infrastructure access governance breaks when tools flatten role-and-scope hierarchy into SaaS-style entitlement rows, because Azure tenants can expose more than 1 million synced entitlements that become roughly 50 million combinations at full coverage. Precision, reviewability, and least-privilege scoping all degrade when the governance model no longer matches how the cloud actually grants access.
At a glance
What this is: This is a cloud governance analysis arguing that RBAC must preserve hierarchy, because flattening role-and-scope bindings produces imprecise access, unreviewable entitlement volumes, and weak least-privilege control.
Why it matters: IAM, IGA, and PAM teams need this because cloud infrastructure access cannot be governed like SaaS entitlements without creating review fatigue, overpermissioning, and poor scoping for both humans and agents.
By the numbers:
- Full coverage of the environment would produce roughly 50 million combinations.
👉 Read C1.ai's analysis of cloud infrastructure access governance at hierarchical scale
Context
Cloud infrastructure RBAC is not a flat entitlement list. It is a hierarchy of role plus scope, where a grant at a parent level flows to everything beneath it, so governance has to preserve that structure if it wants to remain precise.
The problem is that many IGA and CIEM tools were designed around SaaS-style rows, not cloud-native inheritance. Once hierarchy is flattened or partially synced, teams lose the ability to see, review, and grant access at the level the cloud actually uses.
This article argues that the same modelling problem now affects both human access and AI agent access. That makes hierarchy preservation a governance issue, not just a user-interface choice.
Key questions
Q: What breaks when cloud RBAC hierarchy is flattened into entitlement rows?
A: Flattening cloud RBAC breaks effective access governance because parent-child inheritance disappears from view. Reviewers cannot distinguish narrow resource-level access from broad parent-scope access, requesters over-select permissions, and the platform starts governing row counts instead of real scope. The result is overpermissioned access and weaker least-privilege enforcement.
Q: Why does hierarchical cloud access create so many governance problems at scale?
A: Hierarchical cloud access creates problems because each role can pair with many scopes, and the number of valid combinations grows multiplicatively. That makes sync expensive, reviews noisy, and policy enforcement hard to express in a flat governance model. The issue is structural, not just operational.
Q: How do security teams know whether cloud access reviews are still effective?
A: Cloud access reviews stop being effective when reviewers are approving flattened lists instead of meaningful bindings. A useful review shows the role, scope, and downstream inheritance so the reviewer can judge actual blast radius. If the list is too large for human judgment, the control has already lost precision.
Q: How should teams govern human and AI agent access across cloud hierarchies?
A: Treat human and AI agent access with the same hierarchical model, but scope the agent more tightly whenever the task allows it. The governance goal is to bind each identity to the minimum effective scope, preserve inheritance, and make JIT grants expire automatically. That keeps the blast radius aligned to the actual work.
Technical breakdown
Why cloud RBAC explodes when role and scope are separated
Cloud RBAC is an inheritance model, not a simple list of entitlements. A role such as Reader or Contributor only has meaning when paired with a scope such as management group, subscription, resource group, or resource. When tools pre-materialize every possible pairing, the data model expands into millions of combinations and obscures the parent-child relationships that define actual access semantics. That is why a flat catalogue cannot faithfully represent cloud access.
Practical implication: govern cloud RBAC as bindings with inherited scope, not as precomputed entitlement rows.
Why flattening hierarchy breaks reviews and least privilege
Flattening hierarchy turns distinct grants into visually similar rows, so reviewers cannot easily distinguish a narrow resource-group binding from a broad subscription-level grant. The result is not only review fatigue but also systematic overapproval, because humans default to bulk decisions when the list becomes unmanageable. At the same time, least privilege becomes approximate rather than exact, especially when the governance tool cannot express the parent-child path that scopes effective access.
Practical implication: preserve scope context in access reviews so reviewers can judge effective access, not just row counts.
Why AI agents make cloud entitlement precision non-negotiable
AI agents change the stakes because their access needs are often narrower and more transient than a human operator's. An agent that only needs read access to one storage account should not inherit broad subscription-level permissions simply because the governance layer cannot model the hierarchy. In that environment, the blast radius of a compromised agent identity is determined by the precision of the entitlement model, not by the number of security policies around it.
Practical implication: scope agent access to the exact resource boundary the task requires, and do not let modelling limits drive broader grants.
Breaches seen in the wild
- Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud governance fails when the entitlement model erases hierarchy. The core problem is not simply scale, but structural mismatch: cloud infrastructure assigns access through role plus scope, while many governance tools collapse that relationship into flat rows. Once the hierarchy is lost, precision disappears with it, and teams start governing the representation instead of the access path. The practitioner conclusion is that cloud access governance must preserve native inheritance or it will misstate who can reach what.
Review fatigue is a governance failure mode, not a user problem. A quarterly review that turns into tens of thousands of flattened line items is structurally unreviewable, so bulk approval becomes rational even when no reviewer wants it. That means the system has already failed before any human clicks approve. The practitioner conclusion is that review design must reduce the unit of governance back to the binding that actually matters.
Cloud infrastructure access governance now has to account for AI agent precision. The article correctly frames agent access as part of the same hierarchy problem, because agents inherit the same blast-radius risks when tools cannot express narrow scope. This is where NHI governance and cloud access governance converge: broad grants created to compensate for modelling limits increase both human and agent exposure. The practitioner conclusion is that entitlement precision is now a shared control objective across humans and agents.
Hierarchy-preserving access models are becoming the baseline for modern identity governance. Cloud, SaaS, and agentic access are not governed by the same physical data shape, even when they feed the same platform. The organisations that continue to flatten cloud access will keep paying in overpermissioning, review noise, and sync failure. The practitioner conclusion is to treat hierarchical binding as the governance primitive, not an implementation detail.
Named concept: identity blast radius. This article shows that the real risk is not entitlement count alone, but the way modelling choices expand effective access across parent-child cloud scopes. A flat entitlement layer inflates the blast radius of both humans and agents because it hides how a parent-level grant propagates downward. The practitioner conclusion is to measure blast radius at the scope boundary, not at the row count.
What this signals
Identity blast radius: Cloud access governance should be measured by how far a grant can propagate through the hierarchy, not by how many entitlements a platform can store. When a tool flattens scope, it widens the practical blast radius for both humans and agents, even if the policy language looks strict.
Organizations that keep syncing cloud permissions as rows are likely to keep seeing review fatigue, overpermissioning, and failed precision at the same time. The more useful model is to store inheritance once and compute access when it is requested, reviewed, or revoked.
For practitioners
- Preserve role-and-scope bindings Model cloud access as a principal bound to a role at a scope, with inheritance intact, instead of precomputing every combination into a flat entitlement table.
- Reduce review units to effective bindings Present reviewers with the binding, its scope, and its downstream effect so they can approve or deny actual access paths rather than thousands of flattened rows.
- Scope AI agent access to the smallest cloud boundary Assign agent permissions at the exact resource group or resource level the task requires, and avoid subscription-level grants created only because the tool cannot model hierarchy.
- Keep sync logic aligned to native cloud inheritance Ingest the hierarchy first, then compute effective access on demand so sync limitations do not force blind spots or carved-out scopes.
- Align JIT workflows to scope and expiry Use the same hierarchical binding model for just-in-time access so time-bound grants remain narrow, auditable, and revocable across the cloud tree.
Key takeaways
- Cloud access governance breaks when teams model hierarchy as flat entitlement data instead of scoped bindings.
- The scale problem is not incidental. In the article's example, a tenant can move from more than 1 million synced entitlements to about 50 million combinations, which makes precision hard to sustain.
- For practitioners, the control question is whether governance preserves effective access at the scope boundary for both humans and agents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad grants created by flattened hierarchy are the central risk in this cloud access model. |
| NHI-08 — Environment Isolation | Resource-group and subscription boundaries are the isolation lines the article says tools must preserve. | |
| Recommendation — Map cloud access sprawl to NHI-05 and tighten scope boundaries before permissions are granted. Preserve environment isolation by keeping scope context intact in request, review, and JIT flows. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article is fundamentally about preserving least privilege across hierarchical cloud scopes. |
| Recommendation — Apply AC-6 to ensure effective access is scoped to the minimum required cloud resource boundary. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on how permissions and entitlements should be modeled and reviewed in cloud. |
| Recommendation — Use PR.AA-05 to govern entitlements as scoped authorizations rather than flat rows. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | Overbroad cloud grants expand the attacker path from one scope into many downstream resources. |
| Recommendation — Map broad cloud grants to TA0004 and TA0008 to prioritize containment of expanded scope. | ||
Key terms
- Hierarchical RBAC: Hierarchical RBAC is a role model where higher roles inherit the permissions of lower roles. It organizes access into parent and child role relationships so administrators can assign broad authority once and reuse it across related positions. This reduces duplication, but requires careful design to avoid unintended privilege expansion.
- Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
What's in the full article
C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:
- How the hierarchy-aware access model is represented across management groups, subscriptions, resource groups, and resources
- How request, review, and JIT workflows work when entitlement combinations are computed on demand
- How lifecycle changes apply when a human or agent is moved, redeployed, or decommissioned
- How the same model affects cloud IaaS governance and agent access precision
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org