Network Tokens vs Agentic Tokens

Updated: 6 August 2026

What is the difference between a network token and an agentic token? A network token replaces a card number with a surrogate issued by the card network and works within the domain it was issued for. An agentic token uses the same rails but adds a binding to a named AI agent, to the permissions that agent holds, and to the cardholder’s documented instruction. The difference is not cosmetic: an agentic token carries information about who is transacting and within what limits, not only about which card is paying.

Canonical definition: An agentic token is a network payment token bound to a specific AI agent, a merchant scope and a cardholder consent record. A network token replaces the primary account number (PAN) without that agent binding.

Network tokens vs agentic tokens – in brief:

Network tokens are issued by the card networks through their own tokenisation services: Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES), under the EMVCo EMV Payment Tokenisation – Technical Framework.
Agentic tokens sit on top of that same infrastructure. Mastercard announced its Agent Pay programme with Mastercard Agentic Tokens on 29 April 2025, stating that the solution builds on proven tokenisation capabilities.
PSP tokens (vault tokens) are issued by a payment service provider or vault. They are not portable between providers, do not refresh when a card is reissued, and carry no transaction cryptogram.
Shared Payment Tokens (SPT) are the credential primitive in the Agentic Commerce Protocol, published by Stripe and OpenAI on 29 September 2025, scoped to a single merchant and a single cart total.
Under the Visa Core Rules effective 18 April 2026, an agentic transaction using a stored credential must use a token rather than a raw PAN.
No token type removes an organisation from PCI DSS scope automatically. The actual data flow decides, not the supplier’s claim.
Patronusec, an accredited QSA (Qualified Security Assessor), scopes payment environments built on network and agentic tokenisation, from gap analysis through to the Report on Compliance.

What is a network token and who issues it?

A network token is a surrogate for a card number, issued by a card network and restricted to a defined domain such as a merchant, device or channel. It is issued by the networks’ tokenisation services, and the technical framework is set by EMVCo. The token has no mathematical relationship to the card number and cannot be used outside its domain.

The core elements of network tokenisation architecture:

Token Service Provider (TSP) – the entity that issues the token and the only one that can map it back to the card number. In practice this means VTS at Visa and MDES at Mastercard.
Token Requestor ID (TRID) – the identifier of the entity that requested the token. It ties the token to a specific merchant or wallet and prevents another party from using it.
Domain restriction – the token functions only in the declared channel, at the declared merchant, or on the declared device.
Transaction cryptogram – a dynamic value generated per transaction, analogous to the EMV cryptogram used in card-present payments.
Payment Account Reference (PAR) – a data element that links tokenised transactions back to the same card without exposing the number itself. EMVCo has announced work to enhance PAR during 2026, including for co-badged card scenarios.

A network token keeps the credential current: when an issuer reissues a card or changes its expiry date, the token continues to point at the correct account. That property alone separates it from a surrogate generated locally by a merchant or its provider.

A network token is a payment credential issued by a card network and constrained by domain, not a private record identifier held in a merchant database.

What is an agentic token and what does it add to a network token?

An agentic token is a network token enriched with three additional layers: the identity of the AI agent, the scope of authority granted by the cardholder, and a link to the cardholder’s documented instruction. The merchant accepts it through the same authorisation flow as an ordinary network token, while the network additionally checks whether the transaction falls inside the granted limits.

Mastercard announced Agent Pay on 29 April 2025, introducing Mastercard Agentic Tokens built on the tokenisation capabilities that already support contactless, card-on-file and programmable payments. Mastercard’s product material describes a model in which only a registered agent may transact, with those actions remaining traceable through network tokens.

Visa runs a parallel track under Visa Intelligent Commerce. Its developer documentation describes a pass-through payment token specific to agents, intended for use across Visa-accepting merchant locations, alongside four integrated services: provisioning credentials bound to a particular agent, authenticating the user when an instruction is given, applying controls so that a payment request matches the original authenticated instruction, and collecting commerce signals that support dispute resolution.

The practical difference against an ordinary network token:

Layer	Network token	Agentic token
What it represents	the card	the card plus the agent’s authority
Who initiates	cardholder or merchant	AI agent acting on an instruction
Restrictions	merchant, channel, device	plus spend cap, merchant category, session lifetime
Source of consent	card-on-file agreement	documented cardholder instruction
Audit trail	token requestor identifier	agent identifier linked to the instruction

In card-scheme rules this model has stopped being optional. The Visa Core Rules and Visa Product and Service Rules effective 18 April 2026 created the Agentic Payment Provider and Agentic Payment Enabler categories and require that an agentic transaction on a stored credential uses a token obtained from Visa or from a registered enabler. We cover the obligations attached to both roles in our asset on Agentic Payment Providers and network tokens under Visa rules.

