An AI agent completing a payment with a signed mandate and a verifiable-intent seal.

KYA for agentic payments

Payment systems are built on one quiet assumption: that a human chose to buy, on a trusted website, by clicking a button. Every control around that moment — authentication, fraud scoring, dispute rules, liability — assumes a person was present and in control. An autonomous agent breaks that assumption. It initiates, negotiates and completes a purchase without a human in the loop, sometimes for many steps, sometimes across many merchants.

Know Your Agent (KYA) is the discipline that repairs the assumption: establishing who the agent is, on whose authority it acts, and whether this specific payment is within the mandate the principal granted. KYC verifies the customer; KYA verifies the agent. In payments, that difference is not academic — it is the difference between a merchant accepting a transaction and refusing it. This pillar explains what breaks, the three questions it raises, how signed mandates encode agent identity into the transaction, and what to implement.

For the vocabulary, see What is KYA?, delegation and scoped credential.

The assumption that no longer holds

The Agent Payments Protocol (AP2) states the problem in its own words: “Today’s payment systems assume a human is directly clicking ‘buy’ on a trusted website. When an autonomous agent initiates a payment, this core assumption is broken.” The FIDO Alliance frames the same gap from the authentication side: today’s authentication and authorisation models “were designed for direct human interaction, not delegated, agent-initiated actions”, so users may be pushed to share credentials while service providers “lack reliable, interoperable ways to verify user intent — including who authorized an action, under what conditions, and with what limits.”

Three concrete failures follow:

  • No proof of intent. A card credential proves the instrument is valid. It does not prove the user asked for this. An agent that hallucinates a purchase still holds a valid credential.
  • No accountability chain. When a transaction is wrong, who is liable — the user, the agent’s developer, the merchant, the issuer, the PSP, or the orchestration layer? Legacy systems have no field for “an agent did this on behalf of X, under mandate Y”.
  • No bounded authority. A stored card or a broad token grants an agent everything the principal can do, indefinitely. There is no built-in way to say “up to €80, this route, until 18:00”.

Agentic payments are where these failures cost real money, which is why payments moved faster than the identity standards bodies. The protocols below are the industry’s attempt to put identity and intent inside the transaction.

The three questions every agent payment must answer

AP2 reduces the problem to three questions. They are the clearest organising frame available, and they map directly onto KYA:

  1. Authorization — How do we verify that the user gave this agent specific authority for this particular purchase?
  2. Authenticity — How can a merchant be sure the agent’s request accurately reflects the user’s true intent, without errors or AI “hallucinations”?
  3. Accountability — If a fraudulent or incorrect transaction occurs, who is accountable?

Notice what these are not. They are not “is the payment method valid” (that is the card networks’ existing job) and not “is the agent a good AI” (that is nobody’s job in a payment flow). They are identity and authority questions: who the agent is, what it was told to do, and who answers for the result. That is KYA, applied to a transaction.

How signed mandates encode agent identity

The common design across the leading schemes is the signed mandate: a cryptographically signed object, issued under the principal’s control, that a merchant or payment processor can verify without phoning home to the user. The mandate answers “authorization” and “authenticity” at once, because it is both proof of authority and proof of intent.

AP2: Verifiable Digital Credentials

AP2 calls these objects Verifiable Digital Credentials (VDCs) — “tamper-evident, cryptographically signed digital objects that serve as the building blocks of a transaction”. There are two, each in two stages:

  • Checkout Mandate — captures the items and purchase details negotiated between agent and merchant; shared with the merchant. Open captures the user’s constraints and goals before a cart is finalised (for autonomous execution); Closed captures authorisation for a specific, finalised checkout.
  • Payment Mandate — authorises payment against a specific instrument; shared with the credential provider, the networks and the merchant’s payment processor. Again Open (constraints such as budget and allowed instruments) or Closed (authorisation for a specific amount bound to a finalised checkout).

AP2’s design principle is “verifiable intent, not inferred action”: trust is anchored to deterministic, non-repudiable proof of intent rather than to a probabilistic guess about what the agent probably meant. The mandates chain together into a verifiable audit trail for both human-present and human-not-present transactions. AP2 is an open protocol, available as an extension for the Agent2Agent (A2A) protocol and the Universal Commerce Protocol (UCP); v0.2 added human-not-present payments, and standardisation continues inside the FIDO Alliance’s Agentic Authentication and Payments technical working groups.

Visa Trusted Agent Protocol

Visa’s Trusted Agent Protocol (TAP) is “an open framework designed on existing web infrastructure” that helps merchants “distinguish between malicious bots and legitimate AI agents acting on behalf of consumers”. Instead of a new credential type, it leans on signatures and headers the web already understands, and it lets an agent tailor payment details to the merchant’s method — for example passing a hashed Visa Intelligent Commerce payment credential that the merchant can validate as authentic. The emphasis is authenticity of the caller (is this a legitimate agent?) rather than a full intent credential, which makes it a natural complement to a scheme like AP2.

Mastercard Agent Pay and Agentic Tokens

Mastercard’s Agent Pay is a “Remote Commerce Tokenization Program” that lets AI agents “securely initiate and complete transactions” using network tokenisation via the Mastercard Digital Enablement Service (MDES). Its Agentic Tokens are “built to register, verify and recognize agentic transactions”, and each time an agent acts — even for a recurring payment — it does so “with the permissions and limits you define”. Mastercard contributed its Verifiable Intent framework, co-developed with Google and designed to work with AP2, to the FIDO Alliance.

OpenAI / Stripe: Agentic Commerce Protocol and Shared Payment Tokens

