Now they have to prove which agent paid.

For months the question in agentic commerce was whether a machine could pay at all. That part is settled. The newer question, the one the last few days have pushed to the front, is quieter and harder: when an agent completes a purchase, do you know which agent it was, who it was acting for, and whether it had the authority. Identity has become the load-bearing problem, and this week three moves showed different corners of the industry trying to answer it.

Know Your Agent stops being a slogan

The phrase doing the rounds is Know Your Agent, and it has hardened from talking point into an emerging standard. It is the identity layer for agent-driven payments, a set of cryptographic and reputational checks that lets a merchant or fraud system tell a registered, accountable agent from an anonymous bot [1]. The market has already split into four ways of doing it: tokenised agent identities in Mastercard Agent Pay, attestation headers in Visa's Trusted Agent Protocol, verifiable credentials with signed mandates in Google's AP2, and decentralised identifiers on the crypto-native side [2]. Visa's Trusted Agent Protocol went live on 14 October 2025 with twelve launch partners, so this is a running system now, not a whitepaper [2].

The banks in Asia are writing the liability rules

On 20 July the Emerging Payments Association Asia launched an AI and Agentic Payments Working Group, with HSBC as a founding member, pulling banks, networks, and fintechs together to set standards for who is liable when an agent transacts [3]. This is not theoretical for them either. HSBC and Mastercard ran an end-to-end B2B agentic payment pilot for two Singapore-based clients back in May, so the working group is codifying something already live in production [3].

The card side answers with disposable credentials

The infrastructure answer looks different but points the same way. Cross River and Stripe extended their issuing partnership to give agents bank-grade, single-use virtual cards, each scoped to one transaction so the agent presents a throwaway credential rather than the customer's real card number [4]. The credential is bound to a specific user's authorisation and constrained by amount, merchant, and context, and it has to verify both the end user and the agent acting on their behalf, with the KYC and anti-money-laundering checks sitting on Cross River's banking core [5]. Stripe also exposes the same issuance programmatically through its API for teams building their own agentic flows [5].

Read from the rails

Three different groups, one instinct: constrain the credential and make the actor identifiable before it ever spends. A single-use card scoped to amount, merchant, and context is the same idea as a signed mandate on an agent identity, just expressed in card-network language instead of cryptographic tokens. Both are trying to shrink the blast radius of a compromised or misbehaving agent, and both accept that the old "one card, many purchases, one human who could in principle be asked" model does not survive contact with software that transacts on its own.

The part I would watch is the join between identity and dispute. Ten years in payments operations taught me that a credential is only as good as what it leaves behind when something goes wrong. Know Your Agent is useful at the moment of authorisation, but the real test is whether the mandate that let an agent spend can be produced weeks later, matched to the exact transaction, and stand up in a chargeback or an AML query. Four competing identity models is four reconciliation formats a merchant may have to hold at once, and a liability working group only matters if its answer survives into the repair queue. The networks are naming the actor. The open question is whether the proof of authority ages as well as the payment does.

Naming the agent is the easy half. The hard half is producing, weeks later, the mandate that said it was allowed to spend. Identity that cannot be reconciled after the fact is just a label.