A procurement tool agent calls your Jira API with the service account a former contractor set up in 2023. It inherited write access to every project the account ever touched. When auditors ask which human authorised the agent’s purchase-order change last week, your logs show the service account’s name. The logs cannot tell you who operated it, what delegated it, or whether the action was inside any authority anyone granted on purpose.

If that paragraph reads like your environment, you are not an outlier. In a January 2026 survey of 228 IT and security professionals run by the Cloud Security Alliance and Aembit, 68% of organisations said they cannot clearly distinguish AI agent actions from human activity. 74% agreed agents routinely receive more access than their tasks require. Only 36% give agents their own dedicated identities. The rest run them as shared service accounts or, worse, under a human user’s identity.

Regulators have noticed. NIST’s National Cybersecurity Center of Excellence published a concept paper in February 2026 titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, and in August 2026 NIST followed with guidance drawing on the public comments. The message in both documents is the same: AI agents are a distinct class of non-human identity, and the identity problems they raise are solvable with standards most enterprises already operate.

This post is a practitioner’s view of that work: what agent identity actually is, how authorisation and delegation differ from what your IAM already does, and what to do first.

Agents are workloads, not features

The load-bearing idea in the standards work, stated plainly in the IETF’s AIMS draft (draft-klrc-aiagent-auth) and echoed in NIST’s guidance, is this: an AI agent is a workload, and the identity, authentication and authorisation problems it raises are not new categories of problem. They are workload-identity problems you may already solve for your Kubernetes pods and CI runners, plus two genuinely new wrinkles: delegation and autonomy.

That reframing saves you from inventing an agent-specific IAM stack. The standards being proposed are old friends:

• SPIFFE/SPIRE for issuing short-lived, cryptographically verifiable workload identities. An agent that lives for twenty minutes should hold an identity that lives for twenty minutes. SPIFFE’s automatic rotation and revocation model fits agent lifecycles almost embarrassingly well.
• OAuth 2.1 for delegated authority. The agent acts as an OAuth client; the access token carries the agent as client_id and the delegating human as sub. Your authorisation server already knows how to do this.
• OIDC and SCIM for authentication and lifecycle. Agents get provisioned, re-provisioned and deprovisioned like any other principal.
• WIMSE identifiers (with SPIFFE IDs as the deployed instance) so that authorisation decisions and audit records can all key off one stable URI per agent.

NIST’s August guidance names the same set, plus sender-constrained token methods such as DPoP, and calls out the antipattern most organisations still run: static API keys copied into agent config files, markdown documents, or logs.

What IAM is missing: three gaps that matter

If agents are workloads, why doesn’t existing IAM just cover them? Because three properties of agents break assumptions IAM was built on.

1. Delegation chains. A human delegates to an orchestrator agent; the orchestrator spawns research agents; a research agent calls a tool. Every hop is an authorisation event. The NCCoE concept paper treats delegation as one of its six core areas, and the emerging principle is simple to state and hard to ship: authority narrows at every hop and never widens. Each delegation link should be scoped-narrower than its parent and time-bound. Your OAuth token exchange machinery can express this. Few organisations have wired it for agent chains.

2. Credential isolation from the model. The AIMS draft states it as a MUST NOT: “The Large Language Model MUST NOT have access to an agent’s credentials or to credentials that may be needed to access tools and services.” This is the identity-layer echo of the reference-monitor doctrine: the secret sits outside the manipulable component. A prompt-injected model that cannot touch credentials cannot exfiltrate them. I’ve covered this boundary problem before in the context of the fail-open problem in agent security; at the identity layer it means the agent workload holds capability tokens, and the model holds none.

3. Attribution. After an incident, you must be able to answer: which agent did this, under whose delegated authority, against which policy. The CSA survey found only 28% of organisations can trace agent actions back to a human sponsor across all environments. That failure has a name in the survey data (attribution collapse) and an architectural fix: agent identity that is stable, delegate-aware, and carried into every action record. Shared service accounts make the distinction structurally impossible.

Worked through: the procurement agent, fixed

Take the agent from the opening. Same workflow, identity-first design.

The agent registers as a workload at deploy time. SPIRE issues it an X.509 SVID carrying a SPIFFE ID specific to this agent deployment, say spiffe://prod.acme.example/agent/procurement-tool/instance-7f3a, distinct from every other agent instance that has ever run in that estate.

It authorises to your OAuth server with its workload credential. One of two delegations applies. If a human asked for the purchase order, the flow is authorisation code with the human in the loop: the resulting token names the agent as client_id and the delegating human as sub. If the agent acts on its own schedule, client credentials with its own registration apply, and that fact is visible in every downstream decision. Either way, no human account’s password or key ever enters the agent’s config.

