Non-Human Identity in Agentic AI

What Is Non-Human Identity?

Starting point: machines need identities too

Identity, in security terms, is the answer to one question: who or what is making this request? For human users, the answer involves a username, a password, a second factor, and a session. For machines — services, workloads, containers, scripts, databases, and AI agents — the same question applies. A service calling an API needs to prove who it is. A container reading a secret needs to be recognized. A background job writing to a database needs to be authorized to do so.

Non-human identity (NHI) is the umbrella term for the identities assigned to these machine actors. The category includes service accounts in an operating system or cloud platform, API keys issued to applications, certificates bound to servers, OAuth2 clients registered to software systems, and workload identity documents issued by orchestration platforms. Anything that operates autonomously and needs to authenticate to another system has an NHI.

A brief history: service accounts to workload identity

The earliest machine identity pattern was the service account — a user-like account in Active Directory or UNIX with a password, created to run a scheduled task or background service. These worked, but passwords had to be managed manually and almost universally weren't rotated. Compromise of a service account password meant standing access to whatever that account was permitted to reach, often indefinitely.

API keys emerged as web services proliferated. A string of characters issued at registration, sent in a header on every request. Simple to issue, simple to verify, and extremely difficult to scope. An API key either works or it doesn't. There is no standard mechanism for binding it to a specific caller, a specific context, or an expiration time.

mTLS (mutual TLS) offered a better model: both the client and server present X.509 certificates during the handshake, cryptographically proving identity to each other. This moved machine identity from a shared secret (the password or key) to a cryptographic proof. The limitation was operational complexity: issuing, distributing, and rotating certificates at scale required a functioning PKI, which many organizations lacked.

workload identity is the current generation. Platforms like Kubernetes, AWS, GCP, and Azure issue short-lived, cryptographically verifiable identity tokens to workloads at runtime, tied to the execution environment rather than a static credential. SPIFFE (covered in section 300) is the open standard that defines how this should work across platforms.

Why machine identity is harder than human identity

Human identity has a natural fallback that machine identity lacks: the person on the other end. If a user's session behaves unexpectedly, you can ask them. If a credential appears in two locations simultaneously, a human review catches it. Human identity also has strong ecosystem support: multi-factor authentication, behavioral biometrics, conditional access, anomaly scoring on login patterns. The cognitive awareness of the user is itself a control.

Machines have none of this. A compromised API key or service account credential makes requests that are indistinguishable from legitimate ones. There is no second factor available. There is no way to ask the workload whether it intended to make this call. Revocation requires knowing the credential is compromised in the first place.

Three structural problems make machine identity persistently harder. First, secrets tend to end up in configuration files, environment variables, and code repositories — they spread to wherever the service needs them, which is usually everywhere. Second, machine identities accumulate: they are created for a project or sprint and never decommissioned. Third, delegation chains are opaque: service A calls service B on behalf of user C, and the identity of the original requester is often lost by the third hop.

The scale problem

A mid-size enterprise in 2025 has somewhere between 10 and 50 human identities per machine identity in the traditional model. Modern cloud-native environments invert this ratio sharply. Containerized microservice deployments may run hundreds of service instances, each with its own identity. CI/CD pipelines create and destroy workloads continuously. SaaS integrations mean OAuth grants accumulate in every connected application. A medium enterprise today has more machine identities than human ones, often by an order of magnitude.

This scale changes the security calculus. Discovery — finding all the machine identities that exist — becomes a prerequisite for managing them. Rotation, which was straightforward for a small number of service account passwords, becomes an orchestration problem at scale. Decommissioning requires knowing which identities are still in use, which requires runtime telemetry that most organizations do not have.

Key terms

• service account A user-like account in a directory service (Active Directory, LDAP, GCP, AWS IAM) created to represent a machine or application rather than a person.
• API key A static secret string issued by a service to authenticate a caller. No expiry by default, no scoping mechanism, no cryptographic binding to the caller.
• mTLS Mutual TLS: both client and server present X.509 certificates during the TLS handshake, providing cryptographic proof of identity on both sides.
• workload identity A short-lived, cryptographically verifiable identity document issued to a running workload by its execution platform. Replaces static credentials with runtime-issued proof.
• SVID SPIFFE Verifiable Identity Document. The identity artifact produced by the SPIFFE framework — either an X.509 certificate or a JWT, depending on the context. Defined in section 300.
• trust domain A namespace in SPIFFE that identifies a system boundary. Workload identities are scoped to a trust domain. Federation allows two trust domains to accept each other's SVIDs.

