What breaks when identity governance is discussed without cloud and AI context?

Why This Matters for Security Teams

Identity governance breaks down quickly when it is discussed as a human-centric approval problem instead of a cloud and AI operating problem. In modern environments, access is not just assigned to employees and reviewed in quarterly cycles. It is created for workloads, inherited through cloud roles, delegated to service accounts, and extended to agents that can act on intent. That is why identity controls that look complete on paper can miss the actual paths attackers and automation use.

This gap is visible in NHI exposure data from the Ultimate Guide to NHIs, where NHIs outnumber human identities by 25x to 50x in modern enterprises. A human-only governance model cannot keep pace with that scale, especially when cloud platforms and AI systems introduce short-lived privileges, token-based access, and third-party integrations that change by the minute. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes risk-based control, but the implementation details must reflect how identities actually behave in cloud and AI stacks.

In practice, many security teams encounter excessive privilege only after an incident review shows that the real problem was never the policy, but the operating environment the policy failed to model.

How It Works in Practice

Effective identity governance in cloud and AI contexts starts with inventorying every identity type that can request or receive access: users, service accounts, workload identities, API keys, federated roles, and AI agents. The control objective is no longer just “who approved access,” but “what identity was used, by what system, for what context, and for how long.” That shift matters because cloud-native access is often ephemeral, distributed, and automated.

Practitioners are increasingly using workload identity, short-lived tokens, and policy evaluation at request time instead of static entitlements. For agents, that means access should be tied to task scope and runtime context, not a standing role that assumes predictable behaviour. Guidance from the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs supports lifecycle controls such as issuance, rotation, monitoring, and revocation. In cloud and AI environments, those lifecycle steps need to be automated because manual approvals cannot keep up with machine-speed change.

• Use just-in-time access for tasks instead of persistent standing privilege.
• Bind cloud and AI access to workload identity, not shared secrets.
• Evaluate policy at runtime using full context, including source, purpose, and environment.
• Log token issuance, privilege elevation, and revocation as first-class audit events.
• Separate governance for human approvals from governance for autonomous execution.

The NIST guidance on identity and access in the NIST Cybersecurity Framework 2.0 aligns with this approach, but there is no universal standard for AI agent authorisation yet, so current practice is still evolving. These controls tend to break down in fast-moving multi-cloud environments because identity sprawl, token exchange chains, and unmanaged machine accounts make ownership and revocation ambiguous.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against faster release cycles and automation demands. That tradeoff becomes sharper in AI systems, where agents may need temporary access to multiple tools in sequence, and in cloud environments, where ephemeral compute can disappear before a human reviewer even sees the request.

One common edge case is the “approved but unbounded” integration: a third-party SaaS app or AI tool is granted broad API access because the initial business use case seemed narrow. Another is the overreliance on static credentials, which the Top 10 NHI Issues research consistently treats as a high-risk pattern because secrets can persist long after the original purpose has changed. In these situations, human-style governance fails because the access path is machine-driven and the blast radius is system-wide.

For that reason, best practice is evolving toward continuous assurance, not one-time approval. Organisations should classify identity by behaviour and runtime context, then apply different controls to employees, workloads, and agents. Where cloud, CI/CD, and AI orchestration overlap, identity governance must follow the execution path, not the org chart.

Related resources from NHI Mgmt Group

• What breaks when organisations launch AI initiatives without a clear identity security framework?
• How should organisations enforce identity governance across multi-cloud and AI-driven workflows?
• What breaks when organisations rely on compliance status instead of continuous control verification for cloud identity governance?
• What breaks when organisations separate identity governance and authorisation in cloud-first environments?