How should security teams build identity governance across humans, machines, and AI agents?

Why This Matters for Security Teams

Identity governance fails when humans, workloads, and AI agents are managed in separate silos, because each group creates different access patterns, review cycles, and offboarding risks. The practical problem is not just “more identities”; it is that the same service can expose both a person and a machine credential, while an agent may also chain tools and request new access at runtime. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which is why human-centric IAM processes do not scale cleanly.

For security teams, the governance question is whether the organisation can answer three basics at once: who or what owns the identity, what it can touch, and how quickly it can be revoked when trust changes. That requires one inventory, but also one decision model for entitlement review, PAM, and monitoring. Current guidance from the NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework points toward shared accountability and continuous risk evaluation rather than static ownership lists. In practice, many security teams discover identity sprawl only after a secrets leak, a failed offboarding, or an agent is allowed to act beyond its original intent.

How It Works in Practice

A workable model starts with a unified identity register that treats humans, service accounts, tokens, API keys, certificates, and AI agents as governed entities, not separate programs. Each record should carry identity type, business owner, technical owner, purpose, system relationships, authentication method, privilege scope, rotation policy, and revocation path. That makes it possible to review the same asset through IAM, PAM, and detection without translating between tools.

For human identities, access reviews still matter, but they should be tied to actual system relationships rather than broad role labels. For machine identities, the control focus shifts to secrets hygiene, short-lived credentials, and offboarding automation. NHI Management Group’s Lifecycle Processes for Managing NHIs is useful here because it frames NHI governance as a lifecycle problem, not a one-time onboarding task. For AI agents, current guidance suggests using workload identity and runtime policy evaluation, because an agent’s permissions should reflect what it is trying to do at that moment, not a static job description. That aligns with the direction described in the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework.

• Use one source of truth for identity ownership and entitlement scope.
• Require short-lived credentials where possible, especially for service accounts and agents.
• Evaluate privilege at request time for sensitive actions, not just during annual review.
• Feed the same inventory into PAM, SIEM, and SOAR so revocation is consistent.

This guidance breaks down when legacy systems cannot distinguish workload identity from user identity, because the same shared secret often serves multiple apps and owners.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance stronger control with the cost of change management, integration work, and support for legacy applications. That tradeoff is especially visible in mixed estates where humans still use long-lived accounts, machines use embedded secrets, and agents need runtime permissions that can change mid-task.

There is no universal standard for agent identity governance yet, but best practice is evolving toward context-aware authorisation, ephemeral credentials, and real-time policy decisions. For AI agents, static RBAC can be too blunt because the agent may need to call different tools depending on the task, while excessive standing privilege makes lateral movement easier if the agent is misdirected. For that reason, many teams are pairing policy-as-code with workload identity approaches such as SPIFFE-style cryptographic identity, then using local policy engines to decide whether a request is allowed in context. The 52 NHI Breaches Analysis and the Anthropic report on AI-orchestrated cyber espionage both reinforce the same operational point: when identity is shared, stale, or over-privileged, compromise spreads faster than teams expect.

Special cases include third-party OAuth apps, CI/CD runners, and agentic workflows that inherit credentials from upstream systems. These environments need stronger owner attribution and faster secret rotation than standard user accounts. The right governance model is not one policy for all identities, but one control plane that adapts by identity type while preserving a common audit trail.

Related resources from NHI Mgmt Group

• How should security teams govern identity observability across humans, workloads, and AI agents?
• How should security teams govern AI transformation across identity and access programmes?
• How do security teams know whether identity governance is reducing risk?
• How should security teams modernise a failing identity governance platform?