AI agents are starting to look less like tools and more like participants.
They don’t just respond to prompts.
They take actions, call APIs, orchestrate workflows, and, in some cases, make decisions on behalf of users or other systems. As that shift happens, a fairly basic question moves to the foreground:
How do you authenticate and authorize something that acts, but isn’t a human?
The Internet Engineering Task Force (IETF) has started to explore that question in a recent Internet-Draft, “AI Agent Authentication and Authorization” (draft-klrc-aiagent-auth). Like most early drafts, it’s not trying to settle the debate. But it does introduce a useful concept —AIMS (Agent Identity Management System) — which is worth understanding if you’re building or thinking about agent-driven systems.
A Draft, Not a Standard
Before getting into AIMS itself, let’s be clear about what this document represents.
It is an IETF “Internet-Draft,” which means it is an early contribution rather than a finished standard. It hasn’t gone through full working group consensus, and it may change significantly—or never become an RFC at all. The current revision (-01) was only published recently, so the ideas are still forming.
This document is important. Drafts like this are often where the industry starts to agree on a shared language and direction. They’re better seen as signals about where things are heading, rather than rules set in stone.
Agents as Workloads
One of the more significant aspects of the draft is how it frames the problem.
Rather than inventing a new identity model, it leans on something we already understand: workload identity.
In this view, an agent isn’t treated like a user with a session and a UI. It’s treated more like a service or a process — something that has its own identity, uses machine credentials, and participates in programmatic authentication and authorization flows.
That may sound obvious, but it matters in practice. It treats agents more like services or containers, rather than trying to adapt user-centric identity models that don’t translate well.
What AIMS Is
AIMS isn’t a product or a protocol. It’s more of a reference model for how all the pieces of agent identity fit together.
The draft uses AIMS to describe a system that issues identities to agents, proves something about how those agents are running, provides credentials they can use to authenticate, and evaluates whether they’re allowed to take specific actions. It also assumes there are enforcement points somewhere in the system — APIs, gateways, services — that actually make those decisions matter.
If that sounds broad, it is. AIMS is meant to capture the entire identity and access stack for agents, not just the initial authentication step.
What’s notable is that the draft doesn’t try to define each of these components from scratch. Instead, it leans heavily on existing standards — OAuth for delegation, established credential formats such as JWTs and certificates, and emerging workload-identity approaches. The goal seems to be to compose something coherent from familiar building blocks rather than to introduce yet another parallel stack.
The Model
The draft proposes a remarkably grounded architecture — especially if you’ve spent any time working with modern workload identity.
The lifecycle is simple: An agent is issued an identity and a short-lived, verifiable credential. Authentication happens via standard mechanisms — think transport security and token-based proofs. When that agent needs to access a resource, it presents a scoped token that defines its specific rights, often carrying delegated authorization when acting on behalf of a human user.
At runtime, an access management system evaluates that request in context: who the agent is, what it’s trying to do, and under what conditions. Access is granted — or not — based on that evaluation.
There isn’t anything especially exotic here. In many ways, that’s the point. The draft is effectively saying: we already have most of the machinery — we just need to apply it consistently to this new class of actor.
Why This Is Coming Up Now
The timing of this work isn’t accidental.
A lot of early agent implementations rely on patterns that don’t scale well: long-lived API keys, shared credentials, or loosely defined identities. Those approaches are expedient, but they create obvious problems when agents become more autonomous or interact with multiple systems.
The draft calls out this fragmentation directly. Without some shared approach, different ecosystems are likely to reinvent incompatible models, making interoperability and security harder than they need to be.
AIMS is an early attempt to provide a common frame before things diverge too far.
What’s Still Fuzzy
For all its usefulness as a reference model, the draft leaves quite a bit unresolved. That’s not surprising given its stage, but it’s where most of the interesting questions are.
One area that feels underdeveloped is authorization beyond the token. The draft does a reasonable job describing how an agent might obtain credentials or delegated access, but it’s less specific about how complex, dynamic policy decisions should be made at runtime — especially in environments where context changes rapidly.
For example, should an agent be allowed to access a sensitive API only if it’s running in a trusted environment, during business hours, and on behalf of a specific user action? Those kinds of context-dependent decisions aren’t well defined.
Related to that is the question of multi-agent delegation. It’s one thing for an agent to act on behalf of a user. It’s another for chains of agents to act on behalf of each other, passing context and authority along the way. The draft acknowledges this, but the mechanics — and the limits — are still evolving.
There’s also a practical concern around operational complexity. AIMS, as described, assumes the presence of identity providers, attestation systems, token services, and policy engines, all working together. That’s consistent with how modern identity systems are built, but stitching those pieces together in a real environment is not trivial.
Finally, the draft is deliberately scoped. It goes deep on identity and access for agents, but stops short of adjacent concerns like data handling, prompt security, or model behavior. Those areas are clearly relevant—and often intertwined in practice—but they fall outside the boundaries of what AIMS is trying to define.
How to Read This as a Practitioner
If you’re building systems with agents today, AIMS is more valuable directionally than in its specific details.
It reinforces the idea that agents need first-class identities, not borrowed or implicit ones. It assumes that credentials should be short-lived and scoped, rather than static. And it treats delegation — especially acting on behalf of users — as a core capability rather than an edge case.
Just as importantly, it suggests that the industry is trying to converge on shared patterns built on existing standards, rather than fragment into entirely new approaches.
A Useful Snapshot, Not a Final Answer
It’s too early to say what parts of this draft will stick, or whether AIMS will become a widely adopted model. But it’s a useful snapshot of how people are currently thinking about identity for autonomous systems.
If nothing else, it highlights a shift that’s already underway:
- We’re no longer just authenticating users. We’re authenticating actors.
- And those actors don’t behave like anything traditional IAM was designed for.
AIMS is one attempt to bridge that gap.