The Agentic Commerce Protocol (ACP) lets an agent complete a merchant’s checkout programmatically. The scoped credential is a single-use payment token: on Stripe’s implementation that is a Shared Payment Token; the parallel OpenAI Delegated Payment Spec uses a vault token. Stripe is the first compatible PSP. A key structural point, stated by OpenAI, is that “OpenAI is not the merchant of record in the Agentic Commerce Protocol” — the agent platform orchestrates, but the merchant and its PSP remain the transacting parties.

The common pattern

Strip away the branding and the same four pieces recur:

  • A principal who is accountable and who defines the limits.
  • A signed object (mandate, token, or signed request) that binds the agent to that principal and to a specific, bounded action.
  • A verifier (merchant, processor, network) that can check the signature and the limits offline or near-offline.
  • A record that lets the transaction be attributed afterwards.

That is the KYA stack expressed in payment terms: identity, delegation, scoped credential, audit trail. Open, and largely unsolved, are revocation (killing a mandate mid-flight) and narrowing delegation (a sub-agent may hold no more authority than its parent).

What to implement

A practical checklist for anyone accepting agent-initiated payments, mapped to the verify-an-agent flow:

  1. Identify the agent, not just the instrument. Require a verifiable agent identity or a signed request (TAP-style), and treat the agent identifier as a first-class field on the transaction, distinct from the cardholder.
  2. Require a signed mandate for intent. Accept a verifiable credential (AP2 VDC, Verifiable Intent, or a delegated payment token) that names the principal, the scope and the limits. Verify the signature against the issuer’s published key material.
  3. Check the mandate against the transaction. The amount, merchant, items and time must fall inside the mandate. A valid credential for a different purchase is not authorisation for this one.
  4. Enforce the “narrow only” rule. If the agent spawned sub-agents, their authority must be a subset of the parent’s. A chain must terminate.
  5. Scope and expire everything. Prefer single-use or short-lived credentials over a stored card; bound amount, merchant, category and time.
  6. Gate the risky cases on a human. Human-not-present is for bounded, low-risk actions; above a threshold, require explicit step-up approval.
  7. Log principal, mandate and action. Hold an append-only record that reconstructs which agent, acting for which principal, under which mandate, at what time.
  8. Make revocation real and fast. A revoked mandate must fail the next request, not the next statement cycle.
  9. Decide liability up front. The mandate is also a liability instrument: be explicit about who bears the loss when an agent acts within scope but the outcome is wrong.

Worked example: an agent books and pays for a train ticket

This scenario is illustrative — it shows how the pieces fit, and does not describe one product.

Priya asks her assistant agent: “Book me on the 07:14 to Tampere tomorrow and pay for it. Standard class, up to €60.”

  1. Identity. The agent presents its agent identity — issued when it was enrolled and bound to Priya’s account (the principal) — to the rail operator’s booking service. The service verifies the credential against the issuer’s key material.
  2. Checkout Mandate (Open). Before a cart exists, the agent holds an Open Checkout Mandate capturing Priya’s constraints: this route, standard class, tomorrow, up to €60. This is her intent, signed and bounded — not the agent’s guess.
  3. Negotiation and checkout. The agent finds the 07:14 at €54 and finalises the cart. It presents a Closed Checkout Mandate for that specific fare to the merchant.
  4. Authenticity. The merchant verifies the mandate’s signature. It can now trust that the request reflects Priya’s intent, rather than relying on the agent’s own assertion.
  5. Payment Mandate. For payment, the agent presents a Closed Payment Mandate authorising €54 against Priya’s chosen instrument (or, on a tokenised scheme, an Agentic Token within her defined limits; or on a card rail, a signed VDC the processor validates).
  6. Decision. The booking service evaluates the request against policy: agent identity valid, mandate scope matches, amount within limit. Because €54 is under Priya’s €60 ceiling and the route matches, no step-up is needed — the booking proceeds.
  7. Record. The transaction is logged with which agent, for which principal, under which mandate, at what time, against which credential — a non-repudiable audit trail.
  8. Revocation. Later, Priya decides her assistant should no longer book travel. She revokes the delegation. The next booking attempt fails at step 1 or 3, without disabling the assistant’s other integrations.

Now the counterfactual. Had the agent simply presented Priya’s stored card, steps 2, 4, 5 and 8 would be impossible. The merchant would have a valid instrument and no way to know whether this €54 fare was what Priya wanted, or whether a manipulated agent invented it. A card number proves an instrument; a mandate proves intent. That difference is what KYA adds to a payment.

FAQ

Is an agent payment just a card payment made by software? Technically a card may still move the money. But the control is different: agentic schemes add a signed mandate and an agent identity so the merchant can verify authority and intent, which a bare card number cannot express.

Do I need AP2 specifically? No. AP2 is one open design; Visa TAP, Mastercard Agent Pay, ACP and x402 address overlapping parts with different trust anchors and rails. What matters for KYA is that some verifiable object binds the agent to a principal and a bounded action, and that it can be revoked.

Who is liable if the agent buys the wrong thing? That is the open accountability question, and the protocols do not answer it for you — they provide the evidence (who authorised, within what limits, at what time) that a liability rule can be built on. Agree the rule contractually before you rely on it.

Does this replace KYC? No. KYC/KYB verifies the principal — the human or company behind the agent — and remains required for regulated activity. KYA verifies the agent and its mandate. They stack. See KYA vs KYC vs KYB.

What is the unsolved part? Revocation at scale and guaranteed narrowing of delegation. Both are essential and neither is settled across schemes as of October 2026.

Is this legal advice? No. It is an explanation for practitioners. Take professional advice for compliance and liability decisions.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.