Non-Human Identity for Agents: Why Agents Break Human IAM and What a Machine Identity Needs

When a person signs in to a corporate system, a great deal of invisible machinery makes assumptions on their behalf: that there is one human behind the credential, that the human will re-authenticate rarely, that a session is a reasonable proxy for continuous intent, and that authority granted at login is stable for the session's lifetime. These assumptions are so deeply embedded in identity and access management that they are rarely stated. An autonomous agent — a software principal that pursues a goal over a long, unattended run, calls other services, and delegates work to sub-agents — quietly falsifies each one. The result is not a minor impedance mismatch but a systematic failure: credentials that live too long, authority that cannot be traced to the act that used it, and delegation chains that no human ever reviewed. This article makes the mismatch explicit, then derives what a machine identity for an agent must provide instead.

The Unstated Assumptions of Human IAM

Identity and access management (IAM) is the discipline of establishing who a principal is (authentication) and what that principal may do (authorization). A principal is any entity that can be authenticated and to which access decisions apply. In the human-centric practice that dominates enterprise systems, the principal is a person, and a set of assumptions about that person is baked into every layer of the stack. Naming those assumptions is the prerequisite to seeing why agents break them.

The first assumption is singularity: one credential corresponds to one human, who is present, intentional, and accountable. The second is low authentication frequency: a person authenticates at the start of a session and the session — a server-side or token-bound record that the authentication happened — stands in for their continued presence for minutes or hours. The third is credential longevity: passwords, and often the tokens derived from them, are long-lived because forcing a human to re-authenticate constantly is hostile to usability. The fourth is static authority: the permissions attached to a session are fixed at login and rarely change mid-session. The fifth is human-scale population: an organization has thousands or tens of thousands of human identities, a number that governance processes — access reviews, joiner-mover-leaver workflows — were sized for.

None of these is a mistake. Each is a reasonable engineering response to the properties of human users, and standards codify them deliberately. NIST SP 800-63-3, the Digital Identity Guidelines, frames identity assurance around a human enrolling once and authenticating with factors they possess or know; the entire apparatus of identity proofing assumes a person on the other end. The problem is not that these assumptions are wrong for humans. It is that they are silently inherited by systems that then hand the same credentials, sessions, and review cadences to software that is nothing like a human.

Where the Agent Breaks Every Assumption

Take the assumptions in order and watch each fail. Singularity breaks first: an agent is not one actor but potentially a tree of them. A planning agent invokes tool-executing sub-agents, which may in turn call further services, and each of these is a principal that acts. When something goes wrong, the question 'which principal did this?' has no single answer unless identity was designed to preserve the distinction — and inherited human IAM was not, because a human is atomic.

Low authentication frequency breaks next. A human session is a bet that presence at login predicts presence now. An agent has no login moment and no presence to predict; it authenticates to each service it calls, potentially thousands of times over a run. A session token minted for human cadence and reused across an agent's run becomes a long-lived bearer secret exposed on every hop — precisely the anti-pattern the OWASP Agentic Security Initiative flags when it warns about excessive agency and credential exposure in agentic systems.

Credential longevity breaks because its justification evaporates. Long-lived credentials exist to spare humans the friction of frequent re-authentication. An agent feels no friction. There is no usability argument for giving a piece of software a credential that lives for days; the only thing longevity buys is a larger window in which a stolen credential remains valid. Static authority breaks because an agent's task changes what it legitimately needs from minute to minute — reading a document, then calling an API, then writing a result — and a fixed session grant either over-provisions for the whole run or blocks legitimate steps. Human-scale population breaks most quantitatively of all: a fleet can create and destroy agent principals faster than any human-oriented access-review process can enumerate them, so governance sized for tens of thousands of slowly-changing identities is overwhelmed by a churning population of short-lived ones.

The pattern across all five is the same. Each human assumption traded a security property for a human-centric benefit — usability, simplicity, review tractability — and the trade was sound because the benefit was real. For an agent the benefit is zero, so the trade is pure loss. This is the core thesis: agent identity is not human identity at smaller scale; it is a different object whose invariants are the opposite of the human ones.

Defining a Machine Identity Precisely

To say what an agent needs, define the object first. A machine identity is a credential-bearing statement about a software workload that lets other parties authenticate it and make authorization decisions about it. Three sub-terms carry the weight. A workload is a running unit of software — a process, a container, a function invocation — as opposed to the person or team that deployed it. A credential is a verifiable secret or signed artifact that a principal presents to prove identity. Binding is the association between the credential and the specific workload, such that possessing the credential means being that workload and not merely holding its secret.

