Visa TAPTrusted Agent Protocol

What it is

Visa introduced Trusted Agent Protocol in October 2025 with more than ten partners, as an ecosystem-led framework built on existing web infrastructure rather than a new rail. The problem it addresses is unglamorous and immediate: merchants have spent two decades building defences that block automated traffic, and those defences do not distinguish a shopping agent working for a real customer from a scraper or a card tester.

The protocol standardises three classes of verifiable information passed to the merchant. Agent identity — an indication that this is a Visa trusted agent, with an intent to retrieve details about or purchase a specific product. Consumer recognition — loyalty tokens, device identifiers from prior interactions, location parameters, wallet addresses. And payment information — how the payment method is represented, whether as hashed credentials, tokens, or settlement details between agent and merchant.

The cryptographic property that makes it usable is that the signatures are specific to the merchant and the purpose, and time-bound: they cannot be replayed against another merchant or relayed later.

Where it sits relative to Intelligent Commerce

Visa Intelligent Commerce, announced in April 2025, is the payments programme: APIs that let developers embed payment functions — identity verification, consumer-set spending controls — into agents, with tokenised credentials underneath. TAP is the merchant-facing complement, adding transparency and merchant visibility to those transactions.

By mid-2026 Visa reported agents browsing, selecting and initiating purchases within consumer-defined limits at participating European merchants, running in production rather than in a sandbox. The consumer-defined limit is the load-bearing element in that sentence and, in the network model, it lives with the issuer and the token.

Why 'is this agent trusted?' is not 'is this purchase authorised?'

These are separate questions with separate failure modes, and the industry keeps eliding them. A perfectly identified agent, cryptographically attested and listed in every directory, can still propose a payment its principal never authorised: because it was prompt-injected, because it misread a page, because it hallucinated a supplier, or because the human who deployed it did not think through what it would do at 3am when a subscription renewal failed.

TAP makes the first question answerable at the merchant's edge. Nothing in it, or in any identity protocol, answers the second. The second is answered by evaluating a proposed action against an explicit statement of authority — which is a different system, run by a different party, on the delegator's side of the transaction.

What it does not do

• It is about admission and recognition, not about whether the underlying purchase is within the principal's authority.
• Trust is anchored in Visa's ecosystem: the useful signal is that an agent is a Visa trusted agent, which is a scheme-scoped assertion rather than a universal identity.
• Still described as in development and deployment, with availability varying by market.
• It addresses consumer commerce at merchant checkout. Business-to-business payment, where most of the money and most of the fraud sits, is not the target.

Where mnd8t sits relative to it