By Jeff Lombardo

IETF 124, November 2024. Montreal was cold outside, the discussions inside were heated. AI agents were the topic on everyone’s lips, and every working group seemed to be looking at the problem through their own lens. The WIMSE folks were thinking about workload identity. The OAuth crowd was extending grants and tokens. SPIFFE was already deployed in production for service mesh identity. And the Agent2Agent BOF and WebBotAuth WG were trying to address the same topics through their own lens.

The identity community had spent the better part of two decades building a robust, battle-tested toolkit for authentication, authorization, delegation, and observability. OAuth 2.0, SPIFFE, WIMSE, Transaction Tokens, Shared Signals, OpenID Connect. This stuff works. It’s deployed at planet scale. And yet, every new “agent identity” proposal we were seeing started from first principles, reinventing token formats, credential lifecycle, even basic concepts like “what is a workload identity.”

Quickly we sat down with Pieter Kasselman, pointing at the elephant in the room: we don’t have a standards gap. We have an assembly gap. With the support of Brian Campbell, Nick Steele, Yaroslav Rosomakho, and Aaron Parecki, this thinking became draft-klrc-aiagent-auth, now at version -03. A personal Draft that introduces a simple but strong conceptual model called AIMS (Agent Identity Management System).

The thesis: agents are workloads

The core argument is deceptively simple: an AI agent is a workload. It needs an identifier. It needs credentials. It authenticates to other systems. It requests authorization. In short, something the industry has been solving for services, containers, and microservices for years.

Still, what makes agents operationally different is the risk profile:

Dynamic action surface. An agent doesn’t have a fixed API contract. It decides at inference time which tools to call, in what order, based on reasoning that didn’t exist when the agent was deployed.

Cross-domain by default. A single agent task routinely spans internal services, third-party APIs, other agents; each in different trust domains.

Time sensitive and high-churn. Agent instances spin up, fan out, terminate. Some are long lived, running for hours or days, most are short lived, running for seconds or minutes.

High-value targets. An agent with not-contextualized or not-bound credentials is essentially a privileged insider with no audit trail.

What AIMS actually does

AIMS defines a layered stack where each layer is built on guarantees from the one below. There’s no single solution to all of this: it takes a wide range of technologies covering identifiers, authentication, authorization, delegation, and monitoring. What didn’t exist before was the organizing framework that ties them together.

Here’s how it breaks down:

Identifiers. Foundation for everything. The draft proposes WIMSE identifiers (a superset of SPIFFE IDs). A URI that uniquely identifies the agent workload.

Credentials. Authentication and authorization rely on credentials that cryptographically bind identifiers to agents, instead of bare identifiers or long-lived secrets like API keys. The WIMSE credentials specification (X.509 certificates and Workload Identity Tokens) fits well here, along with SPIFFE JWT-SVIDs. Cryptographic proof of ownership of the identifier.

Provisioning. SPIFFE for the general case, while leveraging platform-specific mechanisms (MDMs for end-user posture assessment, cloud-native posture evaluation) depending on where the agent runs.

Authentication. Agents authenticate to LLMs, tools, services, resources, other agents. The draft maps WIMSE credential mechanisms with mTLS at the transport layer and HTTP Message Signatures, WIMSE Proof Tokens at the application layer. The through-line: avoid static pre-shared credentials, it’s an anti-pattern.

Authorization. Specifically, delegated authorization through OAuth. What an agent can access, whether it’s acting on behalf of a user or on its own, how end-users authorize agents to act on their behalf. The draft maps the existing OAuth specs to specific agent use cases: authorization code flow for delegated user flows, client credentials for autonomous agents, token exchange scope and authorization details management, identity chaining via ID-JAG for multi-domain workflows and leaves a space for policy based authorization which may be facilitated through AuthZEN and other policy based authorization standards

Observability and Remediation. Risk evaluation changes. Authorization may need to change mid-session. How do you propagate that? The OpenID Foundation’s prior work here is directly applicable: Shared Signals Framework (SSF), CAEP for continuous access evaluation, RISC for account-level signals. Audit critical details, revoke credentials, trigger re-evaluation.

Policy and Compliance. What are the rules? How do you measure against them? This is inherently deployment-specific. The draft deliberately doesn’t point to any single policy standard here, leaving room for organizations to fit their existing infrastructure in.

Every single component in that stack is either an existing RFC, a mature IETF draft, or an OpenID specification that’s already deployed in production somewhere. The draft doesn’t define any new wire protocol. It profiles and composes.

