How should teams govern access when cloud and AI workloads change too fast for static roles?

Why This Matters for Security Teams

Static roles were designed for people with relatively stable job functions. Cloud workloads and AI agents do not behave that way. They scale up and down, chain tools, call APIs, and take actions based on live context, which means assignment-time access quickly becomes stale. Current guidance suggests treating access as a runtime decision, not a permanent entitlement. The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.

That matters because over-privileged automation fails differently from over-privileged users. A human may click the wrong thing once; an autonomous workload can repeat the same mistake at machine speed, across environments, and without a predictable path. That is why teams need to pair least privilege with context-aware checks, short-lived secrets, and clear ownership for every workload identity. The OWASP Non-Human Identity Top 10 and NHIMG research on NHI risk patterns both point to the same operational problem: standing access survives long after the task that justified it has changed.

In practice, many security teams encounter excessive access only after an agent has already chained one approved action into an unintended second action.

How It Works in Practice

The practical shift is from static entitlements to decision-time authorization. Instead of granting a workload broad role membership and trusting it indefinitely, teams issue access only when a specific task is underway, then revoke it when the task ends. For cloud and AI systems, the identity primitive should be the workload identity, not a human-shaped role. The SPIFFE workload identity specification is widely used for cryptographic proof of what a service or agent is, while policy engines such as OPA or Cedar can evaluate whether that identity should act right now, in this environment, for this request.

That model usually includes four controls:

• Issue short-lived credentials per task, not long-lived static secrets.
• Bind access to current context such as service, environment, task scope, and risk.
• Evaluate policy at request time, not only at provisioning time.
• Revoke or expire access automatically when the task completes or the context changes.

For AI agents, this is especially important because behaviour is goal-driven rather than pre-scripted. A model may decide to call a different tool, retry a failed action, or escalate through a chain of valid permissions. The Guide to SPIFFE and SPIRE is useful here because it frames identity as a runtime trust signal instead of a static account. NIST’s Cybersecurity Framework 2.0 supports the same operational direction through governance, identity, and access practices that can be continuously enforced rather than periodically reviewed. These controls tend to break down when a workload must operate offline or across loosely governed partner systems because runtime policy evaluation and rapid revocation are harder to guarantee.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance security assurance against deployment speed and developer friction. Best practice is evolving, but there is no universal standard for exactly how much context is enough for every workload. Some environments can support very fine-grained, per-request checks; others need a simpler guardrail model because latency, tooling, or legacy integration makes real-time evaluation impractical.

Hybrid environments are a common edge case. A cloud-native service may support ephemeral tokens and policy-as-code, while a legacy batch job still depends on a shared secret or a coarse RBAC group. In those cases, teams should reduce blast radius first: split credentials by function, shorten token lifetime, and require explicit approval for any privilege that cannot yet be made ephemeral. NHIMG’s Top 10 NHI Issues and the lifecycle guidance for managing NHIs both reinforce that identity lifecycle control matters as much as initial provisioning. The OWASP Non-Human Identity Top 10 also highlights that secret sprawl and stale credentials remain common failure modes even when teams believe their controls are mature.

The main exception is when access must be delegated to another system on behalf of the agent. In those cases, current guidance suggests treating delegation as a separate trust event, with explicit scope, auditability, and expiry, rather than extending the agent’s original access indefinitely.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern AI transformation across identity and access programmes?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities in cloud environments?