AI Agents and PCI DSS: Keep Card Data Out of Agents

The fastest way to pull a chatbot, its model provider, its logs and its vector store into PCI DSS scope is to let a customer type a card number into it. Support assistants, voice agents and back-office agents increasingly sit next to payment flows, and every place a primary account number (PAN) lands, from a prompt to a transcript to a tool result, becomes part of the environment an assessor will ask about. The PCI Security Standards Council (PCI SSC) has now said plainly that AI is treated like any other technology when scoping. This guide covers how to keep card data out of agent context: scope decisions, tokenisation and payment handoff patterns, redaction at every hop, agent credentials and logging, and what an assessor will want to see. It is written for payment security leads, AI platform owners and QSAs reviewing AI use. Scoping in general is covered in the PCI DSS Scoping and Network Segmentation Guide; this page applies it to agents.

Key takeaways

AI gets no special scoping rules. PCI SSC's 2026 information supplement says AI should be considered no different from any other form of technology when deciding which requirements apply.
Design so the model never sees a PAN. Hand payment entry to a validated payment component and give the agent only a token, a masked number or a payment status.
Redact at every hop, not just the output. User input, speech-to-text transcripts, tool results, retrieval chunks, traces and analytics exports each need their own control.
PCI SSC's AI principles are the design brief. No unprotected sensitive data, least privilege with use-case-specific credentials, logged and monitored actions, an easy off switch, and treating the AI as a potential malicious insider.
Assume card data will leak in anyway. Customers paste numbers unprompted, so detection and a response for PAN found where it should not be (Requirement 12.10.7) are as important as the happy path.

Where card data meets agents

Agents encounter account data in more ways than the obvious checkout flow. Each entry point needs a decision before launch.

Entry point	How card data arrives	Systems pulled into scope if unmanaged
Customer chat	Customer types a PAN, expiry and security code to "just pay" or dispute a charge	Chat front end, conversation store, model provider, logs, analytics
Voice agent	Customer reads card details aloud; speech-to-text produces a transcript	Telephony platform, recordings, transcription service, transcript store
Tool results	An agent calls a payments, order or CRM API that returns full PAN	Agent runtime, context window, traces
Retrieval	Tickets, emails or documents containing card numbers are indexed for RAG	Vector database, embedding pipeline, source connectors
Back-office agents	Agents reconcile settlements, handle chargebacks or triage fraud alerts	Agent identity, the systems it reaches, its outputs
Coding and operations agents	Agents with access to production databases, logs or the cardholder data environment (CDE)	The agent and every credential it holds

PCI DSS applies to entities that store, process or transmit cardholder data and also to anything that could impact the security of the CDE. An agent with credentials into the CDE is in scope even if it never displays a card number, because it can affect CDE security.

Scope decisions: three patterns

Pattern	How it works	Scope effect	When to choose it
1. Out of band (preferred)	The agent hands the customer to a hosted payment page, secure payment link, in-app wallet or telephony payment capture (for example DTMF masking) run by a validated payment provider; the agent receives only a token or a success or failure status	Agent stack can stay out of the CDE, subject to confirming no PAN reaches it and the agent cannot affect the payment component	Almost always for customer-facing chat and voice
2. Tokenised in context	The agent works with tokens, last four digits or masked PANs from the payments system; detokenisation stays inside the CDE and is never a tool the agent can call	Agent stack likely connected-to or security-impacting rather than CDE, depending on what it can reach	Back-office agents handling refunds, disputes and reconciliation
3. Agent in the CDE	The agent stores, processes or transmits full PAN, for example to key transactions	Model hosting, context, logs, vector stores and every connected system are in scope for the full standard	Rarely justified; requires full requirement coverage, including for third-party model providers

Whichever pattern you choose, document it in the annual scope confirmation required by Requirement 12.5.2 (every six months for service providers under 12.5.2.1), including data flows through prompts, model APIs and logs. See the PCI DSS SAQ Types guide for how payment page choices affect self-assessment eligibility.

What PCI SSC has said about AI

PCI SSC has published three pieces that shape agent design. All are guidance; where they differ from a PCI standard, the standard prevails.

