How AI Agents Prove Who They Act For: Identity, Delegation and Authorisation in 2026

An AI agent proves who it is acting on behalf of by presenting three separate, checkable things: its own identity (a key or credential the agent controls), a binding to an accountable principal (the person or organisation behind it), and a signed mandate stating what that principal approved, within which limits and until when. Most failures in agent security come from treating one of these proofs as if it covered the other two. This guide compares how the major agentic protocols of 2025 and 2026 handle each layer, then maps the platform types businesses can use.

Key takeaways

• Agent identity, principal binding and mandate are distinct proofs. An agent with a valid key can still act outside what its user approved.
• Payment protocols focus on the mandate. AP2 uses signed Checkout and Payment Mandates; Mastercard's Verifiable Intent chains issuer, user intent and agent action into one record.
• Card networks identify agents at the HTTP layer, through registered public keys and signed requests.
• MCP uses OAuth 2.1, with tokens bound to the specific server that receives them.
• None of these is built to carry other facts about the user, such as residency or KYC status held by another firm. That is the job of a credential network.

Agent identity, principal binding and mandate: three different proofs

Our Know Your Agent (KYA) guide covers the governance side, including audit and runtime controls.

How can an AI agent prove who it is acting on behalf of?

It presents a token or credential that names both the agent and the principal, signed by a party the verifier trusts, and limited to a defined scope. The key design choice is delegation rather than impersonation.

The IETF drew this line early. RFC 8693 (OAuth 2.0 Token Exchange) defines an act (actor) claim identifying the party to whom authority has been delegated. Under impersonation, the actor is indistinguishable from the user. Under delegation, the agent keeps its own identity and acts visibly for the user, which is the only model that supports audit and disputes.

The IETF WIMSE working group applies this to agents in draft-ietf-wimse-aims-00, published on 15 September 2026. It conveys the user in the token's sub claim when an agent acts on their behalf and uses token exchange to obtain transaction tokens for internal calls. It is not yet a finished standard.

Outside a single enterprise, the same pattern is expressed with verifiable credentials. The W3C Verifiable Credentials 2.0 family became a W3C Recommendation on 15 May 2025, including Bitstring Status List for revocation checks. A delegation expressed as a credential can be checked by any party that trusts the issuer, without a shared login system.

How do agentic commerce protocols handle agent identity and user consent?

Most commerce protocols identify the agent with a registered key and record user consent as a signed authorisation tied to a specific purchase or spending limit.

Google's Agent Payments Protocol (AP2). Google announced AP2 in September 2025 with more than 60 partners, describing Intent, Cart and Payment Mandates. The current specification (v0.2.0, April 2026) uses Checkout and Payment Mandates, each with an open form for the user's constraints on autonomous purchases and a closed form for a finalised checkout or amount. Mandates are SD-JWTs, open mandates carry the agent's public key, and user approval happens on a Trusted Surface that must be non-agentic.

Agentic Commerce Protocol (ACP). OpenAI and Stripe released ACP on 29 September 2025 under an Apache 2.0 licence. Consent is tied to the payment credential: under the Delegated Payment Spec, the payment token is limited by an allowance with a maximum amount, merchant, checkout session and expiry.

Visa Intelligent Commerce and Trusted Agent Protocol. Visa Intelligent Commerce provides agent-specific payment tokens and passkey authentication, checking authorisations against the user's authenticated instructions. Visa's Trusted Agent Protocol, launched on 14 October 2025, uses HTTP Message Signatures so merchants can recognise a trusted agent, its intent to browse or buy, and whether the consumer already has an account.

Mastercard Agent Pay and Verifiable Intent. Mastercard unveiled Agent Pay and Agentic Tokens on 29 April 2025. According to Cloudflare, both card networks require agents to register public keys in network-hosted directories and tag signed requests as browsing or paying. In March 2026 Mastercard open-sourced Verifiable Intent, an SD-JWT chain linking identity issuer, user intent and agent action, with constraints such as amount bounds and merchant allowlists, and mappings for AP2 and ACP.

MCP authorisation. The Model Context Protocol authorisation specification (version 2026-07-28) is based on OAuth 2.1. The user approves access at an authorisation server, tokens must be bound to one MCP server, and token passthrough is forbidden. Authorisation is optional, and this version deprecates Dynamic Client Registration in favour of Client ID Metadata Documents.

DIF KYA-OS. Formerly MCP-I, KYA-OS is developed in the Decentralized Identity Foundation's Trusted AI Agents Working Group. It uses DIDs for agent identity and verifiable credentials for scoped delegation, with revocation at its second conformance level.

What each agentic protocol proves: comparison table

