Agentic Tokens

An agentic token is a scoped digital payment credential issued for an AI agent. It represents an underlying card, with embedded rules about how, where, and by which agent it may be used. Agentic tokens are tangible or digital markers of autonomy and empowerment that enable AI agents to execute tasks or transactions within predefined parameters.

An agentic token limits the scope of the credential by binding it to the user's mandate and consent. It may capture agent identity, spend limits, time windows, and merchant or category restrictions. Agentic payments use scoped credentials instead of typed card numbers, and agentic tokens allow delegating decision-making while preserving user control.

Agentic tokens can reduce friction and anxiety in risk and trust by providing clear boundaries. They also provide a concrete signal that an individual- or, in this case, an agent-has the authority to make decisions within those boundaries.

Agentic tokens issued through a card network program, such as Mastercard Agent Pay or Visa Intelligent Commerce, are themselves network tokens. They aren't a layer above network tokens. A network token is a substitute for the underlying card PAN, subject to network usage controls. Card-on-file (COF) and device tokens are different use cases of the same technology: they are typically bound to a specific merchant or device to support repeat payments the cardholder has already authorized. An agentic token operates within an agentic payment framework that associates the credential with agent identity, user authorization, and purchase constraints through supported records and controls. These don't need to be embedded in the token itself. For example, passkeys can authenticate the user, but the token doesn't carry the passkey.

A vault token is different. It is a provider-specific alias resolved by that vault. It is meaningful within the provider's environment, and it isn't a network-issued credential. Some vaults and orchestration platforms offer an agent-facing alias that can map to one or more underlying network tokens, with the platform selecting one at runtime based on routing logic. That is one possible implementation, not a universal design, and it doesn't mean tokens are portable across processors. Lifecycle updates, such as automatic card updates, depend on issuer and program support.

A virtual card is a card number (PAN) issued with controls such as a spending limit, an expiration date, or a merchant lock, and it can be single-use or reusable. On its own, it still means the agent handles a card number, which can end up in prompts, agent memory, logs, and observability traces.

An agentic token is a network token that replaces the underlying funding PAN. It operates within an agentic payment framework that associates the credential with agent identity, user authorization, and purchase constraints through supported records and controls. Merchants and issuers can then see that an agent is acting, whereas a standard virtual card payment doesn't signal that. Transaction-specific validation data is provided as required by the network and flow, and token use can be logged with the agent ID and mandate for audit and dispute resolution.

The two aren't mutually exclusive. An eligible virtual card can itself be tokenized for agentic use, so virtual card controls and agentic token scope can work together.

Generally, yes, but tokenization doesn't determine merchant of record (MoR). The MoR is the entity that sells the goods and collects payment, typically the merchant or aggregator. The agent acts on the consumer's behalf, so using an agentic token doesn't change who the seller is. The exception is when an agent platform or marketplace is itself the seller, in which case it may be the MoR. This depends on the specific program and contracts.

Tokenization also doesn't establish PCI compliance on its own. Qualifying EMV tokens can reduce PCI scope, because the merchant stores and passes a token rather than the card PAN. But systems that handle account data, or that are connected to an environment that does, can remain in scope.

These are two separate checks, and agentic commerce relies on three things working together: the token, a verifiable agent identity, and user ID&V.

• Recognizing the agent. Recognizing a signed agent request indicates that a known agent is making it. It doesn't prove the user authorized this particular purchase. Visa's Trusted Agent Protocol (part of Visa Intelligent Commerce) uses signed, time-limited agent-to-merchant requests, and Mastercard Agent Pay makes agent involvement recognizable.
• Verifying the user's authorization. This is a separate check. It depends on user ID&V and on records of what the user authorized. Mastercard's Verifiable Intent framework links consumer identity, the authorized instructions and constraints, and the resulting purchase. Visa's protocol supports separate signed objects for consumer recognition (which can include an ID token) and for payment.

Network tokens are also validated at authorization. Applicable Visa cardholder-initiated token authorizations need fresh cryptograms, while properly classified subsequent merchant-initiated transactions omit them. Token use can be logged with the agent ID, consumer mandates, and ID&V, giving security teams an audit trail for fraud investigations and dispute resolution.

Mandates and intent are the user's recorded authorization for what the agent may do. They include, but aren't limited to:

• Spend limits
• Merchant or category restrictions
• Time frame or time windows
• Agent identity

Depending on the network and implementation, these may be linked to the credential through separate signed mandates, intent records, and server-side controls, rather than being embedded in the token itself.

The credential operates within an agentic payment framework that associates it with these records, allowing the agent to make decisions while the user retains control.

Depending on the network and implementation, agentic tokens can be scoped by merchant, category, amount, and time window, and can be tied to a specific agent identity and its session data. These controls may be applied through supported records and server-side controls rather than within the token itself. The token can be revoked centrally without affecting the underlying card or account.

These limits only help if they're enforced at the payment boundary. If they are, a stolen token is much harder to misuse beyond its intended scope. It may still be usable within its allowed limits, so the limits reduce exposure rather than eliminate it.

Tokens can be scoped by merchant, category, amount, and time, limiting exposure if compromised, and can be revoked centrally without affecting the underlying card or account. Provided limits are enforced at the payment boundary, a stolen token is far harder to misuse beyond its intended scope, though it may still be usable within its allowed limits.

Not directly. The agentic network tokens discussed here represent card credentials and cannot themselves authorize an ACH transfer or stablecoin payment.

Broader agentic payment frameworks can support non-card methods through separate integrations. ACH requires the appropriate bank-payment authorization and processing flow; stablecoin payments require an authorized wallet or signing service. Identity and consent evidence may be reused where supported, but each rail still needs its own payment credentials and controls.

Yes, VGS provisions agentic tokens across three major card networks, including Visa, Mastercard, and American Express. VGS has spent years building that foundation as a token service provider and vault, and it's why networks and platforms trust us to bring agentic payments to production with agentic tokens. If you're building an AI shopping agent, an agentic checkout experience, or a merchant platform that agents will transact with, we're happy to discuss agentic tokens with you.