PCI DSS Scope for Agentic Commerce: Agent Tokens, Delegated Credentials and Your CDE

PCI SSC has not published guidance specific to AI agents making card payments, so PCI DSS scope for agentic commerce still follows the old rule. Any system that stores, processes or transmits cardholder data, or can affect its security, is in scope. The practical question is whether your agent ever sees a raw PAN. If it only carries network or agentic tokens, scope can stay small.

Everything below is our reasoned reading of PCI DSS v4.0.1 applied to new payment flows. It is not official Council guidance, because there isn’t any yet on this topic. Treat it as a starting point for the conversation with your QSA and acquirer, not a substitute for it.

Has PCI SSC published anything on AI agents and payments?

Some AI guidance, yes. Agentic payment guidance, not yet.

• September 2026: the Council published an information supplement, Security Considerations for AI Systems. It covers how organisations deploy AI, defending against malicious use of AI, and how AI fits PCI scoping. The headline line for scoping: AI should be considered no different from any other form of technology when scoping PCI requirements.
• 8 October 2026: the Council announced additional guidance on securing AI in payment environments, developed with its Global Executive Assessor Roundtable and Board of Advisors. It is explicitly not a mandatory requirement, and the standard takes precedence where they differ.
• 20-22 October 2026: the PCI SSC Europe Community Meeting in Edinburgh lists sessions including “AI Agents and Emerging Risks in the Cardholder Data Environment” and “Human vs. Machine: Rethinking Security, Compliance, and Accountability”.

None of these, as far as we can find, tells you how to scope an agent holding a delegated card credential. That gap is what this post is about.

What are agent tokens and delegated credentials?

The card networks have converged on a similar idea: the agent never holds your card number. It holds a token tied to that agent, created with the cardholder’s consent.

• Visa describes AI agents setting up a new payment token on the cardholder’s behalf, with Visa Payment Passkeys used to authenticate the cardholder at that moment. Its Agentic Ready programme is built on this.
• Mastercard issues Agentic Tokens through Agent Pay, again tokenized credentials registered for a specific agent.
• Checkout protocols such as ACP and AP2 pass a scoped payment credential or a signed mandate rather than a PAN. Our sister practice covers the mechanics in its AP2 protocol guide and agentic payment protocols comparison.

Then there’s the messy reality: plenty of “agents” today are just browser automation filling in a checkout form with a stored card number. Those are a completely different scoping story.

How does each agentic payment pattern affect your CDE?

Here’s the scoping model we use. Read “in scope” as “likely in scope, confirm with your QSA”.

The last row catches more teams than any other. A support or shopping agent that never “handles payments” by design can still end up with card numbers in its conversation history, observability traces and fine-tuning datasets. Once that happens, every system those records flow through is handling cardholder data, whether or not anyone designed it to. The cheapest fix is at the front door: detect PAN-shaped input and redact it before it reaches the model or the logs.

Do agent tokens actually take you out of scope?

Mostly, with one caveat that matters. A network token is not a PAN, so holding one is not storing cardholder data. That’s the same logic that makes payment tokenization the strongest scope-reduction tool most UAE merchants have.

The caveat: PCI SSC’s long-standing tokenization guidance distinguishes high-value tokens, ones that can be used like a PAN to generate transactions, and warns they may remain in PCI DSS scope even though they can’t be reversed into card data. Agentic tokens are built to initiate payments. Network-side controls (agent binding, spend limits, cardholder authentication) reduce the damage a stolen one can do, but we’d still treat the token vault and the credentials that can spend from it as high-value assets with access control, logging and change management.

Which PCI DSS requirements bite hardest for agentic checkouts?

If you only have time to look at a handful, start here.

1. Requirement 3, stored account data. Make sure PAN and sensitive authentication data never land in prompts, model context, traces, evaluation datasets or embeddings. Add PAN detection and redaction at the input layer.
2. Requirement 8.6, system and application accounts. Agents act through service accounts and API keys. Inventory them, restrict interactive use, and rotate credentials as v4.0.1 expects.
3. Requirement 10, logging. Log what the agent did, which token it used, and the cardholder consent or mandate it acted on. You’ll want this for disputes as much as for the QSA.
4. Requirement 12.8, third-party service providers. Your LLM provider and agent platform are TPSPs if they can touch card data or affect its security. Know which, and get the responsibility split in writing.
5. Requirements 6.4.3 and 11.6.1. If agents interact with your payment pages, the script inventory and tamper detection still apply. Agent traffic doesn’t change who is responsible for the page.
6. Requirement 12.5.2, scope confirmation. Adding an agentic checkout is a significant change. Re-confirm and document scope, rather than waiting for the annual cycle.

How should you document agentic scope until guidance arrives?

Write it down, then get agreement from the people who accept your compliance. Concretely:

• A data flow diagram showing exactly where PAN, tokens, mandates and consent records travel, including the model provider and observability tools.
• A short scoping rationale per component: in scope, connected-to, security-impacting or out of scope, and why.
• Acquirer agreement. The August 2026 revision of FAQ 1331 made the point clearly in a related context: applicability decisions belong with your compliance accepting entity, not just you and your QSA. We cover that change in PCI FAQ 1331 Revised.
• A review trigger for when PCI SSC publishes agentic-specific guidance, so your rationale gets checked against it rather than silently going stale.

For UAE banks and PSPs, add a column for CBUAE expectations. The Central Bank’s client-side and consumer protection rules don’t pause because a purchase was agent-initiated.

Book an agentic payment-flow PCI scoping workshop

If you’re building or accepting agent-initiated payments, the cheapest time to get scope right is before the first transaction. Our agentic payment-flow PCI scoping workshop is fixed-scope: we map your agent, token and checkout flows end to end, classify every component against PCI DSS v4.0.1, flag where PAN can leak into prompts or logs, and hand you a written scoping rationale you can take to your QSA and acquirer.

It pairs naturally with our payment tokenization advisory and PCI DSS gap analysis. Get in touch to set up a session, ideally before the Community Meeting news cycle turns this into everyone’s urgent question.