What counts as a non-human identity
The taxonomy is broader than most inventories admit. Service accounts running scheduled jobs. API keys embedded in integrations. OAuth tokens granted to third-party apps. Workload identities binding containers and functions to cloud permissions. Certificates and signing keys. And the newest class: AI agents: coding agents in terminals, autonomous agents in the OpenClaw mold, and the sub-agents they spawn.
Agents deserve their own entry because they are NHIs with agency. A service account executes the script it was given; an agent decides what to do next, acquires new capabilities (skills, MCP servers, dependencies), and delegates to sub-agents. Every trait that makes an identity risky (credentials, permissions, reach) plus autonomous behavior. That is why agent-class NHIs need governance beyond what key-management tooling provides; the full discipline is covered in AI agent governance.
Why NHI governance is failing
Human identity governance works because humans come with lifecycle events: a hire date that triggers provisioning, a manager who approves access, a departure that triggers offboarding. NHIs have none of these. They are created in the flow of engineering work, scoped by convenience, owned by whoever created them (until that person leaves), and retired essentially never: stale credentials accumulate for years because nothing prompts their removal. Agents make each failure mode worse: they multiply faster than any other identity class, they often run under a human’s own credentials (so they don’t even appear as separate identities), and delegation means one registered agent can imply several unregistered actors. The result in most organizations is an identity population that is majority non-human, minority inventoried, and almost entirely unwatched between annual reviews.
The NHI lifecycle, and where it breaks for agents
| Stage | How it should work | Where it breaks for agents |
|---|---|---|
| Create | A key or account is provisioned for a defined purpose | Agents are created casually: a developer installs one in minutes, no ticket, no registration |
| Scope | Permissions granted to match the task | Agents inherit the full permissions of the user or environment they run in: scope is accidental |
| Monitor | Usage reviewed periodically | Agents act at machine speed between reviews; periodic checks see aggregate noise, not actions |
| Rotate | Credentials rotated on schedule | Agent-held tokens accumulate in configs and environment files that rotation tooling doesn’t track |
| Retire | Identity deprovisioned when its purpose ends | Agents have no offboarding trigger: no departure, no expiry, no owner to notice they’re still running |
Identity lifecycle management for agents therefore starts from discovery rather than provisioning: find what exists first (including the shadow AI nobody registered), then retrofit ownership, scope, and a retirement path onto it.
ITDR for non-human identities
Identity threat detection and response grew up around human and directory identities: impossible-travel logins, privilege escalation in Active Directory, credential stuffing. When the identity is an agent, the threat signals move to the action layer: an agent suddenly touching paths it never touched, installing from an unknown registry, connecting to an unsanctioned model provider, or appearing on a terminal with no registered agent at all. Detecting any of that requires execution-time telemetry, which directory logs don’t contain. This is how Nexus approaches ITDR for the agent class: runtime capture feeds a findings stream (policy violations, shadow identities, anomalous activity) attached to the identity inventory, so detection and response happen against the same graph. The telemetry backbone is described in agent observability.
Blast-radius analysis: the question that matters in an incident
When a credential leaks, the first question is not “how did this happen” but “what can the attacker reach with it?” Answering it from tribal knowledge takes days; answering it from an identity graph takes minutes. Nexus maintains that graph continuously: agents and NHIs as nodes, credentials and connections as edges, systems as endpoints. Blast-radius analysis walks the graph outward from any identity to show its total reach, which is also lateral-movement analysis under another name, since an attacker holding an agent’s token moves exactly along those edges. The same view, used proactively, prioritizes remediation: shrink the largest blast radii first. This connects directly to the zero-trust principle of assuming breach and limiting what any single compromised identity can do.
An IAM strategy that includes agents
Five practical additions bring agents inside an existing IAM program:
- Agent registration: every agent gets an identity in the inventory, discovered automatically where it wasn’t declared.
- Owner assignment: a named human accountable for each agent’s existence and scope.
- Scoped credentials: agents get their own least-privilege tokens, never a human’s reused ones.
- Execution-time policy: the agent-specific addition: out-of-policy actions blocked before they run, not discovered at review time.
- Audit trails: every action attributable to a session, terminal, and owner, retained durably.
The NHI tools market
A fair split of the market: cloud-side NHI platforms inventory and de-risk credential sprawl across SaaS and cloud estates; Nexus covers the agent class specifically, where endpoint capture and enforcement are required. Many organizations will want one of each: see also our SSPM and AI security tools guides for the adjacent categories.
| Vendor | Focus |
|---|---|
| Astrix Security (Cisco) | NHI discovery and risk across cloud and SaaS estates |
| Oasis Security | NHI lifecycle management: ownership, rotation, decommissioning |
| Entro Security | Secrets and machine-identity monitoring across vaults and repos |
| Swfte Nexus | Agent-class NHIs with endpoint capture: inventory, identity graph, blast radius, execution-time policy |
Non-human identity FAQ
What is a non-human identity?
A non-human identity (NHI) is any credentialed actor in your systems that isn’t a person: service accounts, API keys, OAuth tokens, workload identities, and (increasingly) AI agents. They authenticate, hold permissions, and take actions just like human users, but typically without an owner, a lifecycle, or an offboarding process.
Why are AI agents considered non-human identities?
Because they authenticate to systems, hold credentials, and take actions (the defining traits of an identity) while also reasoning and delegating, which static service accounts never did. That combination makes them the highest-agency, least-governed class of NHI in most environments.
What is ITDR and does it cover AI agents?
Identity threat detection and response (ITDR) detects and responds to identity-based attacks such as credential theft and privilege misuse. Classic ITDR focuses on human and directory identities; covering agents requires seeing agent actions at execution time, which is why Nexus pairs its identity inventory with per-session capture and policy findings.
What is blast-radius analysis for an identity?
Blast-radius analysis answers: if this identity were compromised right now, what could an attacker reach through it? Nexus computes this over its identity graph, connecting agents and non-human identities to the systems they can touch, so incident responders can scope exposure in minutes instead of days.
How should an IAM strategy handle AI agents?
Extend the same discipline you apply to privileged humans: every agent gets an owner, a registered identity, tightly scoped credentials, continuous monitoring, and a defined retirement path. The additional requirement unique to agents is execution-time policy: the ability to block an out-of-policy action, not just review access quarterly.
Your org chart is missing its fastest-growing population
Inventory every agent and non-human identity (and see its blast radius) in the Nexus governance console.
Explore Swfte Nexus