AI Agent Identity 2026: Authentication & Authorization

Posted on: 6/6/2026 1:13:37 AM

In 2026, the hardest question when shipping AI agents to production is no longer "is the model smart enough?" but "when the agent hits a database, sends an email, or moves money — on whose behalf is it acting, and who is accountable?". This is the problem of identity and authorization for autonomous agents — the quiet infrastructure layer that decides whether a multi-agent system can run safely at all.

If the previous post in this series covered AI agent security from the angle of prompt injection and the Lethal Trifecta, this one goes one layer deeper: the identity of the agent itself — who it is in the eyes of your IAM, how it obtains tokens, and what it is (and isn't) allowed to do.

1. Why does an AI agent need its own identity?

In traditional architectures everything runs as the user (via a session) or as the service (via a static API key). AI agents break both models: they act on behalf of a user while also having the autonomy to call dozens of tools, spawn sub-agents, and run asynchronously long after the user has gone offline. The question "who just deleted this record?" becomes nearly unanswerable if the agent has no independent, traceable identity.

2. Three core problems: Authentication, Authorization, Delegation

Agent identity is not one problem but three tightly-coupled ones. Separating them from the start is the key to a correct design:

The most common mistake is collapsing all three into a single static, all-powerful API key: the agent simultaneously "is" that service account, "may do anything", and "has no idea on whose behalf". When the key leaks — and for agents processing untrusted content, leakage is a matter of time — the attacker inherits that full power.

3. Why agents don't use passwords — two authentication models

AI agents don't type passwords, receive SMS OTPs, or tap passkeys. They authenticate with a federated identity credential or a workload certificate — things a machine can prove, not a human memorizes. There are two access models, and picking the right one per operation is the single most important architectural decision:

graph TD
    U["User"] -->|"delegates"| AG["AI Agent
(own identity)"]
    AG -->|"Model 1:
Delegated / On-Behalf-Of"| R1["Resource with
the USER's permissions"]
    AG -->|"Model 2:
App-only / Workload"| R2["Resource with
the AGENT's own permissions"]
    R1 --> NOTE1["e.g. read the user's email,
create a file in user's drive"]
    R2 --> NOTE2["e.g. write system logs,
call an internal service"]
    style U fill:#e94560,stroke:#fff,color:#fff
    style AG fill:#16213e,stroke:#fff,color:#fff
    style R1 fill:#4CAF50,stroke:#fff,color:#fff
    style R2 fill:#2c3e50,stroke:#fff,color:#fff
    style NOTE1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style NOTE2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50

Figure 1: An agent's two access models — Delegated (borrowing the user's rights) and App-only (the agent's own rights)

Delegated access applies when the agent works for a specific user: permissions are bounded by the intersection of the user's rights and the agent's rights. App-only / workload access is for background work tied to no user. The golden rule: any operation touching a user's data must go through delegated access — never let the agent use "god-mode" system rights to bypass that user's own access controls.

4. OAuth 2.1 for agents: Authorization Code + PKCE

The de-facto standard for an agent to obtain a token on a user's behalf is the OAuth 2.1 Authorization Code Flow with PKCE. Because an agent is a public client — it cannot securely store a client secret — PKCE (Proof Key for Code Exchange) is mandatory, not optional as it was under OAuth 2.0.

sequenceDiagram
    participant U as User
    participant A as AI Agent (client)
    participant AS as Authorization Server
    participant RS as Resource Server (MCP/API)
    A->>AS: 1. Authorize + code_challenge (PKCE)
resource=https://mcp.example.com
    AS->>U: 2. Consent screen
(shows agent identity)
    U->>AS: 3. Approve minimal scopes
    AS->>A: 4. Authorization code
    A->>AS: 5. Exchange code + code_verifier
    AS->>A: 6. Access token (short-lived)
+ refresh token
    A->>RS: 7. Call API with Bearer token
    RS->>RS: 8. Validate aud == self
(RFC 8707 resource binding)
    RS->>A: 9. Result

Figure 2: OAuth 2.1 Authorization Code + PKCE flow for an AI agent

A typical agent token request (step 5) looks like this — note the resource parameter (RFC 8707 Resource Indicators) binding the token to exactly one server, and the PKCE code_verifier:

POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&redirect_uri=https://agent.example.com/callback
&resource=https://mcp.example.com
&client_id=agent-orchestrator

5. Chained delegation: Token Exchange & On-Behalf-Of

Multi-agent systems are rarely flat: an orchestrator calls a sub-agent, which calls a tool-agent... Each hop must answer: "who does this token ultimately represent, and through whose hands?". The answer is OAuth 2.0 Token Exchange (RFC 8693).

Token Exchange lets one party swap an existing token for a new, narrower-scoped one, carrying information about the actor (the party wishing to act on behalf of the subject) via the actor_token parameter. The delegation chain is expressed by nesting the act claim: the outermost claim is the current actor, nested claims are prior actors.

graph LR
    U["User
(subject)"] -->|"delegate"| O["Orchestrator
Agent"]
    O -->|"token exchange"| S["Sub-Agent
(narrower scope)"]
    S -->|"token exchange"| T["Tool-Agent
(single action)"]
    T --> API["Resource Server"]
    style U fill:#e94560,stroke:#fff,color:#fff
    style O fill:#16213e,stroke:#fff,color:#fff
    style S fill:#2c3e50,stroke:#fff,color:#fff
    style T fill:#2c3e50,stroke:#fff,color:#fff
    style API fill:#4CAF50,stroke:#fff,color:#fff

Figure 3: A multi-agent delegation chain — each hop narrows scope and records the actor

The final token's payload carries the full delegation history through nested act claims — exactly what makes "who-acted-for-whom" post-incident auditing feasible:

{
  "sub": "user-8842",
  "aud": "https://mcp.example.com",
  "scope": "files:read calendar:write",
  "act": {
    "sub": "agent://orchestrator-prod",
    "act": {
      "sub": "agent://subagent-scheduler"
    }
  }
}

6. Identity in MCP and A2A

The two foundational protocols of the 2026 agent ecosystem — MCP (agent ↔ tool) and A2A (agent ↔ agent) — both treat identity as a first-class citizen, but differently:

A key design point in the June 2025 MCP spec: the MCP Server acts only as a resource server, never issuing tokens itself but merely validating tokens issued by a dedicated Authorization Server. This separation avoids the "every server rolls its own IAM" anti-pattern — the root of countless vulnerabilities.

7. The vendor landscape: Entra Agent ID and friends

The IAM heavyweights have moved in. In April 2026, Microsoft Entra Agent ID reached General Availability — an identity platform purpose-built for agents, extending Zero Trust principles (authentication, authorization, governance, lifecycle) to non-human identities via the open OAuth 2.0, MCP, and A2A standards.

8. Design principles: least privilege, just-in-time, human gates

Technology is only half the story; the other half is design discipline. Four principles for every production agent:

• Scope-level least privilege: each token carries exactly the scopes for the task at hand. Don't grant admin:* when the agent only needs files:read.
• Just-in-time & step-up: elevate privileges only when needed; tokens expire when the work is done. Sensitive operations trigger step-up authorization.
• Human-in-the-loop as an authorization gate: irreversible actions (moving money, deleting data, sending external mail) must pass human approval — the final authorization layer.
• Make every action traceable: every call carries the agent identity plus the act chain, pushed to an immutable audit log to answer "who did what" after an incident.

9. Conclusion

As AI agents move from demo to production, identity becomes the new security perimeter. An agent with no identity of its own is an agent you cannot trace, cannot scope, and cannot audit — the three minimum conditions for any autonomous system to be trusted.

The good news: we don't need to reinvent the wheel. OAuth 2.1 + PKCE for authentication, RFC 8707 for resource binding, RFC 8693 Token Exchange for delegation chains, the on-behalf-of draft for agent identity on the consent screen, and platforms like Entra Agent ID for governance — the toolkit is ready. What remains is discipline: minimal privilege, short-lived tokens, and humans placed at exactly the irreversible gates. In an era where non-human identities outnumber humans 45:1, this is no longer a nice-to-have — it's a survival condition.

References

• Model Context Protocol — Authorization Specification
• RFC 8693 — OAuth 2.0 Token Exchange
• Microsoft Learn — What is Microsoft Entra Agent ID?
• Microsoft Learn — Authentication protocols in agents
• Descope — Diving Into the MCP Authorization Specification
• NHI Mgmt Group — Identity governance & non-human identities outnumbering humans