An agentic token differs from a plain network token in that it encodes authority to act, not merely a reference to an account.

How do PSP tokens and Shared Payment Tokens differ from network tokens?

A PSP token is issued by a payment service provider or vault, and only that vault can map it back to a card number. A Shared Payment Token is a single-use credential scoped to one merchant and one amount, used in agentic checkout protocols. Both solve a different problem from network tokens, which is why mature architectures run them alongside each other rather than as alternatives.

PSP (vault) tokens are created after a provider receives the card number and returns a reference. The benefit is a smaller number of merchant systems in contact with cardholder data. The cost is a lack of portability: moving to another provider usually means re-collecting card details from customers or migrating the vault through a specialist intermediary. A PSP token does not refresh after a card reissue and carries no transaction cryptogram.

Shared Payment Tokens (SPT) were introduced by Stripe with the release of the Agentic Commerce Protocol (ACP) on 29 September 2025, developed jointly with OpenAI. An SPT lets an agent application initiate a payment without seeing the buyer’s credentials and is scoped to a specific merchant and cart total. The related Delegated Payment specification on OpenAI’s side assumes that the payment service provider returns a token scoped to the delegated payment, and its documentation states directly that integrating with the specification involves handling cardholder data and may affect PCI scope.

The full taxonomy in one view:

Token type	Issued by	Usable scope	Refreshes on card reissue	Typical architectural role
Network token	card network (VTS, MDES)	merchant, channel, device	yes	reusable authorisation credential
Agentic token	card network	agent, merchant, limit, session	yes	credential for AI-initiated transactions
PSP (vault) token	payment service provider or vault	that provider’s ecosystem only	no	reduces systems in contact with card data
Shared Payment Token	payment service provider under ACP	one merchant, one amount	not applicable (single use)	passes payment from agent to merchant

The standardisation direction is worth noting. EMVCo stated in November 2025 that it is examining how EMV 3-D Secure, EMV Payment Tokenisation and EMV Secure Remote Commerce should evolve for agentic payments, naming consumer intent, trust in agent-initiated transactions and privacy-preserving interaction models as its opening focus areas.

How do you tell a payment token apart from an agent identity credential?

A payment token answers “what pays”. An agent identity credential answers “who is asking”. These are separate artefacts, carried in different layers of the transaction and verified by different parties. Conflating them creates control gaps, because the team assumes a single verification covers both risks.

Four objects that people routinely call by the same word:

Payment token – a network token, agentic token, PSP token or SPT. It represents a payment instrument and is processed in the authorisation layer.
Agent identity credential – under the Visa Trusted Agent Protocol (TAP), introduced on 14 October 2025, an agent signs HTTP requests using the HTTP Message Signatures standard, and the merchant verifies that the traffic comes from a registered agent. Visa describes the vetting process behind it as Know Your Agent.
Access token (OAuth) – in ACP this delegates the agent’s authority to act on the buyer’s account with a business. It is not a payment instrument.
Language-model token – a unit of text processed by an AI model and billed by the model provider. It has nothing to do with card payments, yet it appears under the same word in design documents.

In practice, verifying an agent’s signature does not replace control over the payment credential, and a valid payment token does not prove that the request comes from an agent the user instructed to do anything.

An agent identity credential proves who is acting. A payment token proves which instrument pays. A defensible architecture needs both, verified independently.

Do agentic tokens take an organisation out of PCI DSS scope?

Not automatically. Scope is determined by whether your systems store, process or transmit cardholder data, or could affect its security. A token removes a system from scope only where that environment cannot map it back to a card number and where the card number never flows through that environment at any stage.

Four questions that settle the cardholder data environment boundary:

Do your systems see the card number at provisioning? The provisioning step is frequently omitted from scoping analyses, yet it is precisely where the full PAN usually appears.
Do you hold detokenisation capability? Access to the mapping function places a system in scope regardless of how rarely you use it.
Does the token reach components that could affect cardholder data security? The agent orchestrator, prompt logging layer and vector store are all systems your assessor will ask about.
Has the supplier provided evidence rather than a claim? An assertion about simplified questionnaire eligibility needs confirmation in the supplier’s Attestation of Compliance and responsibility matrix, not in marketing material.

PCI DSS v4.0.1 remains the only active version of the standard, and the requirements previously marked as future-dated have applied since 31 March 2025. An agentic environment designed today is therefore assessed against the full set of requirements, with no transition period left to rely on.

Patronusec Insight: The most persistent misconception we meet in scoping engagements is that tokenisation reduces scope by itself. It does, but only for an entity that genuinely holds neither the card number nor the detokenisation function. Agentic environments add a second problem: card data can leak not through a database but through a model’s reasoning trace, a tool-call log or context passed to an external model provider. The question your assessor asks is “where is this token visible, and who can turn it back into a card number?” If you are building an agentic platform and do not yet have a PCI DSS gap analysis that explicitly covers token handling and model telemetry, your scope definition is almost certainly incomplete.

