WIMSE for AI Agents Guide: Workload Identity Tokens, Proofs and Agent Credentials

Most AI agents still authenticate with static API keys or shared service account secrets, which cannot say which agent made a call, cannot be bound to the caller and are rarely rotated. The IETF WIMSE (Workload Identity in Multi System Environments) working group is standardising a different base: each workload gets a URI identifier in a trust domain, a short-lived credential bound to a key it holds, and a per-request proof of possession. In September 2026 the group adopted its first agent-specific document, the AI Identity Management System (AIMS) draft, which treats agents as workloads and composes WIMSE with OAuth. This guide explains the WIMSE building blocks as they stand in the current drafts, how they apply to agents, what is stable enough to design around and what is still moving. It is for identity architects, platform engineers and agent builders. All document statuses were checked on the IETF datatracker on 27 October 2026; every WIMSE document is still an Internet-Draft and can change.

Key takeaways

• Agents are workloads. The WIMSE AIMS draft gives each agent exactly one WIMSE identifier (which may be a SPIFFE ID) and short-lived, key-bound credentials, and treats static API keys as the pattern to move away from.
• Three pieces do the work. A Workload Identifier (URI), a Workload Identity Token (WIT, a JWT binding the identifier to a public key) or an X.509 workload certificate, and a per-request proof: mutual TLS, a Workload Proof Token (WPT) or an HTTP Message Signature.
• Identity is not authority. WIMSE says who the agent is. What it may do on whose behalf still comes from OAuth: delegated access tokens, token exchange, Transaction Tokens and human approval through CIBA.
• Design to the architecture, not to draft details. Header names and claims have already changed between versions (the WPT moved to the Authorization header in -02). Build abstraction around token handling and track the drafts.
• Keep credentials away from the model. AIMS states the LLM must never have access to agent credentials. Put signing keys and token handling in the agent runtime or a sidecar, never in the prompt or tool context.

Where the WIMSE drafts stand

The working group's document list also shows more than a dozen related individual drafts on agent delegation chains, mandates, per-call tool proofs and authorisation evidence. Individual drafts carry no IETF standing until adopted. For the wider picture see the IETF Agent Identity and Authorisation Drafts Tracker; for WIMSE as a general workload architecture see the WIMSE Workload Identity Architecture Guide.

The building blocks

Workload Identifier

• Format: an absolute URI with the trust domain as the authority and a non-empty path, for example wimse://agents.example.com/finance/invoice-agent or a SPIFFE ID spiffe://example.com/agent/invoice. Query, fragment, user information and port are not allowed.
• Rules: each trust domain must coordinate assignment across its issuers; identifiers should be stable and not reassigned to a different workload; an identifier counts as authenticated only when it comes from a verified credential, never from a plaintext header.
• Privacy: the draft cautions that identifiers can reveal topology or naming conventions. Avoid user names or customer names in agent paths.

Workload Identity Token (WIT)

• Format: a JWT with typ wit+jwt (media type application/wit+jwt), signed by the identity server with an asymmetric algorithm; none is prohibited.
• Claims: sub carries the Workload Identifier, exp is mandatory, cnf.jwk holds the workload's public key (with alg), and iss and jti are recommended or optional for audit and revocation.
• Not a bearer token: the workload must prove possession of the matching private key each time it presents the WIT, which travels in the Workload-Identity-Token header, not in Authorization.
• Lifetime: the draft recommends WITs on the order of hours, refreshed regularly, ideally with a new key pair each time, because WITs generally cannot be revoked on demand.

Proof of possession options

For the transport option see the mTLS Guide; for the related OAuth proof-of-possession mechanism see the DPoP Guide.

Applying WIMSE to AI agents

The AIMS draft describes an agent as a workload that loops between a model and external tools, services and resources, and lays out a stack: identifier, credentials, provisioning, authentication, authorisation, monitoring and remediation, with policy and compliance across all of them. The architecture draft adds a section on AI and ML intermediaries that treats agentic systems as delegated workloads that must keep propagated context within the scope of the delegation and re-scope it at each hop.

• One identifier per agent instance class: give each distinct agent (purpose, owner, code version family) its own identifier so logs and policy can tell them apart. Decide whether ephemeral sub-agents get their own identifiers or act under the parent's; AIMS assigns exactly one WIMSE identifier per agent.
• Provisioning with posture: AIMS folds attestation into provisioning as posture assessment that gates issuance, renewal and credential attributes. In practice that means the identity server checks where the agent runs (cluster, node, image digest) before issuing a WIT. See the Workload Attestation Guide.
• Credentials outside the model: the runtime or a sidecar holds the private key and mints proofs; the model only asks for tool calls. This also stops prompt injection from exfiltrating the key.
• Authentication per hop: the agent presents WIT plus proof to each tool or API; mTLS where the path is direct, WPT or HTTP signatures where gateways sit in between.
• Owner binding: the individual draft draft-ni-wimse-ai-agent-identity proposes a dual-identity credential carrying both the agent and its accountable owner, with owner countersignature through agent-mediated, owner-mediated or server-mediated issuance. It is not adopted and its security considerations are still a placeholder, so treat it as a design idea, not a specification.

