AI agent identity and attestation: programmatic access, 2018-2026

An assistant that drafts an answer and an agent that can send the answer are not the same security problem. The latter crosses a boundary: it acts on a service, touches data, and may spend another person's authority. A user login alone cannot explain which software acted, which running copy held the credential, or why that copy was allowed to perform this particular operation.

This guide follows AI agent identity and attestation for programmatic access from 2018 to 2026. The dates do not mark one neat standardization cycle. They trace several pieces that matured separately: workload identity, OAuth delegation, fine-grained authorization, proof-of-possession tokens, and, most recently, agent-specific identity models.

Put those pieces together and you get a stack, not a magic credential. Identity names the agent. Attestation establishes what is running. Authentication proves control of a credential. Authorization limits an action. Delegation records whose authority is involved. Audit preserves enough of that chain to reconstruct the event later.

Separate the agent from the human

An agent acting for a person still needs its own identity. Treating it as the person's session collapses two questions into one:

1. Who supplied the authority or requested the work?
2. Which software principal made the call?

Those answers can differ even during one task. A finance employee may start an expense review, an orchestration service may create a short-lived agent instance, and that instance may call a document system and a payment API. If every request looks like the employee, an investigator cannot distinguish the employee's direct actions from decisions made by the agent. Revoking the agent without disabling the employee also becomes difficult.

The opposite shortcut is incomplete too. A unique agent identity with no link to its initiator shows which software acted, but not whose authority it used. This matters when the same agent serves many people or receives work from another agent.

The clean model keeps at least two principals:

• the human, service, or upstream agent that supplied the request and authority;
• the agent software or runtime instance that attempted the action.

Microsoft's 2026 Entra Agent ID documentation is one concrete implementation of this split. It models an agent identity separately from a human identity and distinguishes autonomous access from delegated access. Its blueprint and instance objects are product-specific, not a universal standard, but the separation is useful beyond that platform.

The split draws another boundary. A prompt, model name, tool list, or downloaded skill can change behavior, but none is an access-control principal by itself. The distinction matters for systems built from reusable instruction packages such as the ones covered in our Agent Zero and SKILL.md guide. Behavior belongs in the evidence around a decision; it is not permission.

The five-part identity stack

A production design can be tested against five records. They may live in different systems, but each answers a different question.

1. A stable software definition

The first record identifies the agent as a configured piece of software. Call it a blueprint, registration, service identity, or agent definition. It points to an owner, approved purpose, allowed deployment context, and lifecycle state.

This identity survives ordinary restarts so administrators can review policy and revoke the agent as a product. Do not share it between unrelated agents merely because they use the same model. A travel assistant and a payroll assistant need different identities even if both call the same inference API.

2. A runtime instance backed by attestation

The second record identifies the running workload. A stable definition says what was registered; attestation supplies evidence about what is executing now and where.

SPIFFE defines a SPIFFE Verifiable Identity Document, or SVID, as a cryptographically verifiable workload identity. SPIRE can issue one after node and workload attestation. Its agent interrogates the local environment, such as the kernel or a Kubernetes kubelet, and compares selectors with registration entries before returning an identity document.

Attestation is stronger than placing a secret in an environment variable. A copied API key can run anywhere. A short-lived workload credential issued after platform checks can be tied to a particular trust domain and renewed without storing a long-lived secret in the agent.

Attestation still does not prove that a model's proposed action is sensible. It answers a narrower question: is this the workload we expected to receive this identity?

3. The subject and delegation chain

When an agent acts for someone else, the request needs both an actor and a subject. OAuth 2.0 Token Exchange, standardized in RFC 8693 in 2020, provides a vocabulary for that relationship. A security token service can receive a subject token and, where needed, an actor token. The resulting token can carry an act claim that records the current actor and, in nested form, earlier actors in a delegation chain.

Delegation and impersonation are not synonyms. With impersonation, the receiving service may see the agent as if it were the subject. With delegation, the service can preserve the fact that the agent is acting on the subject's behalf. Agent systems usually benefit from the latter because the separate actor is important evidence.

Keep chains bounded. If one agent can delegate to a second, which can freely delegate to a third, the original approval becomes less meaningful at every hop. Policy should limit who may receive delegated authority, which audience may accept it, and how long it lasts.

4. An action-specific authorization grant

An identity is not permission. A valid agent may still be forbidden to read a salary file, issue a refund, or message an external address.

OAuth scopes are often too broad for high-consequence actions. RFC 9396, published in 2023, adds an authorization_details structure for richer requests. It can express a type of authorization along with actions, locations, and other resource-specific fields. A payment grant, for example, can name a payee, amount, currency, and permitted action instead of handing the agent a general payments.write scope.

