Visa, Mastercard and the Agent Trust Frameworks

The card networks are solving the one thing agentic checkout cannot solve for itself: proving the agent is allowed to spend.

---

TL;DR

• An agent trust framework answers one question: is this AI agent authorised to spend on this cardholder's behalf, for this amount, for this purchase?
• Visa and Mastercard are building it at the network layer, not the merchant layer — so it will reach you whether or not you integrate anything.
• Liability has not moved. Verified agent identity is the precondition for that, not the event itself.
• Merchant-side preparation is unglamorous: record which agent placed each order and what authorisation was presented.

---

The problem the networks are solving

Card networks were built on the assumption that a human is present. Authentication asks is this the cardholder? An agent purchase asks a different question that no existing rail answers: is this software allowed to act for the cardholder, and how far?

That is a delegation problem, not an authentication problem. It needs a way to identify the agent, bind it to a cardholder, express the limits of what it may do, and let a merchant verify all of that at the moment of the transaction.

This is why the networks are building new frameworks rather than extending 3-D Secure. 3-D Secure proves a person is who they say they are. Nothing in it describes delegated authority to a machine.

---

Why it is happening at the network layer

An agent platform could issue its own credentials, and some will. But a merchant cannot reasonably be asked to evaluate a different trust scheme per assistant, and an issuer cannot be asked to honour credentials it has no relationship with.

The networks sit in the one position that sees both sides. When Visa and Mastercard define how an agent is identified and how its authority is expressed, that definition propagates to every issuer and every acquirer without each merchant negotiating it.

The practical consequence for you: this is not a build-or-skip decision. It arrives as scheme rules.

---

What has and has not changed

Has changed: there is now a credible path to an agent purchase carrying verifiable provenance — which agent, acting for whom, within what limits.

Has not changed: who pays when it goes wrong. An unauthorised agent purchase still settles as card-not-present, and card-not-present liability sits with the merchant. Better evidence is the precondition for reallocating that risk; it is not the reallocation.

Be sceptical of anyone selling you the second as though it has already happened.

---

What merchants should do now

Record the agent on the order. Which agent or surface placed it, which authorisation reference accompanied it, what price and terms were presented. This is cheap to store and impossible to reconstruct later, and it is precisely the evidence these frameworks will ask for.

Keep fraud tooling on. The most common error is relaxing velocity and anomaly checks because traffic arrives from a recognised assistant. Recognised is not authorised.

Segment agent orders in reporting. You cannot see a pattern in a channel you do not measure separately.

Track network mandates, not vendor announcements. The rules that bind you come from the schemes. A payment vendor's launch post tells you what is possible; a scheme mandate tells you what is required.

---

Where this sits in the stack

Trust is one layer of four, and it is the last one that matters for revenue. An agent has to find your product, choose it, and be able to transact on your surface before a trust framework is ever invoked. Merchants who sequence trust and payments ahead of discovery end up with immaculate plumbing and no water.

If you have not yet checked whether assistants name you at all for the questions your buyers ask, start there: run a free Citation Rank scan.

---

Related: from the network's trust layer to the merchant's gateway

Every agent purchase ends on a rail a merchant already runs: a Link single-use card, Shop Pay, Google Pay, a Stripe Shared Payment Token or a saved card behind a login, and Stripe put Link's agent purchases at more than 1 million businesses that accept it (Stripe, 8 September 2026). How the network frameworks meet the checkout rails, and who is liable at each step, is in the agentic payments guide; the dispute side is in returns, refunds and chargebacks on agent orders.

FAQs

Q: What is an agent trust framework? A: Network-level rules and credentials proving an AI agent in a purchase is authorised — identifying the agent, tying it to a cardholder, and bounding what it may spend.

Q: Does this shift fraud liability away from merchants? A: Not yet. It creates the evidence on which liability could later be reallocated. Today an unauthorised agent purchase still settles as card-not-present.

Q: Do merchants have to integrate anything? A: Largely not yet. Record which agent placed each order and what authorisation was presented — that is the evidence these frameworks will ask for.

Q: How is this different from 3-D Secure? A: 3-D Secure authenticates a human. An agent trust framework authenticates a non-human actor and the scope of its delegated authority.