AI Agent Identity and Delegated Authorization

AI Agent identity is the set of verifiable identities and relationships that let a system answer: which human or service initiated this task, which Agent definition was selected, which runtime instance is acting, what authority was delegated, and which component performed each effect. One identifier or API key cannot answer all of those questions safely.

The practical design is a chain of distinct principals, short-lived credentials, narrow policy, and durable evidence. The model may choose a next action, but it must not mint its own authority, forward a user's bearer token, or decide that a successful authentication authorizes an object-level operation.

Key Takeaways

• Separate principal, Agent, workload, run, tool, resource, and operation identities.
• An Agent name, manifest, model identity, or Agent Card is metadata until authenticated by a trusted system.
• Prefer short-lived workload credentials over shared API keys and inherited user sessions.
• Preserve delegation rather than silently impersonating the user.
• Bind tokens to an audience and reduce authority at every hop.
• OAuth Token Exchange can express delegation, but policy, revocation, and resource authorization remain deployment responsibilities.
• Treat 2026 Agent-specific WIMSE and transaction-token proposals as work in progress, not deployed standards.

The Identities in One Agent Run

An Agent request often contains several independent identities:

These identifiers must not collapse into a user-controlled string. An LLM saying agent_id=finance-agent does not authenticate a finance workload. A workload certificate authenticates code placement under a trust domain; it does not prove the model's plan is authorized.

Authentication, Authorization, and Delegation

Three questions must remain separate:

1. Authentication: Which principal or workload presented this request?
2. Authorization: May that actor perform this operation on this resource now?
3. Delegation: Which rights did another principal intentionally grant to this actor?

OAuth 2.0 Token Exchange, RFC 8693, defines a security token service interaction that can exchange a subject token and optional actor token. It distinguishes delegation from impersonation and defines the JWT act claim. The RFC deliberately leaves token trust, policy, and many security details to profiles and deployments.

RFC 8707 lets a client identify the target resource so the authorization server can issue an audience-restricted token. The resource answers where the token may be used; scope answers a class of what it may do. Neither answers whether a specific invoice, repository, mailbox, or payment is currently allowed.

The resource server still needs trusted context:

allow =
  verified_issuer
  and expected_audience
  and active_token
  and recognized_workload
  and principal_delegated_this_operation
  and tenant_matches
  and object_policy_allows
  and current_state_allows
  and approval_is_bound_and_unexpired

Workload Identity Is the Foundation

SPIFFE defines workload identities and short-lived SVIDs for dynamic, heterogeneous systems. A runtime can attest a workload and obtain an X.509 or JWT identity without baking a reusable secret into an image.

That solves an important layer: "Which workload is connecting?" It does not define:

• the Agent's task or mission;
• which user delegated authority;
• the exact business object or amount;
• how sub-agents may narrow authority;
• whether an approval is still valid;
• whether a side effect already occurred.

Use workload identity to authenticate the code that talks to the credential broker or resource server. Use application policy and delegated grants to decide what that workload may do.

NIST's 2026 Agent identity guidance makes the same practical point: agents should be first-class entities with their own identifiers and entitlements, while authority remains bound to the user or system operating them. It also warns against credential sharing, static long-lived tokens, broad access, and approval fatigue.

Preserve the Actor Chain

Delegation should preserve both the subject and actor:

• sub: the principal whose authority is represented;
• act: the workload or Agent acting for that principal;
• aud or resource indicator: the intended resource server;
• scope or authorization details: the permitted operation class;
• object and constraints: application-level resource, amount, destination, purpose, and limits;
• run and operation IDs: correlation and replay control;
• expiry, issuer, token ID, and proof key: lifetime and token-use constraints.

At every delegation hop, authority should stay the same or become narrower. A child Agent must not gain a new tenant, resource, tool, amount, destination, or lifetime because a parent copied context into a prompt.

RFC 8693 can carry nested actor information, but it does not by itself enforce strict attenuation. Emerging WIMSE credential-delegation and Agent transaction-token drafts propose more Agent-specific composition and call-chain context. They remain Internet-Drafts as of this article and may change or expire. Use them as design input, pin the revision in experiments, and do not claim generic interoperability.

Broker Credentials Instead of Exposing Them

The safest common pattern keeps reusable credentials outside the Agent:

1. the runtime authenticates to a credential broker using workload identity;
2. it submits the approved operation, target resource, principal context, and run identity;
3. the broker evaluates current policy and delegation;
4. it mints a short-lived audience-bound token or performs the request itself;
5. the resource server validates the token and applies object-level authorization;
6. the system records a result or outcome-unknown state.

This design limits credential theft from prompts, shell history, files, logs, browser storage, and tool output. The Agent sandbox guide describes the execution boundary around that client. The remote MCP OAuth guide covers MCP-specific authorization details.

Sender-constrained tokens such as DPoP can reduce replay after theft, but they do not make the requested operation valid. A stolen proof key, an overbroad token, or a confused resource server still creates risk.

Validate a Delegated Grant

