Why does standard IAM not work for AI agents?

Human IAM assumes a stable principal with a manager, a session measured in hours, and a joiner-mover-leaver process measured in weeks. An agent is a workload that may live for seconds, may run in hundreds of concurrent copies, has no manager, and cannot safely hold a secret because anything in its context can be extracted by prompt injection. It also acts on behalf of a human, and standard token formats have no slot for that delegation.

What should you use for agent identity today?

SPIFFE with SPIRE is the production-ready option. SPIRE attests the workload against selectors such as Kubernetes namespace, service account, and container image digest, then issues a short-lived SVID as an X.509 certificate or a JWT, so no bootstrap secret exists for an injected instruction to disclose. Pair it with per-task credential scoping: name the single repository, split read from write, deny access to CI configuration and secrets, and expire the credential when the task ends.

Agent Identity, Authentication and Credential Scoping

Q: Is there an accepted standard for AI agent identity?

No. Several IETF Internet-Drafts appeared in early 2026, including draft-klrc-aiagent-auth (AI Agent Authentication and Authorization), a WIMSE dual-identity credential, an agentic JWT, and SCIM extensions for agents. draft-klrc-aiagent-auth is an individual submission that the IETF Datatracker states is not endorsed by the IETF and has no formal standing in the standards process. None of these are adopted standards, and any vendor describing them as such is overstating the position.

How to give an AI agent least-privilege access to cloud resources and repositories, why human IAM does not fit, and where the emerging standards actually stand

Why Human IAM Does Not Fit an Agent

The identity model that works for developers breaks in three specific places when the principal is a program

The Common Failure: A Long-Lived Personal Access Token

The fastest way to get an agent working is to hand it a developer's personal access token. It is also the single worst decision available. That token typically carries organization-wide scope, no expiry, and the human's name in every audit record. When the agent later reads a poisoned issue comment and acts on it, the resulting commits are indistinguishable from the developer's own, the blast radius is every repository that person can reach, and revocation means breaking the human's own tooling.

Enterprise identity and access management was designed around a person: someone who authenticates in the morning, holds a session for a working day, and whose access is provisioned by a joiner-mover-leaver process measured in weeks. Every layer of that model - SSO, SCIM provisioning, role assignment, quarterly access review - assumes a stable principal with a manager and an email address. This site covers that human-facing model in the IAM guide. None of it transfers cleanly to an agent.

An agent is a workload, not a person. It may exist for ninety seconds, and it may be one of two hundred concurrent runs of the same container image. It has no manager, and it cannot be trusted to hold a secret, because anything in its context window is one prompt injection away from being read out loud. The identity question therefore changes shape: instead of "who is this user and what role do they hold," the question becomes "which workload is this, what proved it, whose authority is it borrowing, and for how long."

OWASP's agentic security work places Identity and Privilege Abuse among the top risks for agentic applications, cataloged as ASI03 (OWASP GenAI Security Project). That is a useful signal, but a risk taxonomy is not an implementation guide, and the implementation gap is where most teams are stuck.

Lifespan Mismatch

Human credentials are provisioned for months and reviewed quarterly. An agent run may last under a minute, and the next run is a different process on a different node. Any credential whose lifetime exceeds the run is standing privilege that nobody is watching.

Delegation Without a Principal

An agent almost always acts on behalf of a human who asked for something. Existing token formats express one subject. They have no standard slot for "this workload, borrowing this person's authority, for this task" - which is precisely the fact an authorization decision needs.

Attribution Collapse

If the agent authenticates as the human, every log line says the human did it. Post-incident you cannot answer the first question an investigator asks: which run, driven by which prompt, touched this file. Attribution has to survive down to the individual agent execution.

The Standards Landscape Is Unsettled

Several proposals exist. None of them is a standard. Building as though one has won is the mistake to avoid

A cluster of IETF Internet-Drafts appeared in early 2026 attempting to define how an autonomous agent proves who it is. The most comprehensive is draft-klrc-aiagent-auth, "AI Agent Authentication and Authorization", first submitted March 2, 2026 and revised since. Rather than inventing a new protocol, it composes existing ones - the WIMSE workload identity architecture, SPIFFE, and OAuth 2.0 - and its stated goal is to consolidate prior work and identify gaps to guide future standardization.

Read the Disclaimer on the Draft Itself

draft-klrc-aiagent-auth is an individual submission. It has not been adopted by a working group. The IETF Datatracker page states plainly that the document is not endorsed by the IETF and has no formal standing in the standards process. Any vendor describing it - or the related drafts below - as an adopted agent identity standard is overstating the position. Expect the details to change, and design so that a change costs you a configuration edit rather than a rewrite.

