Topic starter
13/10/2026 1:21 pm
TL;DR: P0 Security says cloud identity now spans developers, workloads, service accounts, APIs, Kubernetes clusters and AI agents, and that managing access across constantly changing infrastructure has become a core cloud security problem. The practical shift is from account-centric controls to continuous governance for non-human identities and least privilege.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “Cloud access is a mess. Here’s a map”.
Key questions
Q: What breaks when cloud identity governance still assumes mostly human accounts?
A: Cloud governance loses sight of the identities that actually run the environment.
Q: Why do service accounts and workloads make least privilege harder in cloud environments?
A: Because their access is tied to automation, deployment and runtime dependencies rather than a person logging in.
Q: How do security teams know if cloud identity controls are failing?
A: The clearest sign is when a stolen credential can be validated, reused, and operationalised from infrastructure that has no relationship to the original workload.
Practitioner guidance
- Map every cloud identity type Build an inventory that separates developers, workloads, service accounts, APIs, Kubernetes clusters and AI agents, then assign an owner to each identity class and its entitlements.
- Reduce standing privilege Replace persistent elevated access with task-scoped approvals or time-bounded access where the workflow can tolerate it, especially for cloud administration and automation paths.
- Track identity-to-workload relationships Document which identities can reach which environments, APIs and clusters so privilege reviews show actual blast radius rather than abstract role names.
Bottom line: Cloud identity has outgrown the employee-account model and now includes workloads, service accounts, APIs, Kubernetes clusters and AI agents.
What's in the full article
P0 Security's full whitepaper covers the operational detail this post intentionally leaves for the source:
- A fuller map of cloud identity categories and where each one typically appears in modern infrastructure.
- Practical guidance on governing non-human identities without interrupting engineering workflows.
- Discussion of identity-native authorization and continuous policy evaluation in cloud programmes.
- Coverage of emerging AI-driven infrastructure and why it changes access governance assumptions.
👉 Read P0 Security's whitepaper on cloud identity governance for workloads and AI agents →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/10/2026 1:22 pm
Cloud identity governance fails when teams still think in account-centric terms. The article's central point is that identity now spans workloads, service accounts, APIs, Kubernetes clusters and AI agents, each with different authorisation behaviour. That changes governance from simple user administration into a broader control plane for machine and human access alike. Practitioners should treat cloud identity as an estate that must be discovered, owned and continuously governed.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations treat AI agents like human users in IAM?
A: No. Human IAM assumes a person logs in, works within a session, and can be reviewed later as a stable identity holder. Agents can act at machine speed, across multiple systems, and with changing runtime context, so they need identity governance built around execution and delegation rather than human authentication patterns.
👉 Read our full editorial: Cloud identity governance needs a map for workloads and AI agents