Start by separating the control assumptions for each actor type. Humans need authentication and access review, NHIs need lifecycle control and secret governance, and AI agents need runtime scope enforcement because their tool use can change during execution. One programme can cover all three, but the policy model cannot treat them as interchangeable identities.
Why This Matters for Security Teams
One IAM programme can span humans, NHIs, and AI agents, but only if it stops assuming they are the same control problem. Humans can be governed with authentication, access review, and joiner-mover-leaver processes. NHIs need lifecycle management, secret rotation, and offboarding. AI agents add a different risk: they are goal-driven, can chain tools, and may change what they need at runtime. That makes static access models incomplete.
This is why the control baseline has to separate identity proof, authorisation, and execution scope. A human user can be reviewed against role and entitlements, while an NHI needs secret hygiene and ownership, and an agent needs short-lived, context-aware permissions. NIST’s NIST Cybersecurity Framework 2.0 is useful at the governance layer, but it does not remove the need to tailor controls by actor type. NHIMG research shows the gap clearly: in the Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into service accounts.
In practice, many security teams discover the mismatch only after an overprivileged service account or autonomous agent has already been used to move laterally.
How It Works in Practice
A workable programme starts with a shared inventory and then splits governance by actor class. For humans, the programme should retain familiar identity controls: strong authentication, access certification, segregation of duties, and PAM where elevated access is required. For NHIs, the focus shifts to ownership, secret storage, rotation, and revocation. For agents, the control plane must evaluate what the agent is trying to do at request time, not just what it was allowed to do last month.
That means the policy model should be runtime-aware. Current guidance suggests combining workload identity, short-lived credentials, and policy-as-code so that each task receives only the scope needed for that task. In agentic environments, cryptographic workload identity such as SPIFFE or OIDC-backed service identity is more reliable than static secrets because it proves what the workload is, not merely what token it holds. This also aligns with the emerging guidance in the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework.
- Humans: authenticate, approve, review, and re-certify.
- NHIs: assign an owner, store secrets centrally, rotate aggressively, and revoke on offboarding.
- Agents: issue JIT, task-scoped credentials and evaluate policy at each tool call.
- All three: log who or what acted, what scope was granted, and when it expired.
NHIMG’s Top 10 NHI Issues highlights why this matters: 71% of NHIs are not rotated within recommended time frames, which is incompatible with dynamic access governance.
These controls tend to break down in legacy environments where applications hard-code long-lived secrets, cannot issue per-task tokens, or cannot call a policy engine at runtime.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance faster automation against more complex approval and observability requirements. That tradeoff is most visible with AI agents, where overly rigid policy can break useful workflows, but loose policy can allow tool chaining, privilege escalation, or unintended data movement.
There is no universal standard for this yet. Best practice is evolving toward intent-based authorisation for agents, but many environments still rely on coarse RBAC and static scopes. That can be acceptable for low-risk internal automation, but it becomes fragile when agents interact with production systems, third-party APIs, or sensitive data stores. The safest approach is to separate human approval from machine execution: humans set policy, NHIs carry the service workload, and agents receive only the minimum task scope needed in real time.
Two common edge cases deserve special treatment. First, shared platform identities used by multiple workloads should be refactored into individually attributable workload identities wherever possible. Second, hybrid and multi-cloud estates often force exceptions because identity propagation, vaulting, and token exchange differ across platforms. In those cases, teams should standardise on the control objective rather than the vendor mechanism. NIST’s NIST AI Risk Management Framework is helpful for accountability and governance, while the Ultimate Guide to NHIs provides the operational context for secret rotation and lifecycle discipline.
Where a platform cannot support ephemeral credentials or runtime policy checks, teams should treat that gap as a compensating-control problem rather than assuming static IAM is sufficient.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 Agentic AI Top 10 | A2 | Agentic systems need runtime scope and tool-use controls, not static access alone. |
| CSA MAESTRO | GOV-2 | MAESTRO addresses governance and threat modeling across agentic workflows. |
| NIST AI RMF | GOVERN | AI RMF governs accountability and risk management across human and AI actors. |
Assign accountability, document risk decisions, and review agent behavior continuously.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams unify IAM for humans, workloads, and AI agents?
- How should security teams govern AI agents and NHIs differently?
- How should security teams govern AI agents that can invoke multiple tools in one session?