Proposal	What It Adds	Status
draft-klrc-aiagent-auth	A composed framework: WIMSE plus SPIFFE plus OAuth 2.0, with the gaps called out rather than papered over	Individual Internet-Draft, no working-group adoption
WIMSE dual-identity credential	Binds the agent's workload identity to the identity of the human or service on whose behalf it is acting - the conceptual core of the whole problem	Draft within the WIMSE working group's problem space
Agentic JWT	Agent-specific claims carried in a JWT, so a resource server can reason about agent context at the token layer	Draft, contested
SCIM extensions for agents	Provisioning and deprovisioning lifecycle for agent identities in a directory	Draft. Note this is lifecycle, not runtime authorization

Microsoft has published its own read of where these efforts are converging in its perspective on agentic identity standards, and the Cloud Security Alliance, with Okta, published a research note on March 18, 2026 arguing that enterprise IAM has a structural gap for AI agents (PDF). Both are worth reading. Neither is a specification you can implement against today.

SPIFFE and SPIRE: The Pragmatic Answer Today

Workload identity that predates the agent conversation, is already deployed in production, and happens to fit

SPIFFE defines a naming scheme and document format for workload identity; SPIRE is the reference implementation that issues those documents. A workload receives an SVID - a SPIFFE Verifiable Identity Document, as either an X.509 certificate or a JWT - whose subject is a SPIFFE ID URI. Critically, SPIRE does not hand out an SVID to anything that asks. It attests first, verifying properties of the node and workload such as Kubernetes namespace, service account, and container image digest, and issues an identity only if those selectors match a registration entry.

That attestation step is what makes SPIFFE fit agents specifically. The agent never holds a bootstrap secret it could be tricked into disclosing, because there is no bootstrap secret; identity derives from what the workload verifiably is, and the resulting SVID is short-lived and rotated automatically. HashiCorp makes essentially this argument in "SPIFFE: Securing the identity of agentic AI and non-human actors" (April 30, 2026), noting that ephemeral, automatically rotated credentials match the deployment cycle of AI systems in a way static credentials never will.

The decision that matters most is your naming scheme, because it is the hardest thing to change later. Encode the run, not just the service, so authorization and audit can both address a single execution.

A SPIFFE ID Scheme for Coding Agents

# One trust domain per environment - never one per team
spiffe://dev.example.internal

# The agent workload itself
spiffe://dev.example.internal/ns/agents/sa/coding-agent

# A single execution of it. Authorization and audit both address this.
spiffe://dev.example.internal/ns/agents/sa/coding-agent/run/7f3c9a12

# The supervising CI runner is a DIFFERENT principal, deliberately
spiffe://dev.example.internal/ns/ci/sa/pipeline-runner

# SPIRE registration: the identity is issued only to a workload that
# attests to these selectors. No shared secret is involved anywhere.
spire-server entry create \
  -spiffeID spiffe://dev.example.internal/ns/agents/sa/coding-agent \
  -parentID spiffe://dev.example.internal/spire/agent/k8s_psat/dev/node-17 \
  -selector k8s:ns:agents \
  -selector k8s:sa:coding-agent \
  -selector k8s:container-image:registry.example.internal/coding-agent@sha256:9f2c \
  -x509SVIDTTL 900

No Secret to Steal

Attestation replaces the bootstrap credential. There is no long-lived token sitting in the agent's environment for an injected instruction to read out and post to an external endpoint.

Rotation Is the Default

SVID TTLs are measured in minutes and renewal is handled by the SPIRE agent. A leaked SVID expires on its own, which turns most credential-exposure incidents into a bounded event rather than an open one.

Federation Across Clouds

Trust domains can federate, so an agent in one cluster or cloud can authenticate to a service in another without a shared static secret crossing the boundary. This matters once agents span accounts.

Scoping Credentials to the Task

Workload identity gets the agent authenticated. Scoping decides how much damage a successful injection can do

Authentication and authorization are separate problems, and the second one is where the blast radius lives. Microsoft Security's guidance in "Least privilege for AI agents: Identity, access, and tool binding" (July 16, 2026) argues for a dedicated agent identity rather than a reused service account or shared secret, roles sized to the smallest meaningful unit of work, an explicit separation of read from write capability, just-in-time elevation instead of permanent grants, and an allowlist of the tools the agent may invoke at all.

Applied to a coding agent, that means the credential is minted per task, names the repository it is allowed to touch, and expires when the task does. Use workload identity federation to exchange the SVID for a cloud credential rather than storing cloud keys anywhere near the agent, and keep secrets out of the model context entirely - the pattern is to inject credentials at a proxy the agent talks through, not into the environment the agent can read. That mechanism is covered in prompt injection defense and in secrets management.

An Illustrative Scoped Token Request

