What IETF WIMSE, OAuth, and OWASP Actually Say About Agent Authorization - And What They Leave Out

The standards landscape for AI agent authorization is active, genuinely productive in places, and widely misrepresented by vendors who cite standards bodies to lend credibility to products that those bodies have not actually endorsed.

This post is an attempt to give an honest account of where the major standards efforts currently stand, what they have actually committed to paper, and where the gaps are. The gaps are not criticism of the bodies doing the work — standards take time, and the problem is genuinely hard. They are information for practitioners making architectural decisions today.

IETF WIMSE: Workload Identity Done Properly

The IETF WIMSE working group — Workload Identity in Multi System Environments — is the most concrete and most practically useful standards effort in the adjacent space. It is chartered to evolve SPIFFE concepts into IETF standards-track documents, covering workload identity across cloud, multi-tenant, and cross-trust-domain deployments.

As of early 2026, the active WIMSE drafts include an architecture document, a workload credentials specification, a workload identifier format, a mutual TLS profile, and a workload identity practices document. The architecture draft explicitly includes AI agents as a use case, which is meaningful — it establishes that the working group considers agent identity within scope.

What WIMSE defines: cryptographically verifiable workload identity. A workload — including an AI agent — can receive a short-lived credential that proves its identity to other workloads without relying on shared secrets or long-lived API keys. This is exactly the right infrastructure for the authentication layer of agent-to-agent communication.

What WIMSE does not define: delegation authority. WIMSE tells you that this credential belongs to this workload. It does not tell you what authority that workload holds, how that authority was derived from a human originator, or whether the workload is permitted to delegate authority to another workload. The identity and authority questions are separate, and WIMSE is solving the identity question.

There is also an open question in the community about how AI agent identity maps to WIMSE primitives. WIMSE was designed for static, long-running workloads. An AI agent session is potentially short-lived, context-dependent, and may involve dynamically spawned sub-agents. Whether a sub-agent gets its own WIMSE identity, whether it inherits from its parent, and how long-lived that identity should be — these questions are not answered in the current drafts and are the subject of active community discussion.

For practitioners: WIMSE is worth adopting for the authentication layer. Treat it as a complement to agent authorization infrastructure, not a substitute for it.

OAuth: One Hop Forward, Multi-Hop Gap

The OAuth working group has produced two relevant drafts for agent authorization.

The primary draft — on-behalf-of user authorization for AI agents, currently at version 02 — builds on RFC 8693 (OAuth 2.0 Token Exchange) to introduce a requested_actor parameter in authorization requests and an actor_token in token requests. This handles the single-hop case: a user authorizes an agent to act on their behalf, and the agent receives a token that carries the user's delegated authority.

This is useful and correctly specified. The single-hop case is the most common deployment pattern today, and having a standardized way to represent it in OAuth flows is a real contribution.

The gap is multi-hop chains. RFC 8693's act claim can represent nested actors, but it treats prior actors as informational rather than enforced. There is no normative requirement that authority narrows at each hop, no cryptographic binding between the parent authorization and the derived one, and no specification for how a downstream participant verifies that the chain is valid rather than forged.

A second OAuth draft proposes an optional target_id field for more granular authorization within a single flow. A third draft describes a framework for AI agent networks anchored in OAuth. Neither addresses the cross-hop authority enforcement problem.

The honest characterization: OAuth is converging on the right primitives for single-organization, single-hop agent authorization. It is not yet solving the multi-hop, cross-organizational delegation problem that is the hardest part of the space.

For practitioners: OAuth-based authorization is the correct choice for the user-to-agent delegation layer. Do not expect it to solve the agent-to-agent layer without additional infrastructure.

OWASP GenAI Security: Threat Taxonomy Without Protocol

The OWASP GenAI Security Project is the most operationally active body in this space, and the most likely to influence actual procurement decisions. Practitioners trust OWASP. Security teams use its output in vendor evaluations. This makes its framing consequential.

OWASP's output splits across several artifacts.

The Top 10 for LLM Applications, now at version 2.0, covers the threat landscape for LLM-powered applications. The entry on Excessive Agency covers the case where agents take unauthorized actions. The mitigations it recommends are principle of least privilege and human oversight — correct in direction, underspecified in mechanism.

The Top 10 for Agentic Applications, released in late 2025, is more directly relevant. It names ten threat categories specific to agentic systems, including unauthorized capability acquisition, unsafe agent delegation, and rogue agents. It is a useful taxonomy. It is not a protocol specification — it identifies what can go wrong without specifying the cryptographic infrastructure needed to prevent it.

The Securing Agentic Applications Guide is the most architecturally substantive OWASP output for this space. It takes a clear position on several questions that matter:

It states explicitly that authorization decisions need to be deterministic and auditable, and that "the model said it was fine" satisfies neither requirement. This is a direct validation of the declared-intent architectural position over LLM-based intent inference.

It notes that chain-of-thought reasoning is unavailable, hidden, non-deterministic, or unsafe to expose — making it an inappropriate basis for authorization decisions. This is the OWASP position on intent classification as a primary security control.