The agent’s access to Jira is scoped at issue time: this agent instance, this Jira project, write on purchase-order fields, nothing else, credential valid for the task window. If a sub-agent is spawned to chase supplier details, it receives its own short-lived identity whose delegated scope is strictly narrower, and it cannot request anything beyond that scope because the authorisation server will not issue it.

The model behind the agent never holds any of these credentials. If a prompt injection in a supplier’s invoice convinces the model to attempt a transfer, the model has nothing to attempt it with: the tool call fails before it reaches the API, and the denied attempt, bound to the agent identity and the delegating principal, is already in the record.

When the auditor arrives, the trail answers their question in place: which agent instance acted, which human authorised it, which policy gated it, and a receipt to prove none of that was edited after the fact.

Nothing in this walkthrough required a new IAM product. It required treating the agent as a workload and wiring the standards you already run for workloads to accounts that are not shared, not static, and not human. That is the whole position NIST’s guidance lands on, expressed in an afternoon of architecture decisions.

The current failure modes, in one table

The survey data behind these: 43% of organisations use shared or generic service accounts for AI agents; 31% operate them under human identities; 47% of enterprises reported a confirmed AI-agent security incident in the prior twelve months.

What the emerging standards stack looks like

The honest picture as of October 2026: the standards are mostly existing standards, being composed, with agent-specific extensions still in draft.

• Identity: SPIFFE/SPIRE SVIDs (X.509 or JWT), with WIMSE as the identifier model. Short-lived by default. Hardware-backed attestation is the advanced tier, not the interop requirement.
• Authentication to a delegation server: OAuth 2.1 flows with workload credentials, never static client secrets.
• Authorisation: OAuth token exchange for downscoping; policy engines such as Cedar or OPA for the deterministic control plane. The useful principle from the runtime-governance submissions to NCCoE: IAM verifies who the agent is; a runtime policy layer verifies whether it should do this specific action now, deterministically, outside the LLM.
• Delegation: OAuth Identity and Authorization Chaining Across Domains, Transaction Tokens, and (in draft) the IETF Agent Authorization Envelope layering Verifiable Credentials over workload identity so a relying party with no relationship to the agent’s home environment can still evaluate its authorisation.
• Cross-boundary proof: this is where the standards end and the open questions begin. SPIFFE attestation presumes trust in the issuing infrastructure; when your agent needs to prove itself to another organisation entirely, you need something else. That is precisely the problem cross-organisation trust layers (like the receipts and handshakes in my own project, raucle) are built for, and it is the part I expect to remain contentious longest.

What to do first, in order

This is the part I would want if I were reading this post as an enterprise architect.

1. Inventory the agents you actually have. All of them, including the unsanctioned ones. Your sanctioned count is not your agent count; the CSA found organisations with over a hundred sanctioned agents often run an equal or larger shadow population. An agent inventory is your CBOM for identity (I’ve written about that inventory gap separately).
2. Kill shared accounts and human-identity delegation. Every agent gets its own identity. 36% of organisations do this today; it is the single highest-leverage change on the list.
3. Bind credentials to the workload, never the model. Capability tokens or OAuth grants held by the agent runtime; the LLM holds none. Static API keys in agent configs are the named antipattern; replace them with short-lived, audience-restricted credentials.
4. Make delegation explicit and narrowing. Every delegated action should carry the delegating principal in its token (client_id + sub at minimum), and each hop should hold strictly less authority than the one before.
5. Decide who owns agent identity before the incident. The survey’s ownership distribution (security 28%, engineering 21%, IT 19%, no owner 9%) is a proxy for what your organisation looks like. Incident response needs one authoritative starting point.
6. Carry identity into evidence. Logs that stop at the credential boundary are not audit trails. Every action record should resolve to: agent identity, delegating principal, policy evaluated, decision, and a verifiable receipt where it matters.

The closing note I keep repeating

NIST’s four recurring failures (credential sharing, static or long-lived credentials, broadly scoped access, excessive reliance on human approval prompts) are not exotic. Every one of them exists in enterprises that passed their last ISO 27001 audit. The gap is not awareness; it is that agent deployments reached organisational scale in months, while identity governance for them has not left the starting blocks.

The standards to fix it are arriving. The survey says adoption is outrunning them. The organisations that close the identity gap first will find the rest of agent governance much cheaper, because audit, evidence, authorisation and even prompt-injection containment all key off the same primitive: knowing which agent did what, under whose authority.

You cannot prove what you cannot attribute. Start with identity.

The CSA/Aembit survey data cited is from January 2026 (228 respondents, IT and security professionals). NIST references: the NCCoE concept paper Accelerating the Adoption of Software and AI Agent Identity and Authorization (February 2026), NIST’s guidance on identity foundations for agentic AI (August 2026), and the IETF AIMS draft (draft-klrc-aiagent-auth-03, July 2026). Sources and claims are drawn from the public documents; corrections and counterpoints welcome.