The constraints that motivated us

Through this work, we set ourselves a few constraints early:

If it exists and works, use it. Don’t reinvent credential formats. Don’t create yet another token type. Don’t define a new discovery mechanism when OAuth Server Metadata and Protected Resource Metadata already exist.

If something is genuinely new, call it out as a gap. The draft explicitly identifies areas where profiles, extensions, or new work is needed. Human-in-the-loop mid-execution authorization is one: CIBA gets close but the message flow and client initiation model don’t map well to an agent needing approval during execution, not before. That gap has already produced a new draft (more below). Cross-domain use of transaction tokens is another. Dynamic client relationship management proved DCR was not the end goal, the emergence of CIMD was helpful.

Don’t solve the deployment architecture. AIMS is a conceptual model, not a product spec. It might be one component or distributed across identity providers, authorization servers, policy engines, and runtime enforcement points. That was intentional as it has to map to real deployments that already look different from each other. 

The ecosystem is moving

This is the part that gives me optimism. The framework isn’t just a document; it helped catalyzing focused work on the specific areas where profiles and extensions are genuinely needed. It proved people aren’t reinventing but they’re extending precisely where the existing tire doesn’t fit the road.

The market started validating the thesis of the draft independently. Sean O’Dell, Distinguished Engineer at CVS Health and now a co-author on the Transaction Token Chaining Profile, published “You Already Have the Pieces. Now Build It.” on The Identity Underground. It’s worth reading in full. He opens with the same observation we built the draft around.

OpenAI, Anthropic, and Snowflake have all shipped Workload Identity Federation endpoints  using OIDC and SPIFFE-style credentials to authenticate workloads against their platforms without static API keys. This is literally the AIMS model landing in real systems. The theory is catching up to what practitioners are already doing, and vice versa.

Finally, new proposals have come out of this work:

OAuth Transaction Authorization Challenge by Yaroslav Rosomakho, Brian Campbell, Karl McGuinness, and Pieter Kasselman tackles head-on the human-in-the-loop gap we identified. CIBA’s message flow doesn’t map well to mid-execution approval as it’s client-initiated, not resource-driven. This draft flips it: the protected resource issues a signed challenge when a specific operation requires additional authorization; the agent relays the challenge to a client, which presents it to an authorization server that obtains approval and issues a transaction-scoped access token. It reuses OAuth’s existing capabilities.

Transaction Tokens for Agents by Ashay Raut extends the Transaction Token specification with agent-specific semantics through the act claim for identifying the agent performing the action, and an agentic_ctx claim for conveying operational constraints relevant to authorization, auditing, and policy evaluation within the service graph.

Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining by George Fletcher, Pieter Kasselman, and Sean O’Dell defines how a Transaction Token scoped to a single trust domain can be used as an authorization grant to obtain a JWT Authorization Grant for crossing a trust boundary. This is what makes cross-domain multi-agent workflows practical without requiring every authorization server to trust every other one directly.

WISE: Workload Identity Security Events by Dag Sneeggen, Sean O’Dell, Pieter Kasselman, and myself profiles the Shared Signals Framework for workload identity lifecycle events. SSF, CAEP, and RISC solved the human identity signal story, and WISE extends the same asynchronous event model to workloads: credential rotation, trust revocation, posture changes, and the security state transitions that arise when agents act on behalf of humans, on behalf of other agents, or autonomously. It builds on RFC 8417 (SET), the WIMSE identifier and credential specifications, and the CAEP Interoperability Profile patterns.

All of these are exactly the kind of focused, incremental work that the AIMS framework was designed to surface as missing.

What this means for practitioners

If you’re an identity architect or an IAM practitioner reading this, here’s the takeaway: you already have most of what you need to secure agentic workloads. The standards are written. The protocols are mature. What’s been missing is the map showing how they connect as well as the clarity on where the gaps actually are.

That’s what AIMS provides. And where the map shows blank spots, the community is filling them in with targeted, interoperable specifications rather than competing greenfield stacks.

We’re heading into IETF 126 in Vienna later this month. The AIMS draft is already shaping the standards landscape. I expect to have more exciting updates as those meetings wrap up. In the meantime, the pieces are on the table. Time to assemble.

About the Author

Jeff Lombardo is a Principal Identity Specialist at AWS based in Montreal. He contributes to IETF and OpenID Foundation work on identity architecture for agentic systems. The views expressed here are his own.