It describes verifiable agent identity as a directional next step and explicitly looks forward to decentralized identity registries for cross-internet agent traffic.

OWASP AIVSS — the AI Vulnerability Scoring System — is in active development, with version 0.8 released in early 2026 and version 1.0 expected by end of year. AIVSS provides a quantitative scoring framework for agentic AI security risks with axes covering untraceability, tool misuse, identity impersonation, memory manipulation, and goal manipulation. When version 1.0 ships, it will likely become the basis for how enterprise security teams score agent-related risks in vendor evaluations.

For practitioners: OWASP is building the vocabulary and threat taxonomy that will define how your security team talks about agent authorization. Align your architecture to the OWASP framing now, before the procurement conversations happen.

DIF Trusted AI Agents Working Group: The Decentralized Identity Layer

The Decentralized Identity Foundation launched a Trusted AI Agents Working Group in 2025, with its first work item being Agentic Authority Use Cases. The working group's scope explicitly covers MCP, A2A, and other agentic protocols, positioning DIF as the body for agent identity standards built on W3C DIDs and Verifiable Credentials.

The most concrete output so far is Know Your Agent OS, a specification donated by Vouched to DIF in early 2026. KYA-OS is being developed as a DID-anchored identity and delegation layer that aims to work across the full range of agentic protocols rather than being specific to any one.

The DIF approach is architecturally distinct from the IETF and OAuth approaches in one important way: it is decentralized by design. Identity is anchored in DIDs rather than in centralized identity providers. This is the right architecture for cross-organizational agent delegation, where no single centralized authority is trusted by all parties. Whether DIF's output will achieve the adoption needed to become the canonical standard is an open question.

For practitioners: DIF's work is worth following closely, particularly for architectures that involve cross-organizational agent delegation without pre-established trust relationships between organizations.

A2A: Transport Protocol, Not Authorization Protocol

The A2A protocol, contributed by Google and now under Linux Foundation governance, is the most widely discussed protocol in the agent communication space. It is important to be precise about what it is and is not.

A2A defines how agents communicate — message formats, task states, streaming, push notifications, and the Agent Card format for capability discovery. It does so well. The protocol is well-designed for its purpose.

What A2A explicitly does not define is authorization. The specification states this directly: identity information is not transmitted within A2A JSON-RPC payloads; it is handled at the HTTP transport layer. Authorization logic is described as implementation-specific. The A2A Agent Card lists an agent's capabilities but does not define typed I/O schemas, permission models, or authority boundaries at the skill level.

This is not a criticism of A2A. The protocol made a deliberate scoping decision to leave authorization out of scope and let implementations handle it. What it means for practitioners is that deploying A2A does not give you agent authorization — it gives you agent communication. The authorization layer is something you add on top.

The agent security community has recognized this gap. A proposal called the Open Agent Passport has been submitted to the A2A working group as a protocol extension specifically to address pre-action authorization. The proposal defines an agent passport as a signed credential that binds an agent's identity to its authorized capability scope, and proposes it as a required field in A2A messages. This proposal has not been adopted into the spec but represents the direction the community is moving.

For practitioners: A2A is a solid foundation for agent communication. Do not mistake it for an authorization solution.

What the Gap Looks Like In Aggregate

Mapping across these bodies, the gap in the current standards landscape is specific and consistent. Every body has addressed identity or authentication or threat taxonomy. None has produced a complete, normative specification for:

Cross-organizational agent delegation with cryptographic authority binding that narrows monotonically through a multi-hop chain and can be verified by any downstream participant without contacting a centralized authority.

This is not a gap that any single body is close to closing. WIMSE gets the identity layer right. OAuth gets the single-hop delegation layer mostly right. OWASP gets the threat taxonomy right. DIF is working on the cross-org identity layer. A2A gets the communication layer right. None of them, individually or in combination as currently specified, produces the multi-hop, cross-organizational, cryptographically verifiable authority chain that robust agent authorization requires.

Where CapiscIO Sits

CapiscIO is not trying to compete with any of these bodies. The RFC stack we have published is designed to be composable with the standards that are emerging: WIMSE for workload identity, OAuth for user-to-agent delegation, A2A for agent communication, OASF for capability declaration, DIF for decentralized identity anchoring.

What we have specified that none of these bodies have is the layer that connects them: the Authority Envelope chain that cryptographically binds authority from originator to action, the monotonic narrowing semantics that enforce the authority-only-shrinks invariant across hops, the capability binding registry that makes capability class enforcement deterministic, and the pre-authorized action manifest that declares an agent's permitted action surface before it runs.

We publish these as open RFCs because the right outcome for the industry is a standard that multiple implementations can conform to, not a proprietary solution. The A2A working group is the most likely venue for these primitives to eventually be ratified. We are engaging with that process.

In the meantime, the standards gap is real and it is consequential for any enterprise deploying multi-agent systems today. Understanding precisely where the current standards stop is the prerequisite for understanding what additional infrastructure you need.