How Agentic AI Changes the Problem

What "agentic" means in practice

An agentic AI system is one that takes multi-step actions autonomously to accomplish a goal, rather than producing a single output in response to a single input. The defining capability is tool use: an agent can call external APIs, read files, execute code, browse the web, send messages, or invoke other agents — and then use the results to determine its next action. This loop continues until the task is complete or the agent is halted.

In a concrete deployment, "agentic" might look like: a user asks an assistant to research a topic and produce a summary. The assistant breaks this into sub-tasks, queries multiple APIs, stores intermediate results, spawns a sub-agent to handle a specialized portion, synthesizes the outputs, and delivers a final response. The user sees one request and one response. In between, dozens of distinct operations occurred — each with its own authentication event, authorization decision, and data access.

Sub-agent spawning is increasingly common. An orchestrator agent delegates work to specialist agents: one that handles document retrieval, one that handles code execution, one that handles external communication. The orchestrator may pass credentials, context, or capability grants to the sub-agents it creates. What those sub-agents do with what they receive is the governance problem.

The fundamental shift

IAM was designed around a synchronous, human-initiated model. A person makes a request. The system authenticates them. An authorization policy evaluates the request against the identity's entitlements. Access is granted or denied. The session ends. The model is essentially stateless between authentication events: the identity is verified at the boundary, and the session proceeds within whatever permissions that identity holds.

Agentic AI breaks this model in several ways. The agent authenticates once but acts many times over an extended session. Each action is a distinct authorization event. The sequence of actions is not known at authentication time. The actions span multiple systems, each with its own policy engine. And the agent may take actions that alter the context for its subsequent actions — reading data from one system that influences what it sends to another.

This means the authorization question is not "can this identity access this resource?" — it is "can this identity, pursuing this task, take this specific action at this point in its execution, given everything it has already done?" That is a different and harder question. It requires state. Current IAM does not maintain it.

The delegation explosion

Human delegation in IAM is well-understood: a user grants another user or a service access to act on their behalf. This is modeled in OAuth2, in Kerberos constrained delegation, in Azure managed identity federation. The patterns are mature. The scope is typically bounded: one principal delegates to one other principal for one defined purpose.

Agentic delegation is structurally different. An orchestrator agent receives a task from a user and spawns three sub-agents. Each sub-agent calls external APIs using a token that was issued to, or inherited from, the orchestrator. Sub-agent B spawns a nested sub-agent to handle a data fetch. That nested agent makes an API call that modifies data in a production system.

The accountability question: who is responsible for that production data modification? The user who initiated the top-level task. The orchestrator that delegated to sub-agent B. Sub-agent B that spawned the nested agent. The nested agent that executed the call. The answer is probably all of them, but the audit trail that would let you reconstruct that chain does not exist in most current deployments. Tokens do not carry delegation ancestry. Access logs record the immediate caller, not the chain.

The governance problem compounds as delegation depth increases. At depth two or three, the connection between the original human instruction and the eventual system action becomes extremely difficult to reconstruct. At depth five or ten — which is plausible in a complex autonomous system — it may be practically impossible.

Token persistence across session boundaries

A less-discussed but significant problem: agents that carry credentials across context resets or session boundaries. In a multi-turn agent system, the agent may persist its authentication state between invocations. A token issued in turn one is still present in turn forty-seven. The original session context — what the user asked for, what the agent was authorized to do — may have been summarized, truncated, or lost. The credential remains.

This is analogous to the standing access problem in human IAM, but with a twist: the expiry model that makes short-lived workload identity tokens safe assumes that the session ends. If the session is perpetual, or if the agent has a mechanism to refresh its own tokens autonomously, short-lived tokens become effectively long-lived ones. The credential surface is larger than the credential lifetime implies.

What current IAM covers — and what it does not

It is worth being precise here. The existing IAM category has real, mature coverage of several problems:

• Authentication: verifying that a machine identity is what it claims to be, via certificates, tokens, or cryptographic proofs.
• Credential lifecycle: issuing, rotating, vaulting, and revoking secrets and certificates.
• Entitlement governance: discovering what identities exist, what access they hold, and certifying that access periodically.
• Access policy enforcement: evaluating whether a given identity is permitted to access a given resource at request time.

These are solved problems, or close to it. What current IAM does not cover:

