Use one identity governance model with different control treatments by actor type. Human access still needs joiner-mover-leaver discipline and certification. NHIs need ownership, rotation, and revocation. AI agents need runtime scope control, explicit action boundaries, and visibility into the identities they use to reach tools and data.
Why This Matters for Security Teams
One programme is essential because human users, NHIs, and AI agents all create access risk, but they fail in different ways. Human identity governance can rely on joiner-mover-leaver controls and periodic review. NHIs often fail through weak ownership, overlong secrets, and poor revocation. AI agents add a harder problem: they act dynamically, chain tools, and may seek capabilities at runtime that were never obvious at onboarding.
The practical mistake is to force all three into one static IAM pattern. That works until an agent calls a new tool, a service account is reused across pipelines, or a dormant secret is found in a workflow. NHIMG’s Ultimate Guide to NHIs and the OWASP Agentic AI Top 10 both point to the same operational reality: access must be governed by actor type, not by a single shared process. In the NHI space, NHIMG reporting shows 72% of organisations have experienced or suspect a breach of non-human identities, which is why the control gap matters so much in mixed environments.
In practice, many security teams encounter access abuse only after an over-permissioned service identity or agent credential has already been used to reach a sensitive system, rather than through intentional lifecycle governance.
How It Works in Practice
The cleanest model is a shared governance backbone with separate control treatments for each actor type. Human identities stay in the classic governance lane: HR-backed joiner-mover-leaver workflows, access certifications, segregation of duties, and privileged access management where appropriate. NHIs need ownership, inventory, rotation, scoped permissions, and revocation tied to the workload lifecycle. AI agents need an additional runtime layer because their behaviour is goal-driven, not pre-scripted.
That runtime layer should answer three questions at request time: what is the agent trying to do, what context is it operating in, and what identities or credentials is it using to do it? Current guidance suggests using workload identity as the base primitive for agents, such as OIDC-backed tokens or SPIFFE-style workload proof, then issuing short-lived secrets only when a task is approved. Policy decisions should be evaluated at runtime with policy-as-code and context-aware controls, as reflected in the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework.
- Humans: certify access, enforce MFA, and review privileged roles on a fixed cadence.
- NHIs: assign an owner, rotate secrets, set TTLs, and revoke on workload retirement.
- AI agents: constrain tool scope, require task-level approval for sensitive actions, and log every identity the agent uses.
NHIMG’s Top 10 NHI Issues is useful here because it reinforces that ownership and rotation failures are still the most common operational weaknesses, even before agentic behaviour is added. These controls tend to break down when agents share reusable secrets across environments, because the agent can rapidly pivot from one tool to another without the static assumptions built into legacy IAM.
Common Variations and Edge Cases
Tighter runtime control often increases latency, policy overhead, and integration effort, so organisations must balance stronger containment against developer and operations friction. Best practice is evolving, and there is no universal standard for how much autonomy an AI agent should have before human approval becomes mandatory.
One common variation is a high-trust internal workflow where a single agent can read from one data source and write to one downstream system. Even there, the access should be ephemeral and narrowly scoped. Another edge case is shared platform automation, where many workloads reuse the same NHI pattern. That is where governance often gets messy, because an “automation identity” can hide too many different purposes and owners.
For agentic systems, policy should not depend on a pre-defined role alone. If the agent can choose between multiple tools, evaluate actions against real-time context and step up controls when risk increases. That is especially important in environments with sensitive data, vendor-connected OAuth apps, or cross-domain pipelines, where identity sprawl makes static review ineffective. NHIMG’s Ultimate Guide to NHIs and external guidance such as NIST Cybersecurity Framework 2.0 both support the same principle: govern by lifecycle, ownership, and verified context, not by identity label alone.
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 limits and action boundaries. |
| CSA MAESTRO | T1 | MAESTRO addresses threat modeling for autonomous agents and tool use. |
| NIST AI RMF | GOVERN | AI RMF governance covers accountability for mixed human, NHI, and agent access. |
Assign ownership, policy, and review cadence for every actor type in one governance model.
Related resources from NHI Mgmt Group
- How should organisations govern agentic AI and NHI access in the same programme?
- How should security teams govern human, NHI, and agentic access in one programme?
- How should security teams govern non-human identities that have persistent access?
- When do NHI access reviews create more value than a one-time cleanup?
