Agent Identity, Authorization & Payments

Parent: AI Agent Ecosystems · researched 2026-06-03T23:02:42.930Z· 42 sources · 12 concepts · skill agent-identity-authz-payments

The trust / permission / value layer for autonomous AI agents acting with

Agent Identity, Authorization & Payments

The trust / permission / value layer for autonomous AI agents acting with [source]
delegated authority. When an agent can browse, call tools, move data, and [source]
spend money on a user's behalf, three questions must be answered before it acts: [source]
Who is this agent? (identity), **What is it allowed to do, for whom, and for [source]
how long? (authorization), and How does it pay, within what bounds, with what [source]
audit trail?** (payments). This skill is the agent-specific answer to all three. [source]
It is current to mid-2026 and is explicit about what is a ratified standard, a [source]
draft, a vendor GA, or an announcement - this area is moving fast and much of it [source]

When to use / Skip

Use this skill when you are: giving an agent its own identity distinct from [source]
the user's; wiring OAuth 2.1 on-behalf-of / token-exchange delegation; issuing [source]
scoped least-privilege short-lived tokens; figuring out how an agent gets [source]
authorized to call MCP servers; evaluating non-human / agentic identity [source]
vendors; standing up a token vault / credential broker; adding human-in-the-loop [source]
approval; or letting an agent transact with spend caps, mandates, and an audit [source]
**General human / workforce / workload IAM, and the Okta identity platform [source]
itself** (Identity Engine, OAuth/OIDC auth-server config, management APIs, [source]
federated SSO/SAML, posture) -> okta-expert. This skill assumes an IdP [source]
exists and focuses on the agent layer on top of it. [source]
Building an MCP server (server scaffolding, tool design, transports, [source]
packaging, the SDK) -> mcp-builder. This skill covers only how an *agent [source]
(the MCP client side) obtains and presents authorization to call* MCP [source]
servers, and the resource-server contract it must satisfy - not how to author [source]
Web-crypto / vault code review -> webcrypto-vault-reviewer; generic [source]
OAuth/OIDC flow design for humans -> software-engineering-patterns. [source]

Why agents need their own identity

An agent is neither a human nor a classic service: it is an intermediary that [source]
acts on a human's behalf yet is not that human. Today's identity systems offer [source]
two bad defaults, both of which misidentify the agent: [source]
Impersonation (agent borrows the user's token/session). Trivial to ship — [source]
just pass the user's token - but the agent inherits every permission the [source]
user holds, the audit trail collapses into a single human identity across all [source]
downstream hops, and a prompt injection becomes a confused-deputy attack: [source]
an attacker who controls part of the agent's context (an email, ticket, PDF, [source]
webpage) can redirect the agent's standing authority to exfiltrate data. The [source]
token authenticates correctly the entire way. [source]
Shared / static service account (long-lived API key). Individual agent [source]
behavior becomes unattributable - logs show which account acted, not [source]
which agent or which user delegated - and revoking one misbehaving agent [source]
revokes access for every agent on that account. [source]
Both are the same root failure: overscoped, long-lived, shared credentials. [source]
The consensus fix (CyberArk, Red Hat, Descope, Microsoft, AWS, multiple 2025-26 [source]
arXiv papers) is dedicated agentic identity: each agent gets short-lived, [source]
scoped credentials bound to a specific user + agent + task, so blast radius [source]
is bounded and an agent can be revoked without touching the human. A separate [source]
identity does not stop prompt injection, but **narrow agent-specific scopes [source]
sharply reduce what a confused deputy can do.** [source]
The community term is non-human identity (NHI) / agentic identity — [source]
treated as a first-class identity type alongside humans and services. [source]
Cryptographic foundations being adopted: workload identity (SPIFFE/SPIRE X.509 / [source]
JWT-SVIDs, optionally bound to a measured workload via remote attestation on [source]
TDX / SEV-SNP / Nitro Enclaves), and DIDs + Verifiable Credentials for cross-org [source]

