They should use one governance model for ownership, approval, review, and revocation, but apply it differently by actor type. Human identities rely on joiner-mover-leaver processes, while NHIs need secrets, certificates, and token lifecycle controls. AI agents add runtime behaviour that must also be monitored. The goal is consistent oversight, not identical workflows for every identity type.
Why This Matters for Security Teams
Security teams usually inherit one identity programme but multiple actor types. That is where failure starts: humans can be managed through joiner-mover-leaver processes, while NHIs depend on secret rotation, certificate handling, and token revocation. AI agents complicate the same model because their access is not just owned, it is executed dynamically. A unified programme has to govern approval, review, and offboarding consistently without pretending the lifecycle is identical.
This matters because identity sprawl is already a control problem, not a paperwork problem. NHI Management Group notes that NHIs can outnumber human identities by 25x to 50x in modern enterprises, and that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 is converging on the same point: ownership and accountability must be centralised even when the technical controls differ. In practice, many security teams discover the gap only after a service account, API key, or agent token has already outlived the process meant to govern it.
How It Works in Practice
A workable model starts with one control plane and separate lifecycle playbooks. The control plane defines who approves access, who reviews it, who owns it, and who can revoke it. Then the identity type determines the enforcement method. Humans are tied to HR events, access requests, and periodic certification. NHIs are tied to workload registration, secret issuance, certificate expiry, token TTL, and automated revocation. AI agents need all of that plus runtime policy checks because their actions are goal-driven and can change from one task to the next.
For most teams, the practical sequence looks like this:
- Assign a named business owner for every human account, service account, API key, and agent identity.
- Use a single review cadence, but evaluate humans for role fit and NHIs for actual usage, last rotation, and exposure.
- Issue credentials as short-lived by default, with JIT provisioning for sensitive workloads and automatic revocation on task completion.
- Treat workload identity as the stable primitive for NHIs, using cryptographic proof of what the workload is rather than relying on static shared secrets alone.
- For agents, add real-time authorisation based on intent, context, and tool reach so policy is evaluated at request time, not only during onboarding.
This is where identity governance becomes operational security. NHIMG’s Top 10 NHI Issues highlights how rotation gaps, over-privilege, and weak visibility turn routine access into persistent exposure. That aligns with emerging implementation patterns in SPIFFE, OIDC, and policy-as-code approaches, which support short-lived assertions and continuous evaluation rather than standing trust. These controls tend to break down in legacy environments where batch jobs, hard-coded secrets, and shared service accounts cannot be cleanly mapped to a single owner or expiration event.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance assurance against delivery speed. The hardest edge case is mixed ownership: a human operator may approve an automation workflow, but the NHI or agent that executes it must still be governed as a separate identity with its own lifecycle and logging. Best practice is evolving here, but current guidance suggests one approval framework with differentiated control execution is more realistic than trying to force humans and machines through identical workflows.
Another common exception is third-party access. Vendor integrations often arrive as OAuth apps, API tokens, or delegated service identities that do not fit traditional employee review cycles. That is why the confidence gap reported in The State of Non-Human Identity Security matters: teams can believe they have a mature programme while missing who actually has active machine access. For AI agents, the risk is even sharper because one approved identity may chain multiple tools and requests in ways that were not visible at approval time. Governance should therefore include exception handling for long-lived integrations, emergency access, and agentic workflows that require runtime guardrails, not just pre-approved entitlements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle rotation and revocation are central to mixed human and NHI governance. |
| OWASP Agentic AI Top 10 | A-04 | Agent runtime behaviour needs context-aware authorisation beyond static roles. |
| CSA MAESTRO | GOV-2 | Shared governance across humans, NHIs, and agents needs one control model. |
| NIST AI RMF | AI RMF supports accountability and oversight for autonomous agent behaviour. |
Define ownership, monitoring, and escalation paths for agent decisions under a single AI risk programme.