JWT signature, issuer, and algorithm validation should be handled by a maintained identity library. After cryptographic verification, application code must validate the claims against the requested operation. This Go example checks a simplified, already verified grant.

package main

import (
	"errors"
	"fmt"
	"slices"
	"time"
)

type Grant struct {
	Subject   string
	Actor     string
	Audience  string
	Tenant    string
	Scopes    []string
	ExpiresAt time.Time
	RunID     string
}

type Request struct {
	Actor    string
	Audience string
	Tenant   string
	Scope    string
	RunID    string
}

func authorize(grant Grant, request Request, now time.Time) error {
	if grant.Subject == "" || grant.Actor == "" || request.Actor != grant.Actor {
		return errors.New("actor mismatch")
	}
	if request.Audience != grant.Audience {
		return errors.New("audience mismatch")
	}
	if request.Tenant != grant.Tenant || request.RunID != grant.RunID {
		return errors.New("context mismatch")
	}
	if !now.Before(grant.ExpiresAt) {
		return errors.New("grant expired")
	}
	if !slices.Contains(grant.Scopes, request.Scope) {
		return errors.New("scope denied")
	}
	return nil
}

func main() {
	now := time.Unix(1_800_000_000, 0)
	grant := Grant{
		Subject: "user-42", Actor: "agent-runner-7",
		Audience: "https://orders.example", Tenant: "tenant-a",
		Scopes: []string{"orders.read"}, ExpiresAt: now.Add(time.Minute),
		RunID: "run-123",
	}
	request := Request{
		Actor: "agent-runner-7", Audience: "https://orders.example",
		Tenant: "tenant-a", Scope: "orders.read", RunID: "run-123",
	}
	fmt.Println(authorize(grant, request, now))
}

Expected output:

<nil>

Real authorization also checks signature, issuer, token type, token ID, proof-of-possession key, clock skew, revocation, object ownership, action arguments, policy version, approval, and operation state. A scope check alone is insufficient.

Handle Multi-Agent Delegation

Multi-Agent systems add a delegation graph, not just more model calls. For each handoff:

• authenticate the receiving workload;
• calculate an explicit subset of the parent's authority;
• bind the grant to one audience, purpose, run, and expiry;
• cap chain depth and prevent cycles;
• record parent grant and decision identifiers;
• prohibit raw token forwarding;
• revoke descendants when the root authority is revoked;
• require a new decision for a materially changed plan.

Do not paste access tokens into Agent messages. Do not let a planner invent scope strings. Do not infer delegation from a natural-language instruction such as "let the research Agent access everything I can."

Approval and Consent Must Bind to the Action

Human approval is useful only when the reviewer sees the exact operation, object, destination, amount, and consequences. Bind the decision to canonical arguments, policy version, actor, expiry, and one-time operation ID.

An approval dialog every few seconds creates consent fatigue. Use policy to automate low-risk, reversible reads, require focused review for high-impact operations, and deny unsupported actions. The Approval Gate entry covers single-use decisions and time-of-check/time-of-use protection.

Audit Evidence and Revocation

An audit event should make the chain reconstructable without storing reusable credentials:

• principal, Agent definition, workload, run, tool, resource, and operation IDs;
• issuer, audience, effective scope, policy version, and grant lineage;
• approval or autonomous-policy decision;
• normalized argument digest;
• token and decision expiry or revocation state;
• dispatch, downstream result, and reconciliation outcome.

Redact tokens and sensitive arguments. Store a token ID or digest, not the bearer credential.

Revocation must affect future use, queued work, delegated descendants, broker caches, and long-running sessions. Because not every token is introspected on each call, keep lifetimes short and design explicit cancellation and reconciliation paths.

Common Failure Modes

Frequently Asked Questions

Is Agent identity just a service account?

Not necessarily. A service account can authenticate the runtime, but governance often also needs an Agent definition, owner, policy version, run identity, delegated principal, and operation. A single broad service account loses those distinctions.

Can an Agent use OAuth Client Credentials?

Yes for service-owned operations where no human authority is represented. It must not be presented as acting for a user. Limit the audience, scope, lifetime, and resource policy just as you would for any workload.

When should OAuth Token Exchange be used?

Use it when a trusted authorization server can issue a new token for a downstream resource and preserve the intended delegation semantics. Do not use it as a generic wrapper around any incoming token, and never assume the downstream service accepts the resulting claims.

Does proof of possession solve authorization?

No. It can bind token use to a key and reduce replay, but it does not decide whether the key holder may access a tenant, object, amount, destination, or business operation.

What should be stable before adopting an Agent-specific draft?

Pin the exact draft, map each field to stable underlying standards, implement graceful fallback, and run interoperability and security tests. Avoid persisting draft claim names as irreversible business data without a migration plan.

Sources

• NIST: Why Agentic AI Needs a Strong Identity Foundation
• SPIFFE Overview
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8707: Resource Indicators for OAuth 2.0
• WIMSE Credential Delegation for AI Agents, Internet-Draft
• Transaction Tokens for Agents, Internet-Draft