Key Takeaways:
- Agent identity does not prove customer authorization.
- Delegated authority should carry clear transaction limits.
- Final checkout details need to match the customer’s approved constraints.
- Agent-mediated transactions require records that can be examined later.
- Fraud controls increasingly depend on identity, permissions, and evidence architecture.
For years, ecommerce fraud systems have learned from the customer’s session. Device information, browser behavior, navigation patterns, transaction history, and other signals help merchants judge whether the person placing an order looks like the person they claim to be.
Agentic commerce changes part of that relationship. When an AI shopping agent searches, selects, or checks out on a customer’s behalf, the merchant may no longer observe the customer directly at the point of purchase. Some of the behavioral evidence that fraud systems have relied on can become weaker, unavailable, or attributable to the agent rather than the person behind it.
But that does not mean merchants are left without evidence. It simply changes the evidence they need. Trust increasingly depends on establishing which agent is acting, whether the customer authorized it, what authority was delegated, and whether the resulting transaction stayed within those limits.
The emerging protocols from Visa, Mastercard, Google, Stripe, and others are beginning to answer those questions in different ways. Taken together, they point toward five types of proof that may increasingly need to accompany an agent-mediated transaction.
-
Proof of who is acting
-
Proof that the customer gave it permission
-
Proof of what the agent was allowed to do
-
Proof that the agent stayed inside those boundaries
-
Proof that can still be examined after the transaction
An AI agent arriving at a merchant’s site may look like any other automated traffic unless it can identify itself. This is the role of agent identity: establishing that the software making the request is a recognized agent rather than anonymous or malicious automation.
Visa’s Trusted Agent Protocol allows recognized agents to attach a cryptographic signature to their requests. The merchant can verify that signature against a trusted public key and determine that the request came from a known agent. Visa treats this as a distinct layer of trust, separate from identifying the customer or validating the payment.
Agent identity answers only the first question. It does not establish what that agent has permission to buy.
A legitimate agent still needs evidence that it is acting for a customer who authorized the transaction. This is delegated authority: the customer gives the agent permission to act on their behalf rather than completing the purchase directly.
Visa separates agent recognition from consumer recognition and authorization in its protocol. Mastercard’s Verifiable Intent creates a tamper-resistant record of what the user authorized when an AI agent acts for them. Google AP2 similarly uses signed mandates to establish transaction authority.
For the merchant, “I know this agent” and “this customer authorized this purchase” are different facts. Agentic commerce increasingly needs evidence of both.
Delegated authority can come with transaction constraints. An agent might be permitted to spend only up to a certain amount, transact with a particular merchant, use a particular currency, or operate only until a stated expiry.
Stripe’s Shared Payment Token shows how those limits can be enforced technically. The token can be restricted to one seller and carry a maximum amount, currency, and expiry time. Stripe then checks those conditions when the seller attempts to use it. In a 2026 demonstration, a token capped at $25 allowed a $25 payment and rejected an attempted $50 charge.
The underlying principle is that permission to purchase does not have to mean unrestricted spending authority.
Setting transaction constraints only helps if the eventual purchase can be checked against them. That creates a need for transaction provenance: a reliable record connecting what the customer authorized with what the agent ultimately attempted to execute.
Google’s AP2 separates the customer’s approved constraints from the final checkout the agent assembles. In an autonomous transaction, the user can approve an open mandate describing the conditions under which the agent may act. When the agent later produces the actual checkout and payment, the relevant parties verify that those final details conform to the approved constraints. If verification fails, the transaction should be rejected.
That gives the merchant a way to check whether the transaction presented for execution matches the authority that made it possible.
The trust problem does not end when the payment succeeds. If the customer later disputes what happened, the participants need an audit trail and dispute evidence that can be examined after the fact.
AP2 is designed to retain a checkout mandate and receipt alongside a payment mandate and receipt. Its specification says those records can be brought together during a dispute to establish what the user and the different parties saw, with verification rules for checking that the records have not been altered. AP2 does not determine liability or prescribe the complete dispute-resolution process; those questions remain outside the current specification.
Mastercard’s Verifiable Intent follows the same broader direction by creating a tamper-resistant record of the user’s authorization that consumers, merchants, and financial institutions can refer back to.
The evidence trail may therefore need to establish more than whether a payment was technically approved. It needs to preserve what the customer permitted the agent to do and what ultimately happened.
The fraud stack now needs an evidence layer
As agent-mediated checkout becomes more common, fraud architecture will have to carry more of the evidence that a human session once supplied. The transaction needs to arrive with enough context to establish who acted, what the customer authorized, and whether the purchase stayed within those limits.
That pushes the problem beyond fraud detection into payments architecture, identity and permissions, AI governance, system integration, and the audit trail that connects them. Those controls need to work across live ecommerce systems and survive the handoffs between agent, merchant, payment provider, and risk systems.
That is where architecture and engineering discipline start to matter. Clear permission models, traceable agent actions, and well-designed integration points can make agent-mediated commerce easier to govern without treating every automated interaction as suspicious.
If you’re evaluating how agentic commerce changes the controls around checkout, authorization, and fraud, we can help map the architecture and governance needed to support it.
Related perspective
Agentic commerce changes what merchants need to verify before approving a transaction. 5 Ways AI-Weaponized Returns Fraud Is Turning Refunds into an Attack Surface follows the risk into the post-purchase journey, where agent permissions and automation can complicate returns and refund decisions.