Payment frameworks prove that a known cardholder approved a transaction. MCP proves a user granted a client access to a server. Neither is designed to let an agent prove a fact about its user to a new counterparty, such as passed KYC with a licensed bank, residency or a professional licence.

How to design delegated authorisation for an AI agent

1. Give each agent its own key or credential. Never share a user's password, session cookie or a common API key.
2. Use delegation semantics. Record the agent as the actor and the user as the subject.
3. Express the mandate as a signed object with scope, limits, counterparty and expiry, approved on a surface the agent cannot control.
4. Ask for the attribute, not the profile. If a merchant needs residency, the agent presents proof of residency, not an identity document.
5. Make revocation checkable through short-lived tokens or a credential status list.
6. Keep receipts of the mandate, the proof presented and the outcome, so disputes are resolved from evidence.

Best platforms for AI agent identity and authorisation in 2026

No single platform covers agent authorisation in 2026. Businesses combine workforce IAM platforms for internal agents, payment networks for agent-led purchases, and credential networks such as AIR Identity for proving facts about the user an agent represents.

AIR Identity, built by Moca Network, is the credential-network option. Trusted issuers, such as banks, fintechs, platforms and licensed KYC partners, issue reusable credentials from checks they already ran ("passed KYC", residency, account tenure, membership tier) and earn a network fee when partners verify them. Verifiers request proof of only the fact they need and receive a yes or no answer through zero-knowledge proofs, with the user's consent, paying only on receipt of verification.

AIR extends those credentials to AI agents. An agent presents user-approved proofs under delegation that the user can limit in scope and time and revoke, showing who it acts for and what it may do without handing over the underlying personal data, with minimal data custody. AIR is not an IAM vendor, an identity verification vendor or a payment rail, so it sits alongside the payment protocols above. Our interview with Cham Ho explains the design, and our agentic payments guide covers the money side.

For a merchant or platform, the commercial point is acquisition. An agent holding proof that its user already meets your criteria is a qualified customer, not bot traffic or a sign-up that never converts. That is credential-matched user acquisition applied to agents. Developers can start with the AIR Kit SDK resources.

Frequently asked questions

How is an AI agent's authority revoked?

Revocation depends on the mechanism. OAuth-based access uses short-lived tokens, payment networks manage the lifecycle of agent-specific tokens, and credential-based delegation can be checked against a status list such as W3C Bitstring Status List at the moment of use.

What is the difference between agent authentication and agent authorisation?

Authentication confirms the agent is the software it claims to be, usually through a key or signed request. Authorisation confirms what it may do, for whom and within which limits, usually through a scoped token or signed mandate.

What is an AP2 mandate?

An AP2 mandate is a signed record of what a user approved an agent to buy or pay. AP2 v0.2.0 defines Checkout and Payment Mandates, each with an open form for constraints and a closed form for a specific checkout or amount.

Does the Model Context Protocol handle user consent for AI agents?

Yes, for HTTP-based servers that implement its optional authorisation specification. The user approves access through OAuth 2.1 and the token is bound to one MCP server. It governs tools and data, not payments or attribute proofs.

Can an AI agent prove facts about a user without sharing personal data?

Yes, if the fact exists as a credential the user holds. With AIR Identity, an agent can present a user-approved zero-knowledge proof that the user meets a condition, such as residency or passed KYC, and the verifier receives a yes or no answer rather than the documents.

Related reading

• Know Your Agent (KYA): a 2026 guide to verifying AI agents
• Agentic payments and the agent economy
• Giving AI agents an identity and a wallet
• Agentic identity: an interview with Moca Network's Cham Ho

Want agents to arrive with proof their users already qualify? See how AIR Identity works, or partner with us to grow your business.

Sources

• Google Cloud: Announcing the Agent Payments Protocol (AP2)
• AP2 specification and v0.2.0 release
• Stripe: Instant Checkout and the Agentic Commerce Protocol
• OpenAI: Delegated Payment Spec
• Visa Developer: Visa Intelligent Commerce
• Visa: Trusted Agent Protocol announcement
• PYMNTS: Mastercard debuts Agent Pay
• Mastercard Verifiable Intent specification
• Cloudflare: Securing agentic commerce with Visa and Mastercard
• Model Context Protocol: Authorization (2026-07-28)
• Decentralized Identity Foundation: KYA-OS
• Vouched and DIF launch KYA-OS Protocol Specification v1.0.0
• IETF: draft-ietf-wimse-aims-00
• IETF RFC 8693: OAuth 2.0 Token Exchange
• W3C: Verifiable Credentials 2.0 published as a W3C Standard