TL;DR: AI agent identities are creating new access risks across SaaS environments, with Reco AI arguing that existing identity and access controls do not yet model agent behaviour, delegation, and entitlement scope well enough to govern them at enterprise scale. The governance gap is now in the identity assumptions, not just the tool stack.
NHIMG editorial — based on content published by Reco AI: Non-Human Identities for AI Agents: How to Govern Access at Enterprise Scale
Questions worth separating out
Q: How should security teams govern AI agent identities in SaaS environments?
A: Treat each agent as a distinct non-human identity with its own lifecycle, access scope, and revocation path.
Q: Why do AI agents complicate privilege management for IAM teams?
A: AI agents can authenticate, call tools, and act with delegated authority, which means they behave like non-human identities with real execution power.
Q: What do teams get wrong about AI agent access reviews?
A: Teams often assume an access review can certify an agent the same way they certify a human or a service account.
Practitioner guidance
- Inventory every agent identity separately Create a dedicated register for AI agent identities, including the service accounts, tokens, and API keys they use, plus the SaaS applications they can reach.
- Map delegated access to exact actions Document which agent can read, write, trigger, approve, or export in each connected system.
What's in the full article
Reco AI's full post covers the operational detail this analysis intentionally leaves for the source:
- A walkthrough of how non-human identities for AI agents are mapped across enterprise SaaS environments.
- Practical guidance on choosing the right identity type for agent access and delegation.
- Security control patterns for reducing access risk when agents interact with applications and data.
- Implementation detail that helps teams move from concept to operating model.
👉 Read Reco AI's analysis of non-human identities for AI agents →
AI agent identities: what does enterprise access governance miss?
Explore further
AI agent identities are now a first-class governance problem, not a feature of automation. Once an agent can call tools, traverse SaaS applications, and act on delegated authority, the identity itself becomes the security boundary. That changes how IAM teams should think about provisioning, review, and revocation because the meaningful unit of control is the agent identity, not the workflow it sits inside. The implication is that identity governance must expand from users and service accounts to agent-specific execution identities.
A few things that frame the scale:
- NHIs now outnumber human identities by 144:1 in enterprise environments, a 44% increase year-over-year driven by AI agents, CI/CD automation, and third-party integrations, according to The NHI and Secrets Risk Report.
- Over 5.5% of AWS NHIs hold full admin privileges, creating high-risk super-NHIs that dramatically elevate breach impact, according to The NHI and Secrets Risk Report.
A question worth separating out:
Q: What is the difference between agentic AI governance and traditional automation governance?
A: Traditional automation governance assumes a fixed script with predictable inputs and outputs. Agentic AI governance must control a system that can plan, adapt, and choose different execution paths. That means identity scoping, approval rules, and audit trails matter more, because the same agent may behave differently across similar tasks.
👉 Read our full editorial: Non-human identities for AI agents expose enterprise access gaps