Keep fine-grained grants short-lived and audience-bound. The resource server must validate them rather than trusting the agent's own account of its limits. For risky operations, the policy can also require fresh human approval tied to the exact action details.

5. An audit event that joins the chain

The final record connects the action to the identities and policy decision. A useful event contains more than an agent name and a success flag. It preserves:

• the stable agent definition and running instance identifiers;
• the subject, actor, and any relevant delegation link;
• the requested action, target resource, and authorization decision;
• the credential or grant identifier without logging the secret itself;
• the policy version, approval reference, time, result, and correlation ID.

The model and instruction versions may also be relevant, especially when a behavioral change explains why an allowed action was selected. Those fields support diagnosis, but they do not replace the principal and grant identifiers.

The broader AI agent ecosystem places this identity stack in the control layer around the model. That location is deliberate. The runtime and policy system must enforce access even if the model is confused, manipulated, or simply wrong.

How the stack evolved from 2018 to 2026

There was no single moment when "agent identity" arrived. The important milestones came from workload security and authorization before agent-specific products adopted them.

2018: SPIRE enters the cloud native ecosystem

SPIRE was accepted into the Cloud Native Computing Foundation in March 2018. Its purpose was workload identity in dynamic infrastructure, not AI agents. An agent runtime remains a workload and does not warrant a weaker identity merely because a model participates in its control loop.

SPIRE moved to incubation in 2020 and graduated in 2022. By then, the pattern of attesting a workload and issuing a short-lived identity was established independently of the recent agent market.

2020: OAuth names delegation actors

RFC 8693 standardized token exchange in January 2020. Subject and actor tokens gave security systems a way to distinguish the party whose authority is represented from the party currently acting. This is one of the closest existing building blocks for an agent working on behalf of a user or another service.

2023: Authorization becomes more specific

Two 2023 RFCs cover different weaknesses in bearer-token access. RFC 9396 lets a client ask for detailed authorization instead of relying only on coarse scopes. RFC 9449, known as DPoP, lets an OAuth client demonstrate possession of a key and binds issued tokens to that key. This reduces the value of a stolen token and helps detect replay.

DPoP is not workload attestation. A DPoP proof shows that the caller controls a private key; it does not establish which binary, container, or orchestration environment holds the key. A design may use DPoP and an attested workload identity together because they answer different questions.

2026: agent-specific identity becomes an explicit standards problem

In February 2026, NIST published an initial concept paper on software and AI agent identity and authorization. The paper asks how existing standards can support agent identification, authentication, authorization, least privilege, delegation, human binding, auditing, nonrepudiation, and data-flow provenance. It discusses OAuth, OpenID Connect, SPIFFE and SPIRE, SCIM, zero trust guidance, and Model Context Protocol authorization.

NIST also launched an AI Agent Standards Initiative covering secure, interoperable agents. The important signal is not that the problem has been solved. It is that agent identity now has a dedicated standards and reference-implementation agenda.

Microsoft Entra Agent ID offers a current product example with agent blueprints, instances, sponsors, permissions, and agent-aware sign-in logs. Other vendors will use different objects. One inference follows from the standards landscape: no single format yet represents the whole chain from software registration through workload attestation, delegation, action authorization, and audit.

A programmatic access flow

Consider an employee who asks an internal agent to send a contract to a supplier. A well-bounded flow could work like this:

1. The orchestration service accepts the request under the employee's authenticated session and creates a task record.
2. It starts an agent instance from an approved software definition. The workload platform attests the process and issues a short-lived workload identity.
3. A token service checks that this agent may act for this employee in the contract workflow. It exchanges the relevant tokens and preserves agent and subject identities.
4. The agent proposes send_contract, naming the document, recipient, and expiry. The model's proposal is data, not authority.
5. The policy service compares those details with the employee's role, the agent's policy, recipient rules, and any approval requirement.
6. If allowed, it issues a narrow token for the document service. Rich authorization details describe the permitted action and resource. DPoP can bind that token to the instance's key.
7. The document service validates issuer, audience, expiry, proof of possession, action details, and local policy before sending anything.
8. Each component writes correlated events. The final record can show who requested the work, which agent instance acted, what grant it used, and what the service returned.

Now change one fact: the prompt contains instructions copied from an untrusted document telling the agent to send every contract in the folder. The model may propose the broader action, but the original grant covers one named document and recipient. The policy service rejects the request.

That is why prompt-injection defenses and identity controls are complementary. Filtering malicious instructions may reduce bad proposals. Precise authorization limits what a successful manipulation can execute.

Implementation choices that hold up