Delegation primitives (the standards)

RFC 8693 - OAuth 2.0 Token Exchange (RATIFIED, 2020). The backbone. The [source]
agent presents a subject_token (the user) and an actor_token (itself) and [source]
receives a composite token whose act claim names the actor acting on the [source]
subject's behalf. Supports nested act claims (agent A -> agent B -> API) [source]
and a may_act claim to pre-authorize the next hop. Critical caveat: [source]
token exchange does not automatically enforce least privilege or narrow [source]
scope - narrowing + enforcement is the implementer's responsibility. [source]
OAuth 2.1 (IETF DRAFT, draft-ietf-oauth-v2-1). Mandatory PKCE, exact [source]
redirect-URI matching, short-lived access tokens, refresh-token rotation for [source]
public clients. The baseline every agent auth flow should follow. [source]
draft-oauth-ai-agents-on-behalf-of-user-02 (IETF INTERNET-DRAFT, 2026). [source]
The key new agent-specific piece. Adds a front-channel consent flow that [source]
RFC 8693 lacks: requested_actor on the authorization request (names the agent [source]
on the consent screen) and actor_token on the token request (agent proves who [source]
it is). The issued token names user + client + agent and documents the [source]
Microsoft "On-Behalf-Of" (OBO) is a well-known RFC 8693 implementation; [source]
agent platforms adapt it (grant types: client_credential, jwt-bearer, [source]

Scoped, least-privilege, short-lived tokens (the discipline)

One OAuth client ID per agent, with scopes limited to exactly what the task needs. [source]
Short-lived access tokens (minutes), refresh-token rotation, and a clear [source]
per-agent revocation path that does not disable the human. [source]
Narrow at each hop: an orchestrator that calls sub-agents/tools should [source]
exchange its delegated token for a new token scoped + audience-addressed to [source]
each immediate destination - never forward the original credential. [source]
Just-in-time / Just-enough-access (JIT/JEA): mint a least-privilege token [source]
at action time rather than holding standing access. [source]

MCP authorization (agent -> MCP server) — spec rev 2025-06-18

This is the MCP client / agent side of MCP auth. (Authoring the server -> [source]
mcp-builder.) The MCP authorization spec selects a subset of OAuth 2.1 + four [source]
The MCP server is an OAuth 2.1 resource server; the agent is the **OAuth [source]
2.1 client**. (Applies to HTTP transports; stdio servers read creds from the [source]
environment instead.) [source]
Discovery: server returns 401 with a WWW-Authenticate header -> client [source]
fetches /.well-known/oauth-protected-resource (**RFC 9728 Protected [source]
Resource Metadata - RATIFIED**, mandatory) -> reads authorization_servers -> [source]
fetches RFC 8414 Authorization Server Metadata -> runs OAuth 2.1 + PKCE. [source]
RFC 7591 Dynamic Client Registration is SHOULD-level for zero-friction onboarding. [source]
Audience binding (RFC 8707 Resource Indicators - RATIFIED, mandatory): the [source]
client MUST send a resource parameter (the canonical MCP server URI) in both [source]
authorization and token requests; the server MUST validate the token's [source]
audience is itself and reject foreign-audience tokens. [source]
No token passthrough (security-critical): if the MCP server calls upstream [source]
APIs it acts as an OAuth client to them with a separate token - it MUST [source]
NOT forward the agent's token. This is the documented fix for the confused- [source]
deputy / token-replay class. Tokens go in Authorization: Bearer on every [source]
request, never in the query string. [source]
The June 2025 revision dropped the older auth-server/resource-server [source]
coupling in favor of mandatory RFC 9728; AWS AgentCore Gateway and others [source]
implement exactly this resource-server pattern. [source]

Token vaulting / credential brokering

So agents and tools never see raw secrets, a broker stores and refreshes [source]
downstream credentials and hands the agent only scoped, short-lived tokens at [source]
call time. Implementations: Auth0 Token Vault, **AWS Bedrock AgentCore [source]
Identity token vault (2-legged M2M + 3-legged OBO), Descope Agentic Identity [source]
Hub credential vault**. [source]

Agentic payments & commerce

Cross-cutting model: a user grants bounded spending authority (spend caps, [source]
allowances, mandates); the agent transacts; every step is logged; tokenization [source]
keeps raw card data away from agents/merchants; disputes/fraud are handled via [source]
mandates-as-evidence, "know your agent" verification, and real-time network signals. [source]

Google AP2 (Agent Payments Protocol) — open spec, v0.2 (DRAFT)

A security layer that composes into a commerce protocol (designed for the [source]
Universal Commerce Protocol + A2A), expressing intent/payment as **Verifiable [source]
Digital Credentials (VDCs) secured as SD-JWTs**. [source]
> Terminology in transition - present honestly. The **canonical core spec [source]
> (ap2-protocol.org, v0.2, Google) now defines two mandates: a Checkout [source]
> Mandate** (secures what is bought; merchant-built, user-signed) and a [source]
> Payment Mandate (proves to the Credential Provider/Network/issuer the agent [source]
> is authorized to pay), across five roles (Shopping Agent, Credential [source]
> Provider, Merchant, Merchant Payment Processor, Network). The **earlier GitHub [source]
> specification.md + A2A-extension docs use a three-mandate** framing — [source]
> Intent + Cart + Payment - where "Cart" is being renamed to "Checkout." [source]
Human-present ("direct"): user signs the Checkout/Cart Mandate at purchase [source]
time with a hardware-backed device key. [source]
Human-not-present ("autonomous"): user pre-approves an Intent Mandate [source]
(constraints: merchant allow-lists, SKU/refundability, intent_expiry); the [source]
Shopping Agent later assembles + signs a closed Checkout + Payment Mandate [source]
with an agent key, whose public key is the cnf claim of the open [source]
mandate, exp kept minimal. Mandates link via a hash of the checkout_jwt. [source]
x402 extension (a2a-x402 v0.2): x402 acts as a Form-of-Payment inside [source]
AP2 - the Agent Card advertises both; the x402PaymentRequiredResponse embeds [source]
in an AP2 CartMandate artifact and the PaymentPayload in a PaymentMandate. [source]
Maturity: open-source draft, reference flows; Google-led; not ratified. [source]

Coinbase x402 — HTTP-native stablecoin payments (spec v2, 2025-12-09)

Revives HTTP 402 Payment Required for instant USDC settlement over HTTP, [source]
for humans and agents, with no accounts/sessions. Launched May 6 2025. [source]
Flow: client requests a resource -> server returns 402 with a PAYMENT-REQUIRED [source]
header -> client returns a PAYMENT-SIGNATURE header carrying a signed [source]
PaymentPayload -> server verifies/settles locally or via a facilitator [source]
(/verify, /settle) -> PAYMENT-RESPONSE header on success. [source]
v2 (2025-12-09): CAIP-2 network IDs (eip155:8453 = Base), multi-network [source]
(EVM + Solana), extensions (Bazaar discovery, gasless Permit2, Sign-in-with-x), [source]
exact scheme. USDC via EIP-3009 needs no on-chain approval; any ERC-20 via [source]
Facilitators: Coinbase CDP (Base/Polygon/Arbitrum/World/Solana; free [source]
1,000 tx/mo, then $0.001/tx); x402.org/facilitator testnet-only. TS/Go/Python [source]
SDKs. Composable with AP2. [source]
Maturity: open standard + production facilitator; **ratified by vendor [source]
(Coinbase), not a standards body**; crypto rail. [source]

Agentic Commerce Protocol (ACP) — OpenAI + Stripe (+ Meta), open, BETA

Launched Sept 29 2025 ("Buy it in ChatGPT" / Instant Checkout). Apache-2.0, [source]
jointly governed by OpenAI + Stripe. The merchant stays merchant of record; [source]
ChatGPT relays order details, the merchant accepts/declines and charges via its [source]
own PSP. Building blocks: Agentic Checkout, Cart & Feed, Delegate Payment, [source]
Delegate Authentication (OAuth 2.0), Orders & Webhooks. [source]
Delegated Payment Spec (POST /agentic_commerce/delegate_payment, OpenAI -> [source]
PSP): buyer saves a method in ChatGPT -> a single-use, allowance-constrained [source]
payload goes to the merchant's PSP/vault -> PSP returns a **scoped token outside [source]
PCI scope** -> OpenAI forwards it at complete-checkout. [source]
Allowance object (required fields): reason (one_time), max_amount [source]
(minor units), currency (ISO-4217 lowercase), checkout_session_id, [source]
merchant_id (<=256 chars), expires_at (RFC 3339). Requests carry Signature, [source]
Timestamp, Idempotency-Key; versioned by date. [source]
Stripe Shared Payment Token API is the first Delegated-Payment-Spec- [source]
compatible implementation (~one line if already on Stripe; works across PSPs). [source]
Maturity: BETA, production reference impl live in ChatGPT; card rail. [source]

Card-network programs (ANNOUNCEMENTS / pilots, Apr 2025+)

Visa Intelligent Commerce (Apr 30 2025): opens Visa's network to agent [source]
builders; AI-Ready Cards = tokenized digital credentials confirming the [source]
chosen agent is authorized; consumer-set spend limits + merchant categories; [source]
real-time signals for controls + disputes. Partners: OpenAI, Microsoft, [source]
Anthropic, Stripe, Samsung. [source]
Mastercard Agent Pay (Apr 29 2025): Mastercard Agentic Tokens (on [source]
tokenization + Payment Passkeys); "Know Your Agent" registration; biometric [source]
auth; consumer rules. Floats applying MCP to Secure Remote Commerce. [source]
PayPal (paypal.ai); Mastercard×PayPal (Oct 27 2025): Agent Pay into PayPal's [source]
wallet + Agent Pay Acceptance Framework pilot. [source]
Maturity: vendor programs + early pilots; rollout timelines vague. [source]

Agent-native / crypto startups

Skyfire (Jun 26 2025): verified identity tokens for Know Your Agent (KYA), [source]
programmable payment tokens, A2A commerce; ships KYAPay, a JWT-token payment [source]
extension for A2A; no wallets/gas. [source]
Catena Labs (out of stealth May 20 2025): Circle/USDC co-founder building a [source]
regulated AI-native bank (pursuing an OCC charter): deterministic policy per [source]
action, immutable audit trails, verifiable agent identity, stablecoin + fiat. [source]
Maturity: early, charter-pending. [source]
Nekuda: agent wallet SDK - collect/store credentials (iframe, no PCI [source]
burden), record user mandates, return a reveal token for JIT card [source]
retrieval. Maturity: early SDK. [source]

Integration patterns

1. Agent calls a protected MCP server (client side): [source]
2. Multi-hop delegation (orchestrator -> sub-agent/tool), RFC 8693: [source]
3. Autonomous AP2 purchase (human-not-present), conceptual: [source]
4. ACP delegated payment (allowance-bounded): [source]

Anti-patterns & failure modes

Agent uses the user's token / session (impersonation). Over-permissions the [source]
agent, erases the audit trail, makes prompt injection a confused-deputy data- [source]
exfil path. Use a distinct agent identity + scoped token. [source]
Shared service account across many agents. Behavior unattributable; revoking [source]
one agent revokes all. One client ID per agent. [source]
Long-lived, broad-scope credentials. One crafted document away from [source]
exfiltration; the secret itself is exfiltratable. Use short-lived + JIT + [source]
attestation-bound identity. [source]
MCP token passthrough. Server forwards the client's token upstream -> [source]
confused deputy. Server must mint its own upstream token; validate audience. [source]
Assuming RFC 8693 enforces least privilege. It only carries the act chain; [source]
scope narrowing + enforcement is on you. [source]
No spend cap / mandate / expiry on agent payments. Always bound by [source]
max_amount, currency, merchant scope, and expires_at; keep single-use [source]
where possible; log every intent -> evaluation -> execution. [source]
Treating vendor announcements as shipping standards. Visa/Mastercard/PayPal [source]
programs are largely pilots; AP2 is a moving draft; ACP is beta. Pin to spec [source]
versions/dates and re-verify. [source]
Trusting unofficial AP2 "specs." Lookalike sites circulate fabricated AP2 [source]
vocabulary. Use ap2-protocol.org and the google-agentic-commerce GitHub org only. [source]

2025-2026 frontier & maturity flags

Ratified standards (build on these): RFC 8693 (token exchange), RFC 9728 [source]
(protected resource metadata), RFC 8707 (resource indicators), RFC 8414 (AS [source]
metadata), RFC 7591 (DCR). MCP authorization rev 2025-06-18 selects a subset [source]
+ OAuth 2.1 (itself still IETF draft). [source]
Active IETF draft (the agent-specific gap): [source]
draft-oauth-ai-agents-on-behalf-of-user-02 - front-channel consent to a [source]
named agent; watch for adoption. [source]
Identity vendor GAs: Entra Agent ID (GA), Descope Agentic Identity Hub 2.0 [source]
(GA Jan 2026), AWS Bedrock AgentCore Identity (Aug 2025), WorkOS/Auth0/Stytch/ [source]
Clerk shipping. NHI is now a recognized analyst category. [source]
Payments maturity: ACP = beta (live in ChatGPT); **x402 = open std v2 + [source]
production facilitator (vendor-ratified); AP2 = draft v0.2, terminology in [source]
flux (Cart->Checkout); Visa/Mastercard/PayPal = announcements + pilots**; [source]
Skyfire / Catena / Nekuda = early-stage. [source]
Open research questions: workflow-scoped (not just hop-scoped) authorization [source]
for multi-agent chains; attenuating capability tokens; post-quantum delegation [source]
chains with fast revocation; binding agent identity to attested workloads; [source]
"Know Your Agent" + KYC for regulated rails. [source]
Convergence signal: identity and payments are merging - A2A Agent Cards [source]
advertise both auth schemes and payment extensions (x402, AP2); card networks [source]
cite MCP; payment tokens are increasingly just scoped, mandate-bound OAuth-style [source]

Sources

MCP Authorization spec (2025-06-18): https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization [source]
RFC 9728 Protected Resource Metadata: https://datatracker.ietf.org/doc/html/rfc9728 [source]
RFC 8693 OAuth 2.0 Token Exchange: https://rfc-editor.org/rfc/rfc8693 [source]
IETF draft-oauth-ai-agents-on-behalf-of-user-02: https://datatracker.ietf.org/doc/html/draft-oauth-ai-agents-on-behalf-of-user-02 [source]
WorkOS - OAuth On-Behalf-Of for AI agents: https://workos.com/blog/oauth-on-behalf-of-ai-agents [source]
WorkOS - MCP Authorization in 5 OAuth specs: https://workos.com/blog/mcp-authorization-in-5-easy-oauth-specs [source]
Descope - MCP Auth Spec / Token Exchange / Agentic Identity Hub: https://www.descope.com/blog/post/mcp-auth-spec , /learn/post/oauth-token-exchange , /blog/post/agentic-identity-hub [source]
Auth0 - Auth for AI Agents: https://auth0.com/ai , https://auth0.com/docs/get-started/auth0-for-ai-agents [source]
Microsoft Entra Agent ID + OBO flow: https://learn.microsoft.com/en-us/entra/agent-id/agent-identities , /identity-platform/agent-on-behalf-of-oauth-flow [source]
AWS Bedrock AgentCore Identity: https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-agentcore-identity-securing-agentic-ai-at-scale/ , https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-overview.html [source]
Stytch - AI agents & Connected Apps: https://stytch.com/docs/get-started/guides/ai-agents-and-apps [source]
Red Hat - Zero trust for AI agents (delegation vs impersonation): https://next.redhat.com/2026/05/21/zero-trust-for-ai-agents-why-delegation-beats-impersonation/ [source]
CyberArk - Zero Trust for AI Agents: https://developer.cyberark.com/blog/zero-trust-for-ai-agents-delegation-identity-and-access-control/ [source]
AP2 canonical spec v0.2 (Google): https://ap2-protocol.org/ap2/specification/ + GitHub https://github.com/google-agentic-commerce/AP2/blob/main/docs/specification.md [source]
a2a-x402 spec v0.2: https://github.com/google-agentic-commerce/a2a-x402/blob/main/spec/v0.2/spec.md [source]
Coinbase x402 spec v2 (2025-12-09) + CDP: https://github.com/coinbase/x402/blob/main/specs/x402-specification-v2.md , https://docs.cdp.coinbase.com/x402/welcome [source]
OpenAI - Buy it in ChatGPT + Delegated Payment Spec: https://openai.com/index/buy-it-in-chatgpt/ , https://developers.openai.com/commerce/specs/payment [source]
Stripe - Agentic Commerce Protocol + Shared Payment Token: https://docs.stripe.com/agentic-commerce/acp , https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce [source]
Visa Intelligent Commerce (Apr 30 2025): https://investor.visa.com/news/news-details/2025/Find-and-Buy-with-AI-Visa-Unveils-New-Era-of-Commerce/ [source]
Mastercard Agent Pay (Apr 29 2025): https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay... [source]
Skyfire (KYA, KYAPay): https://skyfire.xyz/skyfire-launches-identity-and-payments-for-autonomous-ai-agents/ [source]
Catena Labs: https://catena.com/about ; Nekuda SDK: https://docs.nekuda.ai/system-overview [source]
arXiv 2505.19301 - Zero-Trust Identity Framework for Agentic AI (DIDs/VCs): https://arxiv.org/html/2505.19301 [source]
> Boundary note: human/workforce/workload IAM + the Okta identity platform defer to okta-expert; MCP server authoring defers to mcp-builder (this covers only the agent/client side of MCP auth). Identity is ratified-standard-anchored; payments are mostly draft/beta/announcement - every payment claim is maturity-flagged and date-stamped. [source]

Children

Non-human identity (NHI) for agents (frontier)
OAuth 2.1 on-behalf-of / token exchange (RFC 8693) (frontier)
Scoped least-privilege short-lived agent tokens (frontier)
MCP authorization & resource-server pattern (RFC 9728/8707) (frontier)
Token vaulting & credential brokering (frontier)
Human-in-the-loop consent & async authorization (frontier)
Confused-deputy & prompt-injection authority hijack (frontier)
Delegation chains & act/may_act claims (frontier)
AP2 mandates (Intent / Checkout / Payment, SD-JWT) (frontier)
x402 HTTP-402 stablecoin settlement (frontier)
Agentic Commerce Protocol & delegated payment / Shared Payment Token (frontier)
Spend caps, allowances & agent payment audit trails (frontier)

Frontier under this node: AP2 mandates (Intent / Checkout / Payment, SD-JWT), Agentic Commerce Protocol & delegated payment / Shared Payment Token, Confused-deputy & prompt-injection authority hijack, Delegation chains & act/may_act claims, Human-in-the-loop consent & async authorization, MCP authorization & resource-server pattern (RFC 9728/8707), Non-human identity (NHI) for agents, OAuth 2.1 on-behalf-of / token exchange (RFC 8693), Scoped least-privilege short-lived agent tokens, Spend caps, allowances & agent payment audit trails, Token vaulting & credential brokering, x402 HTTP-402 stablecoin settlement

← the whole tree · 3D view· how to read this page