The distinction between holding a secret and being a workload is the crux, and it is where the SPIFFE specification (the Secure Production Identity Framework For Everyone, a CNCF workload-identity standard) makes its central move. SPIFFE gives each workload a stable name — a SPIFFE ID, structured as a URI naming a trust domain and a path — and issues a short-lived, cryptographically verifiable document, the SVID (SPIFFE Verifiable Identity Document), that binds that name to the workload. The identity is the name; the SVID is the provable, expiring assertion of it. Crucially, the SVID is obtained by the workload proving properties of itself to an issuing authority, not by a human typing a password on its behalf.

With these terms we can state the identity relation formally. Let a principal p present a credential c to a verifier v. Human IAM effectively checks whether c is valid. Machine identity must check something stronger: that c is valid, that c is bound to a specific workload w, that c has not expired, and that w is the workload authorized for the requested action. The added conjuncts — binding, freshness, and workload-scoped authorization — are exactly the properties the human assumptions discarded.

What a Machine Identity Must Provide

From the falsified assumptions, the requirements follow directly — each requirement is the negation of a broken human assumption. Because singularity fails, an agent identity must be attributable: every action must be traceable to the specific principal that performed it, including which sub-agent in a delegation tree. Because low authentication frequency fails, the identity must be continuously verifiable at low cost, so that authenticating on every hop is cheap rather than a reason to cache a long-lived secret.

Because credential longevity has no justification, the credential must be short-lived by default — measured in minutes, automatically renewed while the workload is healthy, and worthless once it expires. Because static authority fails, authority must be scopable to the task at hand, so that a credential carries only the permissions the current step needs rather than the union of everything the run might do. And because human-scale population fails, the whole scheme must be machine-issuable and machine-revocable: identities are minted and killed by automation on the timescale that agents are created and destroyed, with no human in the enrollment or teardown loop.

These five requirements — attributable, continuously verifiable, short-lived, task-scopable, machine-governed — are not a wish list; they are forced by the failure analysis. Any identity scheme for agents that omits one of them re-inherits the corresponding human assumption and its failure mode. The requirements also compose with zero-trust architecture as defined in NIST SP 800-207, which rejects implicit trust based on network location and insists that every access request be authenticated and authorized on its own merits. An agent fleet is the environment zero-trust was describing in the limit: many principals, no perimeter, every request evaluated fresh. Machine identity is what makes per-request evaluation possible for non-human principals.

Delegation and the Confused Deputy

The requirement that hurts most to omit is attributability, because its absence enables a classic failure that agents make routine: the confused deputy. A confused deputy is a program that holds authority and is tricked into exercising it on behalf of a less-privileged party. When a planning agent holds broad credentials and passes work to a sub-agent — or acts on instructions embedded in data it processed — the broad-credentialed agent can be induced to perform actions the true originator was never entitled to. If the sub-agent simply reuses the planner's credential, the action is indistinguishable, at the verifier, from the planner acting on its own intent.

The identity-level fix is to make delegation explicit and narrowing rather than implicit and inheriting. OAuth 2.0 (RFC 6749) already separates the party that authorizes from the party that acts, and the OAuth 2.0 Token Exchange extension (RFC 8693) provides the concrete primitive: a principal exchanges its token for a new token that names a different subject, can carry an actor claim recording who is acting on whose behalf, and can be scoped down to fewer permissions. The JSON Web Token format (RFC 7519) carries these claims — subject, actor, audience, expiry — as a signed, verifiable structure. Used correctly, each delegation hop produces a fresh, narrower, attributable credential, so a verifier can see both the acting principal and the chain of delegation behind it.

The data-flow view makes the leak concrete. Authority flows from an authorizing party through the agent to a sub-agent and finally to a resource. The dangerous boundary is the point where the agent decides whether to pass its own broad credential across or to mint a narrowed, attributed one. Everything downstream of a broad-credential hand-off is a place where drifted or injected intent can spend authority the originator never granted.

A Reference Model for Agent Identity

The requirements assemble into a reference model with four roles, independent of any product. An identity authority issues short-lived credentials to workloads that prove eligibility to it; this is the role SPIFFE's issuing infrastructure plays, and it is the only component that mints identity. A workload — the agent or sub-agent — holds a credential that is bound to it and renews it while healthy. A policy decision point evaluates, per request, whether the presenting workload is authorized for the specific action, in the zero-trust spirit of SP 800-207 where no request is trusted by position. And a resource server, the protected API or data store, verifies the presented credential and enforces the decision point's ruling.