Start with the protected action, not with the identity product. List the resources an agent can read or change, then define the evidence required at each boundary.

Prefer ephemeral credentials over embedded secrets

Long-lived API keys make identity ambiguous and rotation disruptive. Use a platform identity, workload attestation, or secretless exchange to obtain short-lived credentials. Keep the signing key in the platform's protected key store where possible.

Separate definitions from instances

A stable definition helps with ownership, policy, inventory, and revocation. Per-instance identity helps with containment and investigation. The two-level design also supports parallel runs without making all copies indistinguishable.

Make delegation visible to the resource server

Do not flatten the agent into the human unless a legacy integration leaves no alternative. Preserve actor and subject claims, and make the receiving service validate both. For autonomous tasks, state that no human subject is present instead of inventing one.

Reduce authority at every hop

A downstream token should have no more authority than the upstream grant and normally should have less. Restrict audience, resource, action, time, and delegation depth. Never let a model construct trusted claims directly.

Bind sensitive grants to a key

Sender-constrained tokens reduce replay risk. DPoP is one option for OAuth clients; mutual TLS is another in suitable environments. Key binding does not remove the need for short lifetimes, audience checks, or workload attestation.

Design revocation and inventory together

Administrators need to find every agent definition, owner, sponsor, active instance, credential, permission, and downstream dependency. Revocation should cover one instance, the stable agent, a user-to-agent delegation, or a compromised signing key without requiring a system-wide shutdown.

Common failure modes

Shared human credentials erase the actor boundary. The logs may look complete while attributing an agent's actions to a person who never performed them directly.

Static agent API keys prove little about the current workload. They can leak into logs, images, developer machines, or unrelated deployments. Rotation becomes the only response because there is no instance boundary.

Attestation without authorization proves that the expected workload is running, then may grant it far too much access. Authorization without attestation may issue a precise grant to an unknown copy of the software. Both controls are necessary for sensitive programmatic access.

Broad scopes turn a small model error into a large operational event. If an agent needs to refund one order, a token that can refund every order is a policy failure even when the agent behaves correctly in testing.

Incomplete delegation logs make multi-agent chains impossible to reconstruct. Recording only the final agent hides who initiated the task and which intermediary passed the authority onward.

Unbounded delegation lets authority drift. A grant intended for one workflow can reach agents with different owners, instructions, or trust domains. Cap the number of hops and explicitly allow recipients.

Finally, identity metadata can become stale. Owners leave, blueprints change, and dormant agents retain permissions. Lifecycle controls such as inventory review, expiry, sponsor reassignment, and automated deprovisioning matter as much as token issuance.

Deployment checklist

Before an agent receives production access, confirm that the system can answer these questions with records rather than assumptions:

• Does the agent have a unique, stable software identity and accountable owner?
• Does each running instance receive a short-lived identity after workload or platform verification?
• Can a resource server distinguish the agent from the human or service on whose behalf it acts?
• Are autonomous and delegated actions represented differently?
• Is authorization limited by audience, resource, action, time, and delegation depth?
• Are high-impact actions tied to explicit details and, when needed, fresh approval?
• Are tokens sender-constrained where replay would be costly?
• Can policy reject an action even when the model requests it and the identity is valid?
• Do logs join the definition, instance, subject, actor, grant, policy decision, and result?
• Can administrators revoke one instance, one delegation, or the whole agent without disabling unrelated users?

If any answer is "no," adding a more capable model will not close the identity gap. Fix the missing boundary first. The standards and product names will keep changing, but the underlying questions are stable: which software is running, whose authority it carries, what exact action it may take, and what evidence remains after it acts.

Trace Brief maintains this guide as standards move from concept papers into specifications and deployments. See the editorial policy for how sources and updates are handled.

Sources and methodology

This article draws on the primary documentation and research listed below. An editor reviewed the technical claims and wording before publication.

1. NIST concept paper on software and AI agent identity and authorization — identity, authorization, delegation, audit, provenance, and standards gaps
2. NIST AI Agent Standards Initiative — 2026 federal initiative for interoperable and secure AI agents
3. SPIFFE concepts — cryptographically verifiable workload identities and SVID formats
4. SPIRE concepts — node and workload attestation process
5. CNCF project page for SPIRE — SPIRE acceptance, incubation, and graduation dates
6. RFC 8693: OAuth 2.0 Token Exchange — subject and actor tokens for impersonation and delegation
7. RFC 9396: OAuth 2.0 Rich Authorization Requests — fine-grained authorization details for actions and resources
8. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession — sender-constrained tokens and replay resistance
9. Microsoft Entra Agent ID overview — current implementation example for agent blueprints, instances, delegation, and logs