Identity versus delegated authority

A WIT says "this is the invoice agent in example.com". It does not say "acting for Alice, allowed to approve invoices under 500 pounds". AIMS keeps that in OAuth 2.0, and the pieces fit together as follows.

Multi-hop delegation, where agent A asks agent B to call tool C, is the most active area: several individual WIMSE drafts propose attenuated delegation chains and mandates. Until one is adopted, use token exchange at each hop with narrower scope and audience. See Delegation Chains and Attenuated Authority for AI Agents.

WIMSE compared with what teams use today

Small versus large organisations: a small team running agents on one cloud gets most of the benefit today from cloud workload identity plus vaulted, rotated keys for SaaS. Large estates with many clusters, partners and gateways benefit most from WIMSE's trust-domain model and application-layer proofs, and should pilot with SPIFFE-compatible identifiers so they can move to WIT formats later.

How to implement

1. Inventory agent credentials: list every agent, the credentials it uses, where they are stored and whether the model or tool context can read them.
2. Name a trust domain and identifier scheme: choose a fully qualified trust domain and a path convention per agent; avoid personal data in paths.
3. Stand up issuance with attestation: start with SPIRE or a cloud workload identity service and issue short-lived credentials only to attested agent runtimes.
4. Move secrets out of the model's reach: keys and tokens live in the runtime or a sidecar that signs requests; tools receive results, not credentials.
5. Pick the proof mechanism per path: mTLS inside the mesh; WPT or HTTP signatures through gateways. Wrap it in a library so a draft change is one update.
6. Layer OAuth for authority: exchange for narrowly scoped, audience-bound access tokens per tool call; add Transaction Tokens for internal chains.
7. Pilot in parallel: WIT headers are separate from Authorization in the credentials draft, so they can run alongside existing bearer tokens during migration. Log and compare before enforcing.
8. Enforce and roll back safely: enforce per service once the pilot shows clean results; keep the old credential path disabled but available for one release, and never extend WIT lifetimes to work around issuance failures.

Detection and measurement

• Log: WIT issuance (identifier, attestation result, key thumbprint, expiry), proof validation failures by reason (expired, audience mismatch, wth mismatch, replayed jti or nonce), token exchanges per hop. The WPT draft says raw WPT values must not be logged by default; log hashes or jti.
• Alert: the same identifier presenting from two unexpected locations; proofs signed by a key not in the current WIT; bearer use of a WIT without proof; static keys reappearing for an agent that has moved to WIMSE. Theft and replay map to T1528 Steal Application Access Token and T1550.001 Application Access Token.

Framework mapping

Common failure patterns

• Treating the WIT as a bearer token: accepting it without checking the proof removes the whole point of key binding.
• Trusting identifiers from headers: reading an agent identifier from a plain header or a gateway annotation instead of a verified credential, which the identifier draft explicitly rules out.
• Keys in the agent's context: private keys or tokens passed into prompts, environment variables visible to tools or files the model can read (T1552.001).
• Identity used as authorisation: granting a tool full access because the caller is "the finance agent", with no delegated user context or scope.
• Coding to draft details: hard-coding header names or claim sets from one draft version; the WPT header changed in -02.
• Per-node replay caches only: the HTTP signature draft notes that unshared replay caches let a replay to another cluster member succeed; keep proof lifetimes very short.

Practitioner checklist

• Record every agent's credentials and remove any the model or tools can read.
• Define a trust domain and identifier convention; one identifier per agent.
• Issue short-lived, key-bound credentials only after attestation of the runtime.
• Choose mTLS, WPT or HTTP signatures per path and wrap them in a shared library.
• Use OAuth token exchange for narrow, audience-bound authority per hop.
• Reject WITs without valid proof, and validate the WIT before checking the proof.
• Log issuance and validation without raw tokens; alert on replay and key mismatch.
• Track the WIMSE drafts on datatracker each quarter and update this design note.

Standards and references

• IETF: WIMSE working group documents
• IETF: WIMSE Architecture (draft-ietf-wimse-arch)
• IETF: AI Identity Management System (draft-ietf-wimse-aims)
• IETF: WIMSE Workload Credentials (draft-ietf-wimse-workload-creds)
• IETF: WIMSE Workload Proof Token (draft-ietf-wimse-wpt)
• IETF: WIMSE Workload-to-Workload Authentication with HTTP Signatures
• IETF: Workload Identifier (draft-ietf-wimse-identifier)
• IETF: WIMSE Applicability for AI Agents (individual draft)

Related NHI Mgmt Group resources: Workload Identity Federation Guide · Agent Identity Standards Tracker · AI Agent Credential Lifecycle and Rotation Guide · Agentic AI Identity Guide