• Behavioral consistency: whether the sequence of actions an agent takes is consistent with what it was originally asked to do.
• Intent verification: whether the action being taken at this moment reflects the original task or a redirect introduced by external content.
• Mid-session drift detection: whether the agent's objective has shifted during execution, within its permission boundary.
• Delegation chain accountability: who bears responsibility for an action taken at depth N of a delegation chain.

Workload Identity Standards

SPIFFE: the open workload identity standard

SPIFFE stands for Secure Production Identity Framework For Everyone. It is a CNCF (Cloud Native Computing Foundation) open standard, not a product. SPIFFE defines what a workload identity is, what format it takes, and how it is issued and verified — across platforms, clouds, and organizational boundaries. The goal is interoperability: a workload in one environment should be able to prove its identity to a service in a completely different environment without pre-shared secrets.

The core concept is the SPIFFE ID: a URI that uniquely identifies a workload within a trust domain. The format is:

The trust-domain is a namespace owned by an organization or team. The path identifies the specific workload within that domain. The format is deliberately flexible: the path structure is not mandated by the spec, so teams can encode whatever metadata is meaningful for their system.

SVIDs: the identity document

A SPIFFE Verifiable Identity Document (SVID) is the cryptographic artifact that carries the SPIFFE ID. The spec defines two SVID formats, used in different contexts:

X.509-SVIDs are X.509 certificates with the SPIFFE ID encoded in the Subject Alternative Name (SAN) field as a URI. They are used at the transport layer, typically via mTLS. Both communicating parties present their X.509-SVIDs during the TLS handshake, and each side validates the other's certificate against a trusted certificate authority in the same trust domain. X.509-SVIDs are short-lived by design — typically valid for hours, not days — and are automatically rotated by the issuing infrastructure.

JWT-SVIDs are JSON Web Tokens carrying the SPIFFE ID in the sub claim, signed by the trust domain's issuing authority. They are used in application-layer contexts where X.509 is not practical: HTTP request headers, gRPC metadata, webhook payloads. JWT-SVIDs carry an audience (aud) claim that scopes the token to a specific service or endpoint, limiting the blast radius of a stolen token.

SPIRE: the reference implementation

SPIRE (the SPIFFE Runtime Environment) is the reference implementation of the SPIFFE specification. It is a CNCF project, open source, and production-grade. SPIRE has two components: a SPIRE Server and one or more SPIRE Agents.

The SPIRE Server is the certificate authority for a trust domain. It holds the signing keys, issues SVIDs, and manages the registration of workloads. It maintains a registry of workload identities and their attestation selectors.

SPIRE Agents run on each node in the environment. When a workload starts, it contacts the local SPIRE Agent via a Unix socket. The agent performs workload attestation: it queries the kernel and platform to determine the identity of the workload making the request. Selectors might include: the Kubernetes pod's service account name and namespace, the container image hash, the calling process's UID, or the AWS instance identity document. If the attested selectors match a registered entry in the SPIRE Server's registry, the agent fetches an SVID from the server and delivers it to the workload. No static secret is needed. The workload never handles a password or API key.

Trust domain federation in SPIRE allows two independent SPIRE installations to establish mutual trust. Each server publishes a bundle of its root certificates. When workloads in domain A need to authenticate to services in domain B, both sides can validate the other's SVIDs against the federated bundle. This enables cross-organization or cross-cluster mTLS without out-of-band key exchange.

OAuth2 patterns for non-human identity

OAuth2 is the dominant framework for delegated authorization in web and API contexts. Two patterns are most relevant for NHI:

