Agents are workloads: auditing WIMSE, WIT-SVID and the AIMS stack

The enterprise identity world has quietly settled the question of what an AI agent is. The answer, per the IETF, SPIFFE and a draft co-authored by AWS, OpenAI and Okta: an agent is a workload. We read every spec in that stack and checked what actually ships.

This is another entry in our primary-source audit series. Same method as our reviews of KYAPay, Web Bot Auth and the ERC-8004 registries: clone the repos, read the drafts, query the registries, and report the gap between what the documents promise and what exists on August 23, 2026.

The subject this time is the workload identity stack: the IETF WIMSE working group (Workload Identity in Multi System Environments), the SPIFFE specification set that implements its token format, and draft-klrc-aiagent-auth — the "AIMS" document that maps all of it onto AI agents. This is the identity layer that enterprises will most likely demand before they let autonomous agents touch production systems. It is worth knowing precisely how finished it is.

The thesis: agents are workloads

At a WIMSE interim meeting on June 3, 2026, Pieter Kasselman of Defakto Security presented the agent authentication draft with a one-line justification recorded in the official minutes: "Agents are workloads - this is why we feel draft is relevant to WIMSE."

This framing does real work. If an agent is a workload, it does not need a new identity system. It needs the one that Kubernetes pods, CI runners and microservices already get: a platform-attested identifier, a short-lived cryptographic credential, and no static API keys. The entire agentic identity conversation collapses into existing infrastructure — SPIFFE IDs, X.509 SVIDs, OAuth token exchange — plus a thin profile on top.

The WIMSE architecture document itself now contains the agent clause. Section 3.4.11 of draft-ietf-wimse-arch-08 (July 6, 2026, 33 pages), titled "AI and ML-Based Intermediaries", classifies AI systems as "a special case of delegated workloads" and issues two normative requirements that read like a checklist for agent platforms: autonomous actions "MUST be clearly distinguished" from delegated ones — for example by separate workload identities or token scopes — and in agent-to-agent chains "each hop in the chain MUST explicitly scope and re-bind the security context." Without that, the draft warns, "a chain of AI-to-AI interactions could unintentionally extend authority far beyond what was originally granted." That is the same multi-hop delegation problem we examined in our SD-JWT delegation chain post, restated by a standards body in MUST language.

The WIMSE census: seven drafts, one about to expire

As of August 23, 2026, the WIMSE working group has six active WG documents plus one submitted to the IESG. The architecture (arch-08), the workload identifier (identifier-03, 13 pages), mutual TLS authentication (mutual-tls-02, 9 pages), HTTP Message Signatures authentication (http-signature-06, 22 pages, refreshed August 4), the credential formats (workload-creds-02, 27 pages, July 2), and the Workload Proof Token (wpt-01, 19 pages). A seventh, workload-identity-practices-06 (August 11), is in AD Evaluation at the IESG on the Informational track.

Two details stand out from the datatracker. First, the proof token and HTTP signature documents are descendants of a single spec — draft-ietf-wimse-s2s-protocol went through versions 00 to 07 before being split. Second, the WPT draft was last touched on March 2, 2026 and expires on September 3, 2026 — eleven days after this post. Drafts get resubmitted routinely and expiry is not death, but it is a freshness signal: the proof-of-possession half of the protocol has gone almost six months without a revision while the credential half iterated.

What a WIT actually is

The core artifact is the Workload Identity Token, defined in WIMSE Workload Credentials (authors from Ping Identity, CyberArk, Defakto, Intuit and Zscaler). A WIT is a JWT with header typ: wit+jwt whose defining feature is the mandatory cnf claim: the workload's own public key, bound into the token by the issuer's signature. The same document defines an X.509 sibling, the Workload Identity Certificate (WIC).

The design decision that separates this stack from nearly every token we have audited in this series: a WIT is not a bearer token, by prohibition. It is only meaningful alongside a proof of possession of the cnf key. The companion WPT draft defines that proof: a second, short-lived JWT (typ: wpt+jwt) signed by the workload's key, carrying aud (the target URI), exp, jti, and a family of hash-binding claims — wth (hash of the WIT), ath (hash of the OAuth access token, if present), tth (hash of the transaction token) and oth (other tokens). The alternative presentation path, draft-ietf-wimse-http-signature, binds the WIT to RFC 9421 HTTP Message Signatures instead — the same primitive Cloudflare's Web Bot Auth uses for crawler identity.

Compare that to the payment-adjacent identity tokens in production today. KYAPay tokens, which we drove end-to-end against Skyfire, are bearer JWTs in a custom header — intercept one and you can spend it. The WIMSE authors dealt with the equivalent risk structurally: steal a WIT and you have a public document; without the private key it authenticates nothing.

SPIFFE's WIT-SVID: merged in July, Incubating, one placeholder link

