# IETF Draft Says an Approval Inside an AI Agent Is Not Enough

_A working group of the Internet Engineering Task Force adopted the AI Agent Authentication and Authorization draft on September 9, 2026. The draft applies OAuth and workload identity to AI agents and says a confirmation inside the agent client does not by itself authorize an action._

By Johannes Keienburg, CEO & Founder  
Published: 2026-09-15  
Source: https://www.cakewalk.security/blog/ietf-ai-agent-authorization-draft

---

## A Click Inside the Agent Does Not Count as Authorization on Its Own

An approval a person gives inside an AI agent client does not by itself authorize the action, according to a draft that a working group of the Internet Engineering Task Force (IETF) adopted on September 9, 2026. The group, Workload Identity in Multi-System Environments (WIMSE), works on how running software proves its identity and gets access. Its draft, [AI Agent Authentication and Authorization](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/03/), defines no new protocol and remains work in progress. It shows how [OAuth](/glossary/oauth) and the group's workload identity specifications address the questions an audit asks about an agent: which agent acted, for whom and under what authorization.

> The final authorization decision remains with the authorization server, and the agent MUST NOT treat local UI confirmation alone as sufficient authorization.

_AI Agent Authentication and Authorization, draft-klrc-aiagent-auth-03, section 10.7_

The draft's [human-in-the-loop](/glossary/human-in-the-loop) section starts from the OAuth authorization server. When that server decides a request needs a person's explicit confirmation, it should decline the request or obtain additional authorization from the person. The agent can request that authorization through OpenID Client Initiated Backchannel Authentication (CIBA), which starts an interaction with the person outside the agent, for example as a push notification to an authenticator app on their phone.

The draft says the agent should turn a person's confirmation into an OAuth authorization event before it accesses protected services. It describes this as aligned with the [Model Context Protocol](/glossary/model-context-protocol) (MCP) pattern in which an agent pauses to ask for confirmation. The authors note that CIBA covers only requests the client starts, which does not map well to confirmation needed mid-task, and that more design work may be needed.

## The Draft Names the Agent and Whoever It Acts For

> Agents MUST be uniquely identified in order to support authentication, authorization, auditing, and delegation.

_AI Agent Authentication and Authorization, draft-klrc-aiagent-auth-03, section 6_

The draft requires that each agent be assigned exactly one WIMSE identifier and hold credentials that expire and are cryptographically bound to it. When a person delegates authorization, the agent obtains an OAuth access token, so it does not need that person's own credentials. The token names the agent in one claim and the person or system it acts for in another.

The receiving service must use both identifiers, along with the token's other claims, to decide whether to allow each request. The draft also requires [tamper-evident audit records](/glossary/audit-trail) that name, among other fields, the agent, whoever it acted for, the action requested with its authorization decision and any revocation with its cause. It does not define the authentication and authorization policy model behind those decisions and leaves it to each implementation, provided it is versioned, reviewable and evaluated consistently. The Agent Control Standard's identity workstream reads this draft as covering token issuance, binding and propagation. It lists last-mile enforcement, whether a decision is enforced on every call, among [five agent identity gaps](/blog/acs-agent-identity-gaps).

> An agent acts on authority a person delegated, which is why we govern the agent through that person. Agents hold no standing access through Cakewalk's MCP Gateway. It checks who delegated each governed call, what the call does and which app it acts on, at the moment the agent makes it. One record holds what was allowed, denied or escalated. Each decision in it traces to the rule that made it.

_Comment from Gil Röder, CPO & Co-Founder_

Source: Internet Engineering Task Force, [AI Agent Authentication and Authorization (draft-klrc-aiagent-auth-03)](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/03/), work in progress, adopted by the WIMSE working group on September 9, 2026.