What should organisations do when RBAC does not fit dynamic cloud access?

Why This Matters for Security Teams

RBAC still has a place, but it was built for relatively stable job functions, not for cloud access that changes by workload state, request context, data sensitivity, or automation path. In practice, the problem is not that roles are wrong; it is that roles are incomplete. When security teams force dynamic access decisions into static roles, they either over-permit or create role sprawl that nobody can govern cleanly. NHI Management Group’s reporting shows the pressure behind this shift, including the broader challenge of managing non-human access across modern environments in the Ultimate Guide to NHIs.

The risk grows fast in SaaS, cloud control planes, CI/CD, and agentic workflows because the same identity may need different privileges minute to minute. Current guidance suggests keeping RBAC as a baseline and adding contextual policy for runtime decisions, rather than treating roles as the full authorisation model. That distinction matters because cloud incidents often begin with access that was technically legitimate but far broader than the task required. In practice, many security teams discover the role design gap only after a workload has already chained permissions into something the original approver never intended.

How It Works in Practice

The most workable pattern is layered authorisation. RBAC defines the coarse job function, while policy evaluates the live request: who or what is calling, from where, to which resource, with what sensitivity, and under what runtime conditions. That policy can be expressed as policy-as-code and enforced through an authorisation service, gateway, or cloud-native control. For cloud workloads and non-human identities, the identity primitive should be the workload itself, backed by cryptographic proof such as OIDC-based workload tokens or SPIFFE/SPIRE-style identity rather than a long-lived shared secret.

This is also where JIT access becomes useful. Instead of issuing standing privilege, the system grants short-lived access for a specific task, then revokes it automatically when the task ends. That reduces the blast radius of compromised credentials and better fits systems that act autonomously or burst across multiple services. NHI Management Group’s 2024 Non-Human Identity Security Report found that 59.8% of organisations see value in simplifying non-human access management with dynamic ephemeral credentials, which aligns with current industry direction.

• Use RBAC for stable baseline entitlements, not for every exception.
• Evaluate access at request time with policy that can see workload, environment, and data context.
• Prefer short-lived credentials and token exchange over static secrets for high-change cloud paths.
• Bind the identity to the workload, not to a human owner’s group membership alone.
• Log both the role decision and the policy decision so reviewers can reconstruct why access was granted.

OWASP’s OWASP Non-Human Identity Top 10 is useful here because it frames NHI failures as identity, secret, and privilege problems rather than simple permission hygiene. These controls tend to break down in large multi-cloud estates where teams cannot consistently classify workloads or keep policy inputs accurate enough for real-time enforcement.

Common Variations and Edge Cases

Tighter runtime policy usually improves security, but it also increases design and operations overhead, so organisations need to balance precision against manageability. That tradeoff is real: the more context a policy uses, the more careful teams must be about data quality, policy testing, and exception handling. Best practice is evolving, and there is no universal standard for how much context is “enough” for every cloud platform.

Some environments can keep RBAC dominant because access is simple and rarely changes. Others, especially multi-cloud, CI/CD, and agent-heavy platforms, need context-aware controls much sooner. The boundary is often whether a role can express the risk without becoming too broad. If the answer is no, then policy should take over the dynamic part of the decision. That is especially important when standing permissions persist across systems, because static credentials and broad roles combine into the exact exposure pattern seen in recent breach analyses such as the 52 NHI Breaches Analysis.

For organisations adopting autonomous agents, the need becomes sharper. Agentic systems do not behave like fixed service accounts, and their access paths can shift based on goals, tool chaining, and prompts. In those cases, static role design alone is usually too blunt. The practical answer is not to remove RBAC, but to constrain it with short-lived, context-aware authorisation that can adapt when the workload changes faster than the role model can.

Related resources from NHI Mgmt Group

• How should organisations govern access when PAM does not fit cloud-native workloads?
• How should organisations build DNS disaster recovery into identity and access planning?
• What do organisations get wrong about multi-cloud performance monitoring?
• How should organisations decide between VPNs and application-level access controls?