Resolving the AI Agent Identity Crisis: Many Standards, One Direction

Oct 09, 2026
9 minutes

When an AI agent calls a payment API, deploys code, or hands work to another agent, a valid access token answers only part of the security question. The harder question is what constitutes that agent’s identity in the first place. Is it the code being executed? The underlying model? The runtime instance? The credential it presents? The person it acts for? The intent of its current task?

The answer is all of the above. 


Key Takeaways:

  • Securing a multi-faceted AI agent identity requires cryptographically binding its code, model, runtime, task intent, and delegating user into an attestable credential.
  • Organizations can adopt durable requirements today (like zero standing privileges, or ZSP,  short-lived tokens, and human step-up approvals) without waiting for standards to settle.
  • Security teams can unify governance with Idira by deploying it as an agent identity broker over existing OAuth and Secure Production Identity Framework for Everyone (SPIFFE) infrastructure.

The real identity crisis is that agents have several identities at once. The industry has yet to converge on a consistent way to represent and bind them.

An Eventful Year for an AI Agent Problem Still Taking Shape 

If you've tried to follow the standards work around AI agent identity and security lately, keeping up with the acronyms is a full-time job. The past year brought new OWASP guidance, CoSAI research on agentic identity and access management, or IAM, and a dedicated OpenID Foundation community group. It also brought IETF workload-identity drafts, the ODIS interoperability spec, and a NIST concept paper on agent identity and authorization. There may be more by the time you read this.

Agents are gaining access to business-critical systems and sensitive data faster than the industry can agree on how to identify them. Our team participates in several of these efforts, and we can report that even the people writing the specs are still making sense of it all.

Agents moved from pilots into production faster than the standards community could coordinate, so security groups, identity bodies, coalitions, and governments all started at once.

Different AI Agent Security Standards Address Different Layers 

The efforts below can look like competing standards. They are not six answers to the same question. Different communities are filling different layers of one architecture, from workload identity and delegation to application security, interoperability, and enterprise implementation:

  • OWASP's Securing Agentic Applications guide spans agentic application security across architecture, tooling, and operations. It includes identity-relevant guidance on permission boundaries, ephemeral access, agent authentication, and policy enforcement; version 2 is underway.
  • The Coalition for Secure AI (CoSAI), in its Agentic IAM paper, lays out an enterprise model built on first-class agent identities, ZSP, delegated authority, lifecycle management, and audit.
  • The OpenID Foundation's Artificial Intelligence Identity Management community group is working through where AI agents strain existing identity standards, from agent discovery and identity assertion to delegation and the tokens exchanged between agents. Its whitepaper surveys the problem.
  • The IETF’s Workload Identity in Multi System Environments (WIMSE) working group is standardizing workload identifiers and cryptographically bound tokens for workload-to-workload authentication, within and across trust domains. Its AI Identity Management System (AIMS) draft composes WIMSE, SPIFFE, and OAuth into a framework for agent authentication and authorization instead of defining another protocol. 
  • ODIS (Open Delegation and Identity Standard) is a draft interoperability specification for agent identity, scoped delegation, revocation, and audit context in agent engagements. It is being developed in a CoSAI workstream.
  • NIST's National Cybersecurity Center of Excellence project on software and AI agent identity explores how existing identity standards can be combined in practical enterprise implementations, alongside the broader AI Agent Standards Initiative's support for industry-led standards and open protocols.

These efforts sit at different levels of maturity, from published guidance to early drafts. But read them side by side and the striking thing is not where they differ, but how much they agree. Composition, not consolidation, is how this comes together: combining complementary standards into an architecture that can adapt as they evolve. Enterprises should build for that evolution rather than commit prematurely to one ecosystem. The shared principles offer a security model you can use today, without waiting for final documents or industry consensus.

The shared principles offer a security model you can use today, without waiting for final documents or industry consensus.

One Direction: Attestable Agent Identity, Bounded Authority 

Agent identity should be attestable: a relying party should be able to cryptographically verify which workload is presenting a credential, not just trust possession of a secret. Think workload attestation, not an API key sitting in an environment variable. Credentials should be short-lived and audience-bound. And when an orchestrator delegates to a sub-agent, or exchanges a token for a downstream service, authority should only narrow: fewer operations, a shorter duration, a lower transaction limit, or stronger approval conditions. Never wider.

Prompt injection turns an agent into a confused deputy, a failure mode the security world named back in 1988. Identity controls won't prevent that, but they can cap the blast radius. A payment API can still reject an unapproved supplier, and a tool can still deny an out-of-scope operation, no matter how convincingly the agent asks.

