IETF draft describes IAM for autonomous AI agents because user SSO is not enough

On 2 November 2026 the IETF working group WIMSE published an internet draft for identity and access management of autonomous AI agents. The core: give each agent its own cryptographically bound identity, use short-lived credentials, record the human principal separately as delegated context and verifiably log which agent performed which action on whose behalf, because ordinary user SSO is not enough for this.

This draft, titled AI Identity Management System, describes how existing building blocks such as WIMSE and the OAuth 2.0 family can be applied to software that independently calls tools, services and data sources. Important to hold on to: it is a working document, not an established RFC and not a binding standard.

What exactly does the IETF draft say about IAM for autonomous AI agents?

The draft treats each agent as a separate workload with a unique identifier and credentials that are cryptographically bound to that agent. It calls for short-lived, runtime-issued credentials and discusses keeping credential material outside the language model's direct reach. OAuth 2.0, transaction tokens, policy-based authorization, human confirmation and continuous monitoring together form the model.

The draft distinguishes five control points in one continuous chain:

• Agent identity that does not coincide with the human principal; the user or system is recorded separately as delegated subject context.
• Runtime authentication with short-lived, cryptographically bound credentials instead of static API keys.
• Fine-grained authorisation that translates the agent's mission into minimal scopes and resource, action, time and transaction limits.
• Human confirmation for sensitive actions; according to the draft, a local approval button in the agent UI is not authorisation in itself.
• Posture and risk signals, revocation and audit evidence, so that credentials can be renewed, privileges restricted or sessions terminated if the runtime context changes.

Why is ordinary user SSO or a service account not enough for AI agents?

Because an SSO session represents a human and a service account is usually a long-lived, broadly authorised identity. An autonomous agent independently makes decisions about which tool it calls and which data it requests, and often acts on behalf of changing users. As a result, the agent's identity and the delegated context of the principal must be managed separately.

In the documentation on Microsoft Entra Agent ID, Microsoft shows what this can look like in an enterprise environment: agent identities get their own lifecycle with owners, sponsors, provisioning and deletion, and policies such as Conditional Access can be applied separately to autonomous agents. This is vendor documentation and not a universal standard, but it confirms the principle that an agent is not an ordinary service account.

The operational urgency is evident from research by Microsoft Threat Intelligence, which on 5 November 2026 described how attackers use agentic tooling to find and abuse exposed secrets, using valid workload or application identities to access cloud resources, including Azure Key Vault in a reported case. We do not read this as a prediction that every attack proceeds this way, but as confirmation of the need for least privilege, credential rotation, monitoring of workload identities and rapid revocation. Secrets management is also a recurring theme in OWASP guidance on application security, which reinforces why long-lived keys and exposed secrets are an avoidable risk.

The Coalition for Secure AI (CoSAI), active under OASIS Open, describes agentic IAM in its publication on agentic identity and access as a trust layer on top of existing enterprise IAM, with continuous verification, secure delegation and intent-based authorisation. It also names the risk that an agent assembles sensitive insights from sources that are innocuous in themselves.

What does this mean for directors, lawyers and CISOs deploying agents?

Our analysis: because the IETF draft treats agents as separate workloads with their own identity and short-lived credentials, a CISO cannot make do with extending the existing SSO; the identity team must set up a separate lifecycle for agent identities, with an identifiable owner or sponsor per agent. Because the draft discourages credentials that the model itself can see, any agent with a long-lived API key carries an avoidable risk, so it is sensible to inventory agents and plan the replacement of long-lived keys. Because the draft states that a local approval button is not authorization by itself, high-impact actions should require separate, verifiable confirmation through the authorization server. Because the threat intelligence shows how quickly abuse can proceed, behavioural detection on workload identities and immediate revocation are needed, as damage can occur before a quarterly audit begins.

In summary, from this news follows the following order of measures:

1. Inventory which agents are active and which identity and credentials they use.
2. Assign an owner or sponsor per agent and manage the identity as a separate lifecycle entity.
3. Replace long-lived keys with short-lived, runtime-issued credentials.
4. Record minimal scopes and transaction limits per agent in an independent authorisation layer.
5. Require verifiable human confirmation for sensitive actions and set up immediate revocation.

Anyone who already has agents in production can tie into broader frameworks around agentic AI and AI agents and into the working method to separate an autonomous agent from the authorisation and human approver.

Which minimal audit record must I log per agent action?

The draft describes audit records that should include agent identity, the delegated user or system, the resource, the action, the authorization decision, the timestamp, a correlation ID, and revocation or remediation events. In our assessment, these fields form a practical minimum for reconstructing which agent did what on whose behalf.

A workable minimal record contains:

• Agent ID and the binding to the credential or key;
• Delegated user or system;
• Mission or transaction reference;
• Resource, action and granted scope;
• Authorisation decision and the posture or risk signal that was taken into account;
• The tool and service chain used;
• Timestamp, result and any revocation.

Such a record makes review possible without a reviewer needing broad access to the underlying sensitive data. For the choice of exactly which events to log and for how long, our earlier explanation of a two-layer audit record that links the technical event and the decision can help.

Sources: The article draws on the IETF WIMSE internet draft on AI identity management, documentation on Microsoft Entra Agent ID, research from Microsoft Threat Intelligence and guidance from the Coalition for Secure AI under OASIS Open.