Modeled on the GitHub App installation-token pattern, where the token is minted per installation with an explicit repository list and permission map. The delegation and correlation fields below are a local convention, not part of any published API.

{
  "agent_identity": "spiffe://dev.example.internal/ns/agents/sa/coding-agent",
  "run_id": "7f3c9a12",
  "on_behalf_of": "user:[email protected]",
  "repositories": ["example-org/billing-service"],
  "permissions": {
    "contents": "read",
    "pull_requests": "write",
    "issues": "none",
    "actions": "none",
    "secrets": "none",
    "administration": "none",
    "packages": "none"
  },
  "expires_in_seconds": 900
}

Repository Scope, Not Organization Scope

A task touches one repository, so the credential names one repository. This is the highest-value control here: it converts "the agent can rewrite anything the org owns" into "the agent can open a pull request against one service."

Split Read From Write

Reading code and proposing a change need different authority. Grant contents:read and pull_requests:write, never contents:write. The agent proposes; a review gate merges. Direct push access to a default branch should not exist for an agent identity.

Never Grant Access to Secrets or CI Config

An agent with permission to edit workflow files or read repository secrets can grant itself anything else. Deny the actions and secrets scopes explicitly, and require human review on any diff that touches CI configuration. See supply chain security.

Federate, Do Not Store

Exchange the workload identity for a short-lived cloud credential through OIDC-based workload identity federation. No static cloud access key should exist in an agent workspace, image, or template - if one does, it will eventually be committed or exfiltrated.

Attribution, Revocation and Rotation

The controls that decide whether an incident is investigable and whether it can be stopped

Dual identity is not an academic nicety. When an agent opens a pull request, two facts need to survive into the audit record: which workload did it, and whose authority it was borrowing. Collapse those into one and you lose the ability to answer either "was this agent compromised" or "who authorized this." Keep them separate, correlate them with a run identifier, and an investigator can reconstruct the chain from a human request through a specific agent execution to a specific commit.

Revocation is the control most teams discover they are missing during an incident rather than before one. If the agent's credential is a nine-hundred-second SVID exchanged for a nine-hundred-second repository token, revocation is largely automatic: stop issuing, and everything drains within the TTL. If the agent holds a personal access token, revocation means finding every place that token was copied. That asymmetry is the practical argument for short TTLs.

Deprovisioning needs an owner too. An agent identity created for a proof of concept and never removed is standing privilege that no access review will catch, because it has no manager to review it. Assign every agent identity a named human owner and an expiry date at creation. Broader policy framing lives in AI governance.

Fields Worth Logging

Agent SPIFFE ID, run identifier, delegating human, tool invoked, resource touched, credential scope, and decision outcome. Anything less and cross-system correlation becomes guesswork.

A Working Kill Switch

Stop all issuance for one agent class in a single action, then confirm from logs that in-flight credentials expired. An untested revocation path is a hypothesis, not a control.

Named Human Owner

Orphaned non-human identities are how permission sprawl accumulates invisibly. No joiner-mover-leaver process will ever catch them, so ownership has to be recorded up front.

Trade-offs and What Is Still Unsolved

What this approach costs, and the parts nobody has a good answer for yet

SPIRE Is Real Infrastructure

Running SPIRE means a highly available server, a datastore, per-node agents, and a registration workflow. For a team with a handful of agent runs a week, a managed short-lived-token mechanism from your existing platform is a defensible interim choice. Adopt SPIFFE when the number of workloads makes manual credential handling untenable, not because it is fashionable.

Downstream Systems May Not Speak It

A SPIFFE identity is only useful where something verifies it. Version control hosts, SaaS APIs, and legacy internal services usually accept only a bearer token, so you need an exchange step - and that broker becomes a dependency and a high-value target with its own threat model.

Per-Task Scoping Adds Friction

An agent that legitimately needs a second repository mid-task will fail, and someone has to widen the scope or re-plan the work. That is the control working as designed, but it costs developer time, and it is why teams quietly revert to broad tokens. Budget for it explicitly.

Delegation Semantics Are Genuinely Unsettled

When agent A invokes agent B, whose authority applies, and does it narrow at each hop? The drafts gesture at this; no widely implemented answer exists. Until one does, keep agent-to-agent chains short and re-authorize at each boundary rather than passing a credential along.

A Note on the Statistics You Will See Elsewhere

Several striking percentages circulate in this space: the share of organizations whose IAM tooling cannot achieve zero standing privilege for agents, the share reporting over-permissioned agent access, the share with no policy for creating or removing AI identities. They are widely repeated but consistently secondary-sourced to vendor surveys with no published sample size or methodology, so they are omitted here rather than passed along. If you need a number for a business case, take it from your own access review - it will be more persuasive, and it will be true.

Identity is one layer. These pages cover the containment, secrets, and governance layers around it