How should security teams decide whether an AI agent gets human or non-human identity?

Why This Matters for Security Teams

The identity choice is not a labeling exercise. It determines whether an AI agent gets delegated human access, machine permissions, or a hybrid that is tightly scoped and time-bound. When teams treat autonomous software like a person, they inherit the weakness of static RBAC for a workload that changes context mid-task. When they treat a person-driven workflow like a machine, they can break legitimate business processes. Current guidance suggests starting with operating pattern, then mapping to privilege, auditability, and revocation speed. That is consistent with the governance emphasis in the Ultimate Guide to NHIs and the risk framing in the NIST AI Risk Management Framework. For agentic systems, the right question is not “What is the agent?” but “What authority does it need at runtime, for how long, and under whose accountability?” In practice, many security teams encounter overprivilege only after an agent has already chained tools or crossed a data boundary.

How It Works in Practice

For autonomous agents, the identity model should follow execution behavior. If an agent is acting independently across systems, it should generally use a non-human identity backed by workload identity, short-lived secrets, and explicit policy evaluation at request time. That means the agent proves what it is with cryptographic workload identity, then receives just enough authority to complete a bounded task. This is the direction reflected in the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

A practical pattern looks like this:

• Use human identity when the agent is clearly delegated by a named person in a bounded workflow, such as drafting or retrieving approved records.
• Use non-human identity when the agent executes autonomously, calls tools, or moves across systems without real-time human supervision.
• Issue JIT credentials per task, with TTLs measured in minutes or hours, not days or weeks.
• Prefer ephemeral secrets and rotate them automatically when the task ends or the policy changes.
• Apply intent-based authorisation so the policy engine evaluates what the agent is trying to do, not only which role it was assigned months ago.
• Log every identity transition, tool invocation, and privilege grant so security can reconstruct agent behavior later.

This matters because agent behavior is dynamic and often non-linear. NHI research shows that 97% of NHIs carry excessive privileges, which makes identity sprawl and access creep a real operational risk, not a theoretical one. Pair that with the fact that agents already exceed intended scope in many deployments, as described in AI agents: the new attack surface. These controls tend to break down in multi-step orchestration pipelines where agents can chain tools faster than manual approval can keep up.

Common Variations and Edge Cases

Tighter identity controls often increase friction, so organisations have to balance safety against speed and operator overhead. That is especially true in hybrid scenarios where an agent starts with delegated human context and then escalates into autonomous actions. There is no universal standard for this yet, so best practice is evolving rather than settled.

Edge cases include customer-facing assistants, SOC copilots, and code agents. A copilot that only prepares an action for human approval may stay under delegated human identity, but the moment it can execute changes, fetch secrets, or open tickets automatically, it needs machine-grade containment. Likewise, if an agent needs access to production data for a narrow task, JIT access with explicit expiry is safer than permanent membership in a broad role. The same logic appears in NHIMG’s research on the OWASP NHI Top 10 and in external guidance from the NIST AI Risk Management Framework.

Another common exception is a shared agent used by a team. That should not be mapped to a shared human identity. It should be treated as a workload identity with per-user attribution layered on top, so accountability survives audit and offboarding. The hard rule is simple: if the system can act without a person actively steering each step, it should be governed as a non-human identity, even if it serves a human workflow.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• What is the difference between human identity governance and AI agent governance?
• Why do AI agents increase non-human identity risk in existing IAM programmes?