The formal convergence between the IETF track and the CNCF ecosystem landed on July 1, 2026, when WIT-SVID.md was merged into the spiffe/spiffe standards repo (PR #362, single commit, by SPIRE maintainer Noah Stride). The repo — created August 2017, Apache-2.0, 1,829 stars at audit time — now lists the WIT-SVID beside the X509-SVID and JWT-SVID as a first-class SPIFFE Verifiable Identity Document.

The document is explicitly a sub-profile: "all WIT-SVIDs are WIMSE WITs", not the reverse. The SPIFFE profile is stricter than the upstream draft in ways that reflect operational scar tissue. The kid header is mandatory (upstream: optional) because, as Appendix C admits, go-spiffe and SPIRE already reject spec-compliant JWT-SVIDs without it — "making this a de-facto requirement." The sub must be a SPIFFE ID. The aud claim is prohibited outright. The alg allowlist is pinned to nine RSA and ECDSA values. And the presentation rules are blunt:

// WIT-SVID.md, Section 5 — Token Presentation
The WIT-SVID MUST NOT be presented as a bearer token.
The WIT-SVID MUST NOT be presented using the HTTP Authorization header.

// and the JOSE header every WIT-SVID carries
{ "alg": "ES256", "kid": "lQSi3hZ…", "typ": "wit+jwt" }

The Authorization-header ban has a specific rationale: preventing a WIT-SVID from being swallowed by validators expecting an OIDC bearer token and accepted without proof of possession. The iss claim carries the same defensive rule — if present, it "SHOULD NOT be a value compatible with OpenID Connect Discovery."

The spec is marked Incubating under SPIFFE's STABILITY.md ladder: breaking changes avoided but permitted in response to implementation experience, features "typically gated behind a feature flag." And it ships with an honest loose end: reference [8], the "Best Practices: SVID Type Comparison" document cited twice in the appendices, resolves to the literal URL https://example.com/todo-svid-type-compare. A placeholder in a merged standard is a small thing, but in this series we have learned to read them as maturity gauges — the RSL spec we audited last week had the same tell in grander form.

What ships: SPIRE behind a flag, go-spiffe in exp/

Specs are cheap; shipped code is evidence. We cloned SPIRE (2,496 stars, v1.15.3 released August 21, 2026) and grepped. WIT-SVID support touches 42 files — the CA, the bundle marshaller, the server APIs, telemetry names. It is real, incremental engineering: the changelog records iss-claim support in one release (#6857) and svid.v1 API client support in another (#7132, #7134).

It is also entirely disarmed by default. The feature flag machinery in pkg/common/fflag/fflag.go is explicit:

// FlagWITSVID controls if WIT-SVID and the APIs for it are enabled. When set
// to false all WIT-SVID APIs will return Unimplemented.
FlagWITSVID Flag = "wit-svid"
…
FlagWITSVID: false,

go-spiffe, the reference client library (v2.8.1, June 19, 2026), tells the same story in its package layout: WIT support lives in exp/svid/witsvid and exp/bundle/witbundle — the experimental namespace. One more grep result worth recording: the string "wimse" appears exactly zero times in the entire SPIRE codebase. The implementation tracks the SPIFFE profile, and the IETF lineage is invisible at the code layer.

AIMS: the agent profile, with OpenAI and Okta on the byline

draft-klrc-aiagent-auth ("AI Agent Authentication and Authorization") is where the workload thesis gets applied to agents in normative language. Version -00 appeared on March 2, 2026 with four authors from Defakto Security, AWS, Zscaler and Ping Identity. By version -03 (July 6, 2026, Informational, expires January 7, 2027) the byline had grown to six: Nick Steele of OpenAI and Aaron Parecki of Okta joined. That authorship is itself a datapoint — the company operating the largest consumer agent surface and the company that wrote much of the MCP authorization spec are signing onto the workload framing.

The draft defines AIMS — Agent Identity Management System — as a conceptual model of eight stacked functions, from identifiers at the bottom through credentials, provisioning, authentication, authorization, observability, policy, and compliance at the top. Its sharpest requirements sit in the bottom two layers. An agent "MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID." Credentials "MUST provide a cryptographic binding to the agent identifier," "SHOULD be short-lived," and static API keys are named an antipattern for agent identity. So is token pass-through: "It is an anti-pattern for Tools to forward access tokens it received from the Agent to Services or Resources."

At the June interim, the working group's reception was warm but procedural: no adoption call was issued, chairs opted to gauge interest by email, and participants noted WIMSE "must clear existing work items first." There is a second agent draft in the queue with less momentum: Huawei's draft-ni-wimse-ai-agent-identity-02 ("WIMSE Applicability for AI Agents", February 28, 2026) proposes a "Dual-Identity Credential" cryptographically binding both the agent and its human owner — an idea our KYAPay audit found expressed as the hid/aid claim pair. It defines no concrete claims, requests nothing from IANA, and expires September 1, 2026.

The IANA reality check

As in every audit in this series, we verified the registries the drafts promise to fill. The WIMSE documents request five registrations: media types application/wit+jwt and application/wpt+jwt; HTTP field names Workload-Identity-Token and Workload-Proof-Token; and JWT claims wth, tth and oth.

Checked against IANA on August 23, 2026: the application media-type tree holds 1,795 entries and neither token type is among them. The HTTP field name registry holds 258 entries; neither Workload header appears. The JWT claims registry holds 172 entries; wth, tth and oth are absent. This is expected — registration normally lands at RFC publication, and nothing here is an RFC yet. But it puts WIMSE at exactly the same registry maturity as KYAPay's eighteen unregistered claims and RSL's unregistered media type: a stack that exists in drafts and code, not yet in the namespace infrastructure of the internet. The difference is trajectory — WIMSE is a chartered working group with a document already at the IESG; the others are individual submissions.

The seams: MCP is in, x402 and A2A are nowhere

The most interesting part of any stack audit is the edges. We grepped three protocol repos for "spiffe" and "wimse" on audit day.

The Model Context Protocol repo has four hits, and they are all recent and directional. MCP's official roadmap post, published August 22, 2026 — the day before this audit — commits to "defining an opinionated path for agent identity and delegation through Workload Identity Federation" and to growing engagement "with the IETF OAuth and WIMSE working groups." The concrete vehicle is SEP-1933: Workload Identity Federation — opened December 5, 2025 by PieterKas, the same Pieter Kasselman who lead-authors AIMS. It argues that workloads in "Kubernetes, SPIFFE/SPIRE, and cloud-native runtimes" already hold short-lived attested JWTs and should authenticate to MCP servers with those instead of registering OAuth clients with static secrets. Still open, 38 comments, last updated August 17. It slots beside the ID-JAG machinery we covered in our Enterprise-Managed Authorization audit, and MCP's SEP-1046 (client credentials) already defers its JWT profile to a WIMSE document, draft-levy-wimse-headless-jwt-authentication.

The payments side is the opposite. The x402 repo: zero occurrences of either string. The A2A repo: zero. And the absence is mutual — AIMS mentions MCP once, lists A2A only in its references, and contains zero mentions of x402, payments or stablecoins across all four versions. The workload identity stack and the machine payments stack are being designed in the same twelve months, partly by companies that sit in both rooms, with no normative contact whatsoever.

That matters because the two stacks answer adjacent questions with incompatible mechanics. x402 authenticates a payment: the X-PAYMENT header carries an EIP-3009 authorization whose signature proves control of funds — proof of possession of a wallet key, per request, which is why walk-up-and-pay needs no accounts. WIMSE authenticates a caller: proof of possession of a workload key, per request. Two PoP systems, two key hierarchies, zero binding between them. Nothing today lets a seller assert "this payment came from the workload that presented this WIT" — the WPT's oth claim, hashes of other tokens in the request, is the obvious future hook, sitting in the draft that expires in eleven days.

What it means for LLM4Agents

Enterprise adoption of autonomous agents will arrive wrapped in this stack. When a bank's platform team lets an agent fleet call an LLM gateway, the credential it presents will look like a WIT-SVID from a SPIRE deployment, not a static API key from a dashboard. AIMS names static keys an antipattern in so many words. For a gateway like ours, whose baseline auth is exactly the API-key-plus-wallet pattern, that is a clear medium-term signal: the key ladder we described in our agent threat model eventually needs a rung where a customer's workload identity — not a secret we minted — is the authentication root.

The threat is mostly to the alternative identity rails. If "agent = workload + SPIFFE ID" wins in the enterprise, then bespoke agent-identity registries — the NANDA AgentFacts model, KYA-style identity tokens — compress into the discovery and compliance layers, and the authentication layer defaults to infrastructure enterprises already run. The opportunity is the unbuilt bridge: nobody has specified how a WIMSE-attested workload becomes an x402 payer. A gateway that accepts a WIT for authentication, maps it to a spend policy, and settles per-call in stablecoins would be composing the two halves that the standards bodies have not yet introduced to each other.

Staying on the frontier

Concrete steps, in order. First, accept platform-attested JWTs as an authentication method alongside API keys: validating a customer-issued workload JWT against a configured JWKS is a contained change to the gateway's auth middleware, and it is precisely the pattern SEP-1933 proposes for MCP servers — implementing it early positions our MCP surface for where that spec is heading. Second, bind identity to spend: let an operator pin a wallet's x402 spending policy to a workload identifier, so a leaked API key alone cannot move money — the sub of the attested JWT must match. Third, instrument the seam: log the SHA-256 hash of any workload credential presented alongside an x402 payment, so that when a WPT-style binding claim standardizes, our receipts already carry the join key. Fourth, track three dates — the WPT draft's September 3 expiry (does the PoP half get refreshed?), the AIMS adoption email on the WIMSE list, and SPIRE's release notes for FlagWITSVID flipping to default-true. That flag flip, not any RFC, will be the moment agent workload identity becomes deployable reality.