AI Principles (blog, 11 September 2025): AI systems "must be deployed and managed in compliance with applicable PCI SSC requirements". They should not be "trusted with high-impact secrets or unprotected sensitive data", "provided with access to systems and information not required for their operation", or implemented "with full agency over the creation and deployment process chain without a human-in-the-loop". They should be "provided with access to account data only when it is suitably protected", deployed so their actions "can be logged and monitored", "implemented so that they can be easily disabled if required", "protected against malicious input and malformed output", "provided with limited, use case, and context specific credentials", and "considered as a potential 'malicious insider'" in threat analysis and incident walk-throughs. They may be given access to protected payment data and may autonomously perform fail-secure actions.
Security Considerations for AI Systems (information supplement, announced 15 September 2026): covers AI deployment and use, defending against malicious use of AI, how PCI standards apply to AI and use-case examples, and states that AI should be treated like any other technology when scoping.
Integrating Artificial Intelligence in PCI Assessments, Guidelines v1.0 (March 2025): for assessors: AI is described as a tool, not an assessor; humans remain accountable for findings, and assessors should tell clients when AI is used and obtain consent. Expect your QSA to ask how you use AI and to disclose how they do.

Keeping PANs out of prompts, transcripts and retrieval

Redaction must run before data reaches each component that is meant to stay out of scope. A single output filter is not enough because the prompt has already been sent to the model provider and stored in logs by then.

Front-end interception: detect card-number patterns in the chat widget or app before submission (digit sequences of PAN length that pass a Luhn check, with tolerance for spaces and dashes typed by the customer) and replace them, then tell the customer to use the secure payment option.
Voice capture: use payment capture that suppresses card digits from the audio path and recordings, so transcription never sees them. Pause recording and transcription during payment if digits must be spoken.
Gateway redaction: run a second detector in the AI gateway or proxy in front of the model API, so anything missed at the edge is masked before leaving your environment.
Tool result filtering: make payment and order tools return tokens or PANs masked in line with your Requirement 3.4.1 masking design, never full numbers.
Retrieval hygiene: scan sources before indexing and exclude or mask card data; a vector store full of tickets with pasted card numbers is stored account data.
Logging and tracing: apply the same masking to traces, evaluation datasets and analytics exports; observability tools are a frequent blind spot.
Never sensitive authentication data: card verification codes and full track data must not be retained after authorisation (Requirement 3.3.1 and sub-requirements such as 3.3.1.2 for the card verification code). Conversation stores that keep a typed security code breach this outright.

Treat the redaction service as a security function: its rules, tests and false-negative rate are evidence. See the Payment Card Data Elements guide for which data elements are which.

Agent identities, credentials and access

Agents near payment systems use system and application accounts, which PCI DSS v4 now addresses directly. Map the AI principles onto the requirements:

Control	PCI DSS v4.0.1 requirement	Agent implementation
Least privilege for system accounts	7.2.5 (and periodic review, 7.2.5.1)	One identity per agent and use case, with access only to the tools and data it needs; no detokenisation rights
No interactive use of system accounts	8.6.1	Agent service identities cannot be used by people to log in interactively, except under documented exception
No hard-coded secrets	8.6.2	No API keys in prompts, agent configuration files or code; use a secrets manager or workload identity
Protected, rotated credentials	8.6.3	Short-lived tokens and rotation based on targeted risk analysis
Access reviews	7.2.4	Agent identities included in the six-monthly account and privilege review
Third-party providers	12.8 (12.8.1 to 12.8.5)	Model providers, agent platforms and transcription services that could touch account data or affect CDE security managed as third-party service providers, with a responsibility matrix

See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) and the PCI DSS for Service Providers and Responsibility Matrix Guide. For agents that pay on a user's behalf, use scoped, single-purpose payment credentials rather than reusable card numbers, as covered in the Agentic Commerce Identity Guide.

Logging, monitoring and detection

Log agent actions: PCI SSC's principles call for AI actions to be logged and monitored. For agents with CDE access, Requirement 10.2.1 and its sub-requirements apply: access to cardholder data, administrative actions, access to audit logs, invalid logon attempts and changes to credentials.
Automate review: Requirement 10.4.1.1 expects automated log review. Feed agent tool calls and identity events into the same pipeline, and alert on detokenisation attempts, bulk queries and new destinations.
Detect PAN where it should not be: run regular data discovery across conversation stores, transcripts, vector databases, traces and model provider logs you control. Requirement 12.10.7 requires incident response procedures when stored PAN is found anywhere it is not expected.
Canary card numbers: seed test card numbers into systems the agent can reach and alert when they appear in prompts, outputs or egress, as described in the AI Agent Honeytokens and Canaries guide.
Kill switch: the principles say AI should be easy to disable. Test that you can stop an agent and revoke its credentials quickly without breaking payment processing.