The client credentials grant (RFC 6749 §4.4) is the standard pattern for machine-to-machine authentication. The client (a service or workload) presents its client_id and client_secret directly to the authorization server and receives an access token scoped to its own permissions. There is no user involved. The access token is short-lived and scoped to a specific audience. The limitation is the client_secret: it is a static credential that must be managed. Workload identity federation can replace it — cloud platforms now allow workloads to present a signed identity assertion (from SPIFFE or the cloud platform's own identity system) in place of a static secret.

The token exchange grant (RFC 8693) addresses delegation: a service that receives a token on behalf of a user can exchange that token for a new token scoped to a downstream service, carrying provenance information about the original subject. This is the standards-track mechanism for constrained delegation — "I am service A, acting on behalf of user B, calling service C." The resulting token carries both identities. RFC 8693 is the correct tool for building auditable delegation chains, though implementation support is inconsistent across authorization servers.

mTLS: mutual authentication at the transport layer

Standard TLS (as used in HTTPS) authenticates the server to the client: the server presents a certificate, the client validates it. Mutual TLS extends this: the client also presents a certificate, and the server validates it. Both parties cryptographically prove their identity before the connection proceeds.

For machine-to-machine communication, mTLS is the strongest available authentication mechanism at the transport layer. The certificate binds the identity to a cryptographic key pair. There is no password to steal, no API key to leak. Revocation is handled by certificate expiry and CRL/OCSP, or by short lifetimes that make revocation unnecessary. Combined with SPIFFE SVIDs, mTLS provides cryptographically verifiable workload identity with automated rotation and no static secrets.

The operational challenge is certificate issuance at scale and across organizational boundaries. Service meshes (Istio, Linkerd, Consul Connect) automate mTLS establishment between services within a cluster, but cross-cluster and cross-organization mTLS requires federation — the trust domain mechanism described in the SPIRE section above.

What these standards cover — and where they stop

SPIFFE, mTLS, and OAuth2 client credentials together solve the authentication problem for workloads with a level of rigor that was not widely achievable five years ago. Short-lived cryptographic identity documents, automated rotation, attestation tied to execution environment, no static secrets in configuration. This is genuine progress.

The gap is precise: all of these answer who. None of them answer what for.

A SPIFFE X.509-SVID tells you that the certificate holder is spiffe://agents.example.com/agent/summarizer/instance/a7b3c9. It tells you nothing about what task that agent was given, whether the action it is currently taking is consistent with that task, or whether something has redirected the agent between the point of authentication and the point of this specific API call. Authentication is verified. Intent is invisible.

The CNCF SPIFFE specification and RFC 8693 are the primary references for this section. Neither document addresses behavioral authorization — their scope is explicitly limited to identity issuance and delegation.

The Runtime Authorization Problem

Defining the problem precisely

Authentication answers: is this identity genuine? Authorization answers: is this identity permitted to access this resource? Both are well-defined problems with mature solutions. A third property — behavioral consistency — is distinct from both and is not addressed by either.

Behavioral consistency, as a security property, asks: is the sequence of actions this agent is taking consistent with what it was authorized to accomplish? An agent authorized to summarize a set of documents has a bounded action space: read those documents, produce text. An agent that reads the documents and then begins querying an employee directory, encoding data in base64, and making outbound HTTP requests to external endpoints is technically operating within its read permissions — but is clearly not doing what it was sent to do.

The gap between authentication/authorization and behavioral consistency is the runtime authorization problem. It is a security property that current IAM infrastructure has no mechanism to enforce, because IAM was never designed to maintain session-level behavioral state.

What a runtime authorization system would need to do

A system designed to enforce behavioral consistency across an agentic session would need to accomplish several things that no current deployed system does:

• Capture declared intent at session start. Before the agent takes any action, the system records what the agent was asked to do. This becomes the reference signal for the session — the baseline against which all subsequent actions are evaluated. The challenge is structured capture: natural language instructions need to be represented in a form that admits comparison with observed behavior.
• Maintain action-level telemetry throughout the session. Every tool call, API invocation, data read, and write must be logged in a way that is attributable to the specific agent instance, carries the delegation ancestry if applicable, and is available for in-session evaluation — not just post-hoc review.
• Compare realized actions against declared intent at each step. The comparison mechanism needs to distinguish actions that are clearly within scope, actions that are clearly outside scope, and the broad middle ground of ambiguous actions that could be consistent with the task or could represent drift.
• Enforce in real time. Post-hoc detection of behavioral drift is better than nothing. It is not a sufficient control. An agent that exfiltrates data over thirty seconds cannot be remediated by an alert that fires six minutes later. The enforcement mechanism needs to operate at action execution time, not after the fact.
• Handle delegation without losing accountability. When the root agent spawns sub-agents, the behavioral constraints of the session need to propagate down the delegation chain. A sub-agent cannot have broader behavioral permissions than the task scope its parent was given.

Why this is hard

Three structural difficulties make runtime behavioral authorization genuinely hard, not just underimplemented.

First, agents do not declare intent in structured form. A user says "research competitor pricing and put together a summary." That instruction is sufficient for a human to act on. It is not a structured authorization policy. Extracting a set of bounded, verifiable behavioral constraints from natural language — and doing so robustly, across diverse task types — is an unsolved problem. Approximate solutions exist; none are reliable enough for hard enforcement.

Second, the action chain spans multiple systems with different visibility. An agent using tools across a browser, a code execution environment, an API gateway, and a file system produces telemetry in four places with four different formats, four different logging schemas, and no common correlation mechanism. Reconstructing a coherent action chain across these systems is a significant engineering problem, independent of the authorization logic on top of it.

Third, distinguishing legitimate context adaptation from behavioral drift is a judgment call. An agent summarizing research documents that follows a citation to an adjacent topic is adapting to the task. An agent that follows citations to a completely unrelated topic and begins performing actions unrelated to the original request has drifted. The boundary between these is not crisp, and false positives (halting legitimate agents) carry real costs.

Multi-agent trust and delegation bounds

When agent A delegates to agent B, what authorization does agent B inherit? This question does not have a consensus answer in any current standard or deployed system.

Three models are possible. Full inheritance: agent B gets everything agent A had. This maximizes capability but means a compromised or misbehaving sub-agent has the full permission and behavioral scope of the orchestrator. Explicit downscoping: agent A issues a constrained grant to agent B, specifying what subset of its permissions and behavioral scope the sub-agent is authorized for. This is the least-privilege model and the most secure, but it requires the orchestrating agent to reason about what scope is appropriate — which is itself a non-trivial capability. Zeroing: agent B starts with no inherited context and must re-authenticate with the root authority. This is secure but breaks continuity in delegation chains where context propagation is necessary for the task.

Capability-based security models suggest a partial answer: rather than inheriting role-based permissions, sub-agents receive specific, scoped capability tokens that permit exactly the actions they need for their delegated sub-task and nothing more. This limits blast radius at each delegation hop. It requires the issuing system to understand task decomposition, which returns us to the structured intent problem.

Current research directions

The field is active but pre-standardization. Several approaches are being explored:

Constitutional AI and capability restriction at training time. Rather than enforcing behavioral bounds at runtime, this approach bakes constraints into the model itself during training. The model is trained to refuse certain categories of action regardless of instructions. This works for coarse constraints (do not produce CSAM, do not provide instructions for weapons) but is brittle for task-specific behavioral bounds (do not access systems outside the scope of this particular task). The constraint is global; the requirement is contextual.

Capability-based security tokens scoped to specific intents. Rather than issuing general-purpose access tokens, this approach issues tokens that carry the task context as a first-class attribute. A token issued for "summarize documents in folder X" encodes that scope, and the receiving service can evaluate whether the requested action falls within it. This maps well to existing OAuth2 scope mechanisms but requires the authorization server to understand task semantics — a hard dependency on structured intent representation.

Dual-Intent Runtime Authorization (DIRA) is one proposed framework for this class of problem, treating declared intent and realized intent as two signals compared at each action step: dira.cyberdaemon.ai.

Open problems

1. Cross-trust-domain delegation chains When an agent delegates across a SPIFFE trust domain boundary, behavioral context does not transfer. The receiving system knows who sent the request via the SVID. It does not know the original intent, the delegation depth, or the constraints the originating domain expected to apply. No standard exists for behavioral context propagation across trust domain boundaries.
2. Audit trail completeness An audit trail that records tool calls but not reasoning state is incomplete. An agent that reaches the same API call from two different reasoning paths — one legitimate, one injected — produces identical audit logs. Distinguishing them requires logging the intermediate reasoning, which raises its own privacy and storage questions and is not currently standardized.
3. Real-time vs. post-hoc verification Post-hoc analysis (reviewing logs after the session) is tractable with existing tooling. Real-time enforcement (blocking an action before it executes) requires sub-second evaluation of behavioral consistency, which is computationally expensive if the evaluation involves a language model and may introduce unacceptable latency in tool-calling loops.
4. Structured intent capture at scale Reliably extracting a bounded, verifiable behavioral specification from free-form natural language instructions is unsolved. Approaches that work in controlled settings fail on the diversity of real-world task descriptions. Until this problem is solved, any runtime authorization system that depends on structured intent has a soft dependency on an unreliable extraction mechanism.
5. Standard identity for the agent lifecycle SPIFFE covers workload identity at a point in time. It does not cover the agent lifecycle: identity at spawn, identity propagation through sub-agent delegation, identity at session end, and revocation of a specific agent instance without revoking the entire workload class. Agent-specific lifecycle identity is not addressed in any current standard.