What We Recommend

Don't make your security architecture depend on one standard winning. Adopt the durable requirements today, and keep the representations underneath modular. Every item below is called for by multiple initiatives above:

  1. Discover Your Agents. Associate each with an owner, purpose, lifecycle state, capabilities, and access paths.
  2. Treat Agents as First-Class Identities. Don't hide them behind service accounts several agents share, or behind a human's credentials, because neither leaves an attributable actor. Give each agent its own identity and represent its distinct facets: the logical agent and its version, the code and underlying model, the runtime instance, the current task and its intent, and the delegating principal. These are layered: an attested workload identity anchors the runtime instance, and the agent-specific facets are bound on top of it.
  3. Eliminate Standing Privilege. Keep secrets out of model context; broker task-scoped, ephemeral access instead.
  4. Enforce Policy at Every Hop. Never assume an upstream check happened; re-evaluate authorization at each boundary, all the way to the final tool or resource.
  5. Gate High-Risk Actions on Human Approval. For payments above a threshold, production deployments, or bulk data exports, require step-up confirmation so that even a manipulated agent can't complete them alone.
  6. Monitor Behavior and Preserve the Audit Trail. Baseline what each agent normally does, flag deviations from its declared task, log enough to reconstruct who authorized which agent instance to do what, and keep a fast path to disable an agent and its credentials.

Where each one is called for:

Recommendation OWASP CoSAI OpenID WIMSE ODIS NIST
Discover your agents ✓ ✓ ✓
First-class identities ✓ ✓ ✓ ✓ ✓
Eliminate standing privilege ✓ ✓ ✓ ✓ ✓ ✓
Enforce at every hop ✓ ✓ ✓ ✓ ✓
Human approval on high-risk ✓ ✓ ✓ ✓ ✓
Monitor and audit trail ✓ ✓ ✓ ✓ ✓ ✓

None of this requires exotic new infrastructure. The agent-specific work is being built on foundations you already have, such as OAuth 2.0, OpenID Connect, and SPIFFE. NIST puts it plainly: today's established IAM standards are “the foundation upon which we will build the secure and scalable agentic protocols of the future.” 

SPIFFE was built for workload identity, and an AI agent is a type of workload. Giving each agent a workload identity unlocks the machine-identity tooling you already run for secrets management and just-in-time access. Keep the evolving agent-specific formats behind adaptable interfaces rather than hard-coding them into every application

OAuth has extensions in progress to address emerging problems , from identity chaining across trust domains and its ID-JAG profile for cross-app access, to a challenge that lets a protected resource verify a human really approved an action.

Workload identity anchors agents; delegation and policy govern access, with audit and revocation throughout.

Building in the Open: Idira’s Approach to Agent Identity 

At Idira, we participate in the work and discussions across these initiatives and related communities, and the exchange runs in both directions. Into the standards rooms we bring what we see in enterprises running heterogeneous identity, security, and application environments: how granular agent identity needs to be, how delegation and revocation should work, what audit lineage must survive, where interoperability breaks.

Out of them, we bring the converging principles into what we build. They are the same principles behind Idira's Discover, Control, Govern approach: Find agents and their access paths, provide bounded privilege through an agent identity broker, manage lifecycle and revocation, and preserve the chain from the initiating human through the agent to the tool or resource. 

Our aim is to provide an adaptable identity layer, so you don't have to track every draft or redesign as each spec matures. That layer is where a mature identity security platform earns its place.

When evaluating an agent identity platform, look for an architecture that can incorporate standards as they mature. Adopt the principles now. Use open standards where they are mature. The standards will take years to settle. The principles don't have to wait. 

Ready to put these principles into practice? Explore how Idira helps you discover, control, and govern AI agents.


FAQs

What is AI agent identity and why is it different from traditional machine identity?

AI agent identity includes the agent’s workload identity and context such as its code, underlying model, runtime instance, current task, and delegating principal. An attested workload identity anchors the runtime instance, with agent-specific context bound on top..

How does prompt injection impact AI agent identity security?

Prompt injection acts as a "confused deputy" attack, manipulating an authenticated agent into executing unauthorized tasks. Robust identity controls mitigate this risk by enforcing zero standing privilege, task-scoped audience tokens, and step-up human approvals for high-risk operations.

Can enterprise teams implement AI agent governance using existing OAuth and SPIFFE infrastructure?

Yes. Standard protocols like OAuth 2.0, OpenID Connect, and SPIFFE serve as foundational layers. Identity platforms like Palo Alto Networks Idira build upon these standards to broker ephemeral, task-scoped access without requiring complete infrastructure overhauls.