Data Report · RedactSure Research
Can an AI Agent Touch Cardholder Data Without Expanding PCI Scope? Reading the Scoping Rules Against the New Reader
Scope is the assessor’s call, and the architecture decides how that call goes. Under the PCI Security Standards Council’s scoping guidance, systems that store, process or transmit cardholder data are in scope, and so are systems connected to them in ways that could impact their security. An AI tool that ingests screens containing primary account numbers has entered that analysis on the wrong side. An agent architecture in which card values become consistent tokens (CARD_001, ACCT_001) at the render, before any model reads a screen, keeps the PAN out of model context, out of the AI vendor’s readable systems and out of the logs, which gives the qualified security assessor a short analysis instead of a long one. No vendor determines scope, this one included; what an architecture can do is make the assessor’s question easy to answer. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Key findings
- The scoping test is functional, not intentional: store, process or transmit cardholder data, or the ability to impact the security of systems that do. A tool’s marketing category is irrelevant to it; its data flows are everything.
- The payments industry already ran this playbook. The Council’s own tokenization guidance formalized replacing the PAN with a stand-in wherever the real value is not required, and concentrating real values into hardened vaults is how the industry shrank its exposure a decade before AI.
- An AI model that reads full operations screens becomes a processor of whatever those screens contain, and every log, retention system and subprocessor behind it inherits the question.
- Consistency is what keeps tokenized operations workable: CARD_001 on the dispute screen matches CARD_001 in the case history, so investigation and reconciliation proceed without the model holding the PAN.
- The consequential actions in payments workflows, posting an adjustment, submitting a dispute response, releasing a refund, gate on a named person under Supervised Delegation, which is where card operations always kept their controls.
How does PCI scoping actually work?
The scoping guidance organizes the world into three populations. The cardholder data environment: people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data. Connected-to and security-impacting systems: in scope because they touch the CDE or could affect its security, even without holding card data themselves. And out-of-scope systems: those with no access to the CDE and no ability to impact it, a status the guidance insists must be verified, not assumed.
Two properties of that structure matter for AI. Scope follows data flows wherever they go, including into services the organization did not think of as payment systems; the guidance’s persistent theme is that organizations under-scope by forgetting where the data travels. And scope is contagious through connectivity: a system that can reach into the CDE is in the analysis even if no PAN ever rests on it.
Now place an AI tool into the structure. A staff member works a dispute queue with an AI assistant that reads the screen, and the screen carries the PAN, the transaction detail and the cardholder’s identity. The model received the data, so it processed it; the vendor’s infrastructure transmitted and possibly stored it; the prompt logs may retain it. Each of those facts is a scoping fact. Whether the tool was marketed as a productivity assistant does not appear anywhere in the test.
What did payments already learn about tokens?
The payments industry is the birthplace of the fix, which gives this vertical an advantage the others lack: its assessors already understand tokenization natively.
The Council’s tokenization information supplement laid out the pattern years ago: replace the PAN with a token wherever the real value is not required, keep the vault that maps tokens to values small and hardened, and evaluate the surrounding systems by what they actually hold. Merchants and processors rebuilt their operations around it, and the industry’s exposure concentrated into a defensible core.
Render-layer tokenization applies the same pattern at a layer the payments version never had to cover, because until recently no software read operations screens. The staff-facing systems, dispute consoles, case management, reconciliation tools, service portals, render inside a governed environment, and card values become consistent tokens before any model reads them. The full mechanism, including the payments lineage, is described in What Is Render-Layer Tokenization?; the scoping-relevant property is a single sentence: the PAN never enters model context, and the AI vendor stores ciphertext it cannot decrypt, with the customer holding the keys.
What does the analysis look like, workflow by workflow?
| Payments workflow | What the screens contain | What the model reads under tokenization | Where a real value appears |
|---|---|---|---|
| Dispute investigation | PAN, transaction detail, cardholder identity | Transaction facts keyed to CARD_001 and USER_001 | Nowhere in the AI path; the analyst sees systems of record as today |
| Chargeback response assembly | Case history, evidence documents | The evidence set under consistent tokens | In the submission at the network portal, on the analyst’s approval |
| Refund and adjustment preparation | Account references, amounts | Amounts in clear; account references tokenized | In the posting at the payment system, on approval |
| Reconciliation and exceptions | Settlement files, transaction listings | Amounts, dates and status in clear; card references tokenized | Nowhere in the AI path |
| KYC and onboarding review | Identity documents, account applications | Application facts under tokens per policy | In the system-of-record entry, on approval |
The pattern the table shows the assessor: the AI path holds no PAN at any point, the resolution events land at destinations that were already in the CDE analysis, and the model’s logs, the usual scoping surprise in AI deployments, contain tokens end to end. The QSA still draws the boundary, verifies the segmentation and tests the claims; the difference is what there is to find.
The contrast case is worth stating as plainly. An AI deployment in which models read raw operations screens has created a new processing path for cardholder data through the model vendor’s infrastructure, and the honest scoping response is to treat that path as in scope, with everything that follows: the diligence, the attestations, the assessment surface. Organizations discovering this after deployment are re-learning the lesson the scoping guidance has taught for a decade, that scope follows the data, not the org chart.
Where do the controls sit?
Card operations never lacked control discipline; the question is whether the AI inherits it. Under Supervised Delegation, it does, and in the shape payments already uses.
The named person is the analyst who owns the queue. They confirm the exposure policy, field by field, before the workflow runs; they can watch any run; and the consequential actions, the chargeback response leaving for the network, the adjustment posting, the refund releasing, wait for their approval, every time, on the record. The AI never pays, posts or decides. The run history and approvals export as tokens to the organization’s monitoring, which means the audit trail that payments compliance lives on gets a new, complete chapter that itself contains no cardholder data.
Under prompt injection, the attack class OWASP ranks first for LLM applications, an agent in this architecture gives up CARD_001. The fraud economics of stolen tokens that resolve only at approved destinations on approved actions are the point: there is nothing to sell.
What does the QSA conversation look like, prepared?
Scoping conversations go badly when the organization discovers its own data flows in the assessor’s questions. The prepared version of this conversation has the artifacts on the table before the questions arrive, and the list is short.
The data-flow statement: one page per AI workflow, showing what enters model context (the tokenized screen stream, with the field policy attached), where real values live (the enclaves, with the key-custody arrangement), and where resolution happens (the approved destinations, each already known to the CDE analysis). This is the AI version of the flow diagrams every assessment already requires, and producing it from the architecture takes an afternoon.
The payload sample: the actual model-bound content from one run on the organization’s own dispute or reconciliation workflow, not a vendor diagram. Assessors are professionally allergic to architecture slides; a captured payload showing CARD_001 where the PAN would be ends a line of questioning that slides prolong.
The log demonstration: a run history pulled from the SIEM, showing the token-only property of the record trail. The question behind the question, has this deployment created a new repository of cardholder data in the monitoring stack, gets answered by inspection.
The vendor attestation set: the AI vendor’s written statement of what its systems receive and store, the ciphertext-only custody, and the change-notification commitment, the same artifact structure the break-glass evaluation template prescribes for healthcare, because the diligence shape is identical across regimes.
An organization holding those four items has converted the scoping conversation from discovery into verification. The one it should still expect, and welcome, is the assessor testing the claims: sampling runs, inspecting the environment’s boundary, checking that the resolution destinations match the approved list. An architecture whose marketing survives testing is the only kind worth bringing to a compliance program, which is why every claim on this page is phrased as something a QSA can check.
What the record shows
Whether an AI agent expands PCI scope is decided by data flows the assessor can trace, and an architecture determines those flows before any assessment begins. An agent reading raw screens creates a new cardholder-data path through the AI vendor; an agent reading render-layer tokens does not receive the PAN at all, and the analysis concentrates on resolution events at destinations already inside the compliance program. The industry that invented data tokenization is the natural home for tokenizing the screen, the one layer its own playbook never covered because nothing but people ever read it. The claim an organization takes to its QSA is modest and checkable: here is what the model receives, here is where real values appear, here are the logs. Scope remains the assessor’s call. The architecture’s job is to make it an easy one. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
Does this take our operations out of PCI scope?
No architecture takes an organization out of scope, and no vendor’s statement substitutes for a QSA’s determination. What the architecture does is keep the AI path from adding scope, by keeping the PAN out of it entirely.
What about sensitive authentication data?
The same policy machinery covers it: fields the organization designates tokenize at the render. Data that PCI DSS forbids storing after authorization is not made storable by tokenization; the rule set governs the systems of record exactly as before.
Our processor already tokenizes transactions. Is this redundant?
Different layer, same philosophy. Processor and vault tokenization protect the transaction path and the integrated systems. The render layer protects the operations screens your staff and their AI assistance actually read, which processor tokenization never sees.
What does the model receive during a dispute investigation?
Transaction amounts, dates, merchant descriptors, case history and network rules in clear, because the reasoning runs on them; PAN, account references and cardholder identity as consistent tokens. The investigation logic survives intact because consistency is preserved.
Can the AI vendor’s staff see cardholder data in support scenarios?
Real values live in hardware-encrypted enclaves with customer-held keys; the vendor stores ciphertext it cannot decrypt, and its logs are tokens. The support-tooling question, which the scoping guidance would ask of any provider, has a short answer.
Who should evaluate this claim set?
The organization’s QSA and security team together, against the architecture directly: what enters model context, where resolution happens, what the logs hold. Each claim on this page is written to be tested that way.
Related reading
What Is Render-Layer Tokenization? · What Is Supervised Delegation? · What Is the PII Wall? · On the RedactSure blog: Payments Set the Gold Standard for Security. AI Just Moved the Bar.
Sources
Standards
- PCI Security Standards Council, “Guidance for PCI DSS Scoping and Network Segmentation.” https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
- PCI Security Standards Council, “Information Supplement: PCI DSS Tokenization Guidelines.” https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
- OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
RedactSure documents
- RedactSure, “Payments Set the Gold Standard for Security. AI Just Moved the Bar.” (2026). https://redactsure.com/blog/payments-security-in-the-age-of-ai/
- Product behavior described on this page reflects RedactSure’s current design. Scope determinations belong to the organization’s qualified security assessor.
Bring your hardest questions.
A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.
Book a security review Book a demo · Something elseAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.