Which PCI DSS requirements apply to AI systems that initiate payments?

Using AI removes no requirement of the standard. PCI SSC published a set of principles for AI systems in payment environments on 11 September 2025, opening with an absolute rule: an AI system must be deployed and managed in compliance with applicable PCI SSC requirements, and the complexity of a model does not remove the obligation to meet them.

Those principles map onto the properties of an agentic token:

Agentic token property	PCI SSC principle for AI systems	Related PCI DSS area
Spend cap, merchant category, lifetime	access to account data only in suitably protected form, with usage limits	Requirement 3 and Requirement 4
Binding to agent identity	limited, use-case and context-specific credentials	Requirement 7 and Requirement 8
Logging of agent actions	actions logged and monitored, with a named individual responsible	Requirement 10
Ability to revoke the token	system that can be easily disabled	Requirement 8 and Requirement 12
Resistance to instruction manipulation	protection against malicious input and malformed output	Requirement 6 and Requirement 11
Isolation of the agent environment	separation of operational environment and user data	Requirement 1

Three principles deserve separate attention, because they change how an agentic platform is designed:

An AI system cannot accept responsibility. PCI SSC states that roles requiring formal acceptance of responsibility, including management-level approvals and key custodian duties, are unsuitable for AI systems. A named individual answers for the agent’s actions.
An AI system is not trusted with high-impact secrets. PCI SSC places API access tokens, user credentials and cryptographic key material explicitly in that category.
The agent is treated as a potential malicious insider. PCI SSC recommends covering that scenario in threat analysis and incident response walk-throughs, which maps to Requirement 12.10.

Read in that light, the agentic token is the mechanism PCI SSC describes as an acceptable way of giving AI access to payment data: data in protected form, with limits on amount, frequency, merchant and credential lifetime.

What do practitioners usually get wrong about token types?

The common mistakes rarely come from a lack of technical knowledge. They come from using one word for four different objects. The errors below recur in scope documentation, responsibility matrices and supplier conversations.

❌ Treating every “token” as the same object – a language-model token, an OAuth access token, a network token and an agentic token serve disjoint functions and attract different controls.

❌ Assuming a network token removes you from PCI DSS scope – scope follows access to the card number and the detokenisation function, not the mere presence of a token.

❌ Conflating agent identity with the payment credential – a verified agent signature says nothing about authority to charge a card, and a valid token does not confirm who is presenting it.

❌ Assuming PSP tokens are portable – a token issued by one provider is useless outside that provider’s vault, which turns a change of provider into a credential re-collection exercise.

❌ Storing a Shared Payment Token for later – an SPT is scoped to one merchant and one amount, and the implementation pattern assumes an immediate charge with no credential retention.

❌ Leaving model telemetry out of the scoping exercise – prompt logs, tool-call traces and context stores can hold data that appears in no production database.

FAQ – Network tokens vs agentic tokens

Is an agentic token the same as a network token?

Not entirely. An agentic token runs on network tokenisation infrastructure and behaves like a network token at the merchant, but it additionally binds the credential to an AI agent’s identity, a scope of authority and a cardholder consent record. A plain network token represents the payment instrument only.

Who issues network tokens?

The card networks, through their own tokenisation services: Visa Token Service at Visa and Mastercard Digital Enablement Service at Mastercard. The technical framework comes from EMVCo’s EMV Payment Tokenisation specification. A payment service provider may request a token on a merchant’s behalf, but it does not issue one.

How does a PSP token differ from a network token?

A PSP token is issued by a payment service provider, and only that vault can map it back to the card number. It is not portable between providers, does not refresh after a card reissue, and carries no transaction cryptogram. A network token is issued by the card network and works across the acceptance network.

Can an agentic transaction use a raw PAN?

No, where the Visa agentic payment rules effective 18 Apr 2026 apply. A transaction on a stored credential requires a token obtained from Visa or from a registered Agentic Payment Enabler. Using a raw card number in an agentic transaction breaches the rules.

Does tokenisation remove the need for a PCI DSS assessment?

No. Tokenisation can materially reduce the number of systems in scope, but the obligation to validate compliance remains. If your environment sees the card number at provisioning or holds detokenisation capability, it stays in scope under PCI DSS v4.0.1 whichever token type you use.

How does Patronusec help define PCI DSS scope in an agentic environment?

We start with a data-flow map covering token provisioning, the agent orchestration layer and model telemetry, then test it against PCI DSS v4.0.1. As an accredited QSA we provide a fixed quotation following a no-obligation scope assessment call.

Blog space

Network tokens vs agentic tokens – 4 token types and the differences that decide your PCI DSS scope

In this article you will learn:

Table of Contents