Metrics

Metric	Target
PANs detected in out-of-scope stores per month (conversation logs, transcripts, traces, vector stores)	Zero after remediation; every finding handled under 12.10.7
Redaction false-negative rate in quarterly testing with synthetic card numbers	Zero on standard formats; tracked trend on edge cases
Payment interactions completed out of band	100% for customer-facing agents
Agent identities with use-case-specific credentials and a review in the last six months	100%
AI providers with a documented PCI responsibility split	100% of those that could touch account data

Rolling it out

Inventory: list every agent and AI feature near payments, with data flows, providers and credentials.
Decide the pattern: choose out of band, tokenised or in-CDE for each, and record the rationale and scope result.
Build the handoff: integrate a validated payment page, link or telephony capture and make the agent consume only status and tokens.
Layer redaction: front end, gateway, tool results, retrieval and logs, then test with synthetic card numbers in all common formats.
Clean history: discover and purge card data already in conversation stores, transcripts and indexes, and handle findings as incidents.
Pilot: run with a small customer cohort and daily data discovery before wider release.
Roll back safely: keep the previous human or IVR payment path available and switch agents off if detection finds leakage.
Evidence: prepare data flow diagrams, redaction test results, responsibility matrices and logs for the assessor.

Decision guidance by organisation type

Small merchants using a hosted chatbot: keep payments entirely with the payment provider's hosted page or link, turn on any card-number masking the chat platform offers, and confirm in writing that the chatbot vendor does not retain transcripts with card data. The aim is to keep the self-assessment simple and the chatbot out of scope.
Large merchants with contact centres: the voice channel is the hard part. Prioritise payment capture that keeps digits out of recordings and transcripts, then extend redaction to the AI gateway and analytics. Expect the QSA to sample transcripts.
Service providers and payment facilitators: agents operating inside the CDE for operations or fraud work need the full control set, six-monthly scope confirmation and a clear statement to customers about which AI providers touch account data.
Organisations building their own agents: make the tokenised pattern the platform default, so product teams cannot wire a full-PAN tool into an agent without a security review.

Framework mapping

Area	PCI DSS v4.0.1	NIST CSF 2.0	OWASP
Scope and data flows	12.5.2	ID.AM-07	None specific
Keep sensitive data out of prompts and outputs	3.3.1, 3.4.1	PR.DS-01, PR.DS-02	LLM02 Sensitive Information Disclosure
Agent least privilege and credentials	7.2.5, 8.6.1 to 8.6.3	PR.AA-05	LLM06 Excessive Agency
Malicious input	Requirement 6 secure development	PR.PS-06	LLM01 Prompt Injection
Logging and monitoring	10.2.1, 10.4.1.1	DE.CM-09	None specific
Unexpected PAN response	12.10.7	RS.MA-01	None specific

Common failure patterns

Output-only redaction: masking the reply while the full PAN has already gone to the model provider and into logs.
Forgotten transcripts: voice agents whose speech-to-text output or call recordings hold spoken card numbers and security codes.
Tools that return full PAN: an order lookup API built for internal staff reused by an agent, pulling the agent runtime into the CDE.
Detokenisation as a tool: giving the agent a "reveal card" function for convenience, which defeats tokenisation entirely.
Observability blind spots: traces, evaluation datasets and prompt caches holding card data outside every data discovery scan.
Model providers missing from the TPSP list: no responsibility matrix for an AI provider that receives prompts which could contain account data.

Practitioner checklist

Inventory every agent and AI feature that could see account data or affect CDE security.
Route all customer payments out of band and give agents only tokens, masked PANs or status.
Block sensitive authentication data from ever being stored in conversation, transcript or log stores.
Apply redaction at the front end, gateway, tool results, retrieval pipeline and logs, and test it quarterly.
Remove detokenisation and full-PAN tools from agent tool lists.
Give each agent a use-case-specific identity, secrets from a vault, and include it in six-monthly access reviews.
Add AI and transcription providers to the TPSP inventory with a responsibility matrix.
Run data discovery for PANs across agent stores and handle findings under Requirement 12.10.7.
Document agent data flows in the annual (or six-monthly) scope confirmation.
Test the agent kill switch and fallback payment path.

AI Agents and PCI DSS: Keeping Card Data Out of Agent Context