What is AI agent identity?
AI agent identity is the credential framework used to identify and authorize autonomous AI agents — LLM-based assistants, automated SREs, code agents — when they execute privileged actions on production systems.
The category is new. As of 2025–2026, the OWASP Foundation has published its Top 10 for LLM Applications (which treats agent autonomy and excessive agency as distinct risks), and the Cloud Security Alliance has written about non-human identity governance. Vendors in the broader identity space have begun marketing “agent identity” or “AI identity” products. The shape of the category is settling, but the standards work is still in flight.
This page is opinionated. It argues that AI agent identity is a distinct sub-category of non-human identity, not a relabeling — and that the design center is short-lived, per-action capability tokens evaluated against runtime policy, with a reasoning-chain audit trail.
Why this is a new category, not a relabeling of NHI
Service accounts and machine identities have been around for decades. The case for a separate “AI agent identity” category rests on three properties of modern agents that don’t hold for traditional workloads:
- Plans are generated at runtime. A billing service does billing. An agent decides, at inference time, that step 4 of the plan requires SSHing into a production host and running a shell command. Static IAM policies can’t express “the set of actions this LLM might propose” — that set is effectively infinite.
- The actor is delegated authority, not granted it directly. A human asks the agent to do something; the agent acts under the human’s authority. This is closer to a power-of-attorney model than to a normal service account. The audit log needs to record the delegating principal as well as the acting principal.
- The behavior space is adversarial. A misconfigured CI runner does the same wrong thing in a predictable way. A misaligned or prompt-injected agent does novel wrong things. Security controls have to assume the agent itself is potentially compromised by untrusted input.
Open questions
The field is unsettled. The following questions are under active debate in 2026 and don’t yet have consensus answers:
- Identity issuance. Who attests that a given agent process is the agent it claims to be? SPIFFE-style workload attestation works if the agent runs on a controlled host, but breaks down for hosted agents (Claude Code, Cursor) where the runtime is the vendor’s. Federation is plausible — the vendor issues an OIDC token, your control plane verifies it and exchanges for local capability tokens — but no standard exists.
- Revocation granularity. Should revocation be per-agent-instance, per-conversation, or per-task? Each has different operational cost. The consensus seems to be drifting toward per-task tokens that expire automatically, with per-instance kill switches as a backstop.
- Reasoning-chain audit. Should the agent’s internal chain-of-thought be part of the audit log? Pro: explains why an action happened. Con: LLM reasoning is notoriously unreliable as explanation, and the chain may contain sensitive context the user didn’t expect to be logged.
- Cross-agent delegation. Agent A spawns agent B to do a subtask. Whose identity does B act under? A’s, the original human’s, or its own? Each answer has different audit and revocation implications. This is unresolved.
Where Linux Identity fits
Our primitives map naturally to agent identity. Per-host enrollment gives every host a verifiable identity. Short-lived SSH certificates give the agent an identity-bound credential with a tight TTL. Capability tokens for sudo let us mint per-action authorizations, evaluated against runtime policy. And the append-only audit log gives a tamper-evident record of every privileged action, regardless of which principal — human or agent — initiated it.
We aren’t claiming to have solved the open questions. We’re claiming that the existing infrastructure for governing SSH and sudo access on Linux fleets is the natural substrate to build agent governance on, because the unit of action is already short-lived, identity-bound, and audited.
A note on terminology
We use “AI agent identity” rather than “agentic identity,” “agent IAM,” or “AI identity” because the first foregrounds what’s actually new: the actor is an AI agent (a particular kind of non-deterministic process), and the problem is identity (not access control, not policy, though those follow). The other terms are in circulation; we’d rather the field converge on language that describes the actor precisely.
More questions
- How is AI agent identity different from a regular service account?
- A service account assumes the workload is deterministic — it does a fixed set of things, with a fixed scope, in a predictable order. An AI agent is non-deterministic: an LLM produces a plan at runtime and calls tools in whatever sequence the plan requires. Static least-privilege doesn’t fit, because the union of all plausible actions is much larger than the union of expected actions. AI agent identity adds three things on top of a service account: a per-action capability check, a runtime policy engine evaluating the proposed action against the agent’s authorized scope, and an audit trail that captures not just what the agent did but why it claims to have done it.
- What kinds of AI agents need this?
- Three patterns are showing up in production. (1) Code agents — Claude Code, Cursor’s background agent, OpenAI’s codex-CLI — that read and modify source, run tests, and increasingly run deploy commands. (2) Autonomous SRE agents — systems that read alerts, propose remediations, and execute fixes on production hosts. (3) Workflow agents embedded in business tools that perform CRUD operations on customer data. The privileged-access surface is the third category in production today and growing fastest in the first two.
- How do you revoke a runaway AI agent?
- The same way you revoke any short-lived credential: stop renewing it, and (if needed) push a revocation list so currently-active credentials are rejected immediately. The design implication is that AI agents must use ephemeral, narrowly-scoped credentials with TTLs in single-digit minutes, refreshed per action or per planning loop. A long-lived API key in an agent’s config defeats revocation. Bonus: if the agent’s runtime is a separate process from the credential broker, the broker can also enforce a kill-switch that refuses to mint new credentials for a flagged agent identity, without trusting the agent process to honor a shutdown signal.
- How do you audit an AI agent that synthesizes its own plan?
- A traditional audit log answers “who did what, when.” For an AI agent, the interesting questions are “who did what, why, and on whose authority” — where “why” is the chain of reasoning the agent used to choose the action, and “authority” is the human delegation that authorized the agent to act in the first place. The emerging pattern is to log three layers per action: (1) the user prompt or trigger that started the work, (2) the agent’s intermediate plan or tool-call sequence, (3) the final privileged action executed. Layer 3 looks like a normal access log; layers 1 and 2 are new and not yet standardized.
- Does least privilege still apply to agents?
- Yes, but the unit of granting changes. For a deterministic service, least privilege means scoping the IAM role to exactly the actions the code calls. For an agent, the code path is generated at runtime, so static scoping is either too tight (the agent blocks on legitimate work) or too loose (the agent has broad rights it might misuse). The practical version is capability-token least privilege: the agent’s identity authorizes it to request specific capabilities, each capability requires a fresh token bounded to a single action, and a policy engine evaluates each request against context (user delegation, time, host, action type). The agent never holds standing rights, only the right to ask.