The model's virtue is that each of the five requirements maps to a specific role's obligation. Short-lived and machine-issued are the authority's obligation. Attributable is a property of the credential the authority mints and the claims it carries. Continuously verifiable is the resource server's cheap per-request check of a signed, unexpired token. Task-scopable is the decision point narrowing authority to the action. Machine-governed spans the authority and the decision point acting without a human in the per-request loop. Nothing in the model presupposes a person, which is exactly the point — it is an identity architecture whose atoms are workloads.

This piece deliberately stops at the model's shape and its invariants. How an authority proves a workload is eligible before issuing a credential, how credentials are rotated and delegated at runtime, how an identity is revoked the instant an agent is decommissioned, and how a whole fleet's identities are inventoried and audited are each substantial problems in their own right. What matters here is the foundational claim that motivates all of them: an agent is a non-human principal, human IAM's assumptions do not hold for it, and the identity it needs is a short-lived, bound, attributable, task-scoped, machine-governed credential — a different object, derived from the failure of the human one.

Limitations and Threats to Validity

The argument here is a conceptual derivation, not an empirical study, and it should be read as such. The claim that each human assumption fails for agents is an analytical one grounded in the definition of an autonomous agent; a deployment that constrains its agents to short, supervised, single-principal tasks will experience milder versions of these failures, and for such deployments retrofitting machine identity may be lower priority than the analysis implies. The reference model is likewise a synthesis of properties drawn from established standards, not a specification; it names obligations without prescribing protocols, and a real implementation must choose concrete mechanisms that the cited standards leave open.

There is also a residual risk the model does not eliminate. Short-lived, bound, attributable credentials shrink the window and sharpen the trace of a compromise, but they do not prevent an agent that is itself behaving wrongly — through goal drift or a successful injection — from spending the authority it legitimately holds within that window. Identity answers 'who is acting and may they', not 'should this otherwise-authorized action happen given what the agent is trying to do'. That second question belongs to behavioral monitoring and intent governance, which operate above the identity layer. Machine identity is necessary for agent security and it is not sufficient; its job is to make every other control possible by ensuring that, at minimum, the system always knows which principal is acting and can revoke it.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

delegation:
  on_subagent_invoke:
    require_token_exchange: true      # never pass the parent credential through
    new_token:
      subject: subagent_workload_id     # the acting principal is the sub-agent
      act_as:  parent_workload_id       # RFC 8693 actor claim: who delegated
      scope:   least(step.required)     # narrow to just this step's needs
      ttl:     300s                     # short-lived by default
    deny_if:
      - scope == parent.scope           # refuse un-narrowed delegation
      - ttl   >  900s                   # refuse long-lived delegated tokens

Glossary

Principal

Any entity that can be authenticated and to which authorization decisions apply; in human IAM a person, in agent systems a software workload.

Workload

A running unit of software — a process, container, or function invocation — as distinct from the person or team that deployed it.

Machine identity

A credential-bearing statement about a workload that lets other parties authenticate it and make authorization decisions about it.

Binding

The association between a credential and a specific workload, so that possessing the credential means being that workload rather than merely holding its secret.

SPIFFE ID / SVID

A SPIFFE ID is a URI naming a workload's trust domain and path; an SVID is the short-lived, cryptographically verifiable document that binds the ID to the workload.

Confused deputy

A privileged program that is tricked into exercising its authority on behalf of a less-privileged party.

Token exchange

An OAuth 2.0 mechanism (RFC 8693) by which a principal trades a token for a new, possibly narrowed token that can record who is acting on whose behalf.

Zero-trust architecture

A design (NIST SP 800-207) that grants no implicit trust from network position and authenticates and authorizes every access request on its own merits.

References

1. NIST SP 800-207, Zero Trust Architecture (2020)
2. NIST SP 800-63-3, Digital Identity Guidelines (2017)
3. SPIFFE — Secure Production Identity Framework For Everyone, specification (CNCF)
4. IETF RFC 6749, The OAuth 2.0 Authorization Framework
5. IETF RFC 8693, OAuth 2.0 Token Exchange
6. IETF RFC 7519, JSON Web Token (JWT)
7. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
8. NIST AI 100-1, AI Risk Management Framework (AI RMF 1.0)