Are AI Agents in PCI DSS Scope? The Test Isn't Whether They See Card Numbers
AI agents fall into PCI DSS scope when they can connect to or affect the security of the cardholder data environment, not only when they handle card data. PCI DSS scoping rules place any system that can access the CDE, or impact its configuration or security, in the connected-to and security-impacting category, where all applicable requirements apply.
A retailer books its annual PCI assessment. The scope document is in good shape: the payment application, the segmented CDE, the jump host, the logging infrastructure. Then the assessor asks whether the support team's AI assistant has been included. The room pauses. The assistant does not handle payments. It reads order history to answer customer questions, and order history lives in a database that also sits behind the segmentation boundary. Nobody has an answer, because nobody has ever written the assistant down anywhere.
That conversation is becoming routine, and it almost always runs the same way. The organization has assessed the AI system against the wrong test. In our PCI assessment work at Clone Systems, we consistently find that teams evaluate an AI assistant's scope by asking whether it can see a primary account number. The standard does not ask that question in isolation. It asks whether the system can reach the cardholder data environment or affect its security, and a system can do both without a card number ever passing through it.
The evidence that this is now a live problem rather than a theoretical one arrived this week. Mandiant published its AI Risk and Resilience report on September 16, 2026, developed with the Google Threat Intelligence Group [1]. Two findings from it are worth holding onto. In one red team exercise, an AI assistant with access to code repositories and CI/CD pipelines was manipulated into cloning sensitive internal repositories to an external account the testers controlled, abusing permissions it had been legitimately granted [1]. In a separate incident, a malfunctioning accounting agent made more than 15,000 high-cost API calls in under an hour, generating roughly $50,000 in cloud charges and disrupting operations [1]. Neither of those systems needed to touch account data to matter. Both would have been in scope under a correct reading of the standard, and neither would have appeared on a typical scope diagram.
What Actually Determines Whether an AI System Is in PCI DSS Scope?
Connectivity and security impact, not data handling alone. This is the whole argument, and it is settled in the standard's own scoping guidance rather than being a matter of assessor opinion.
The Three Categories the Standard Uses
The PCI Security Standards Council's guidance on scoping and network segmentation sorts every system component into one of three categories [2].
CDE systems store, process, or transmit cardholder data or sensitive authentication data, or sit on the same network segment as systems that do. These are fully in scope.
Connected-to and security-impacting systems are in scope as well, and the qualifying criteria are broader than most teams realize. A system lands here if it can connect to or access the CDE across network boundaries, if it can impact the configuration or security of the CDE or how account data is handled, if it provides security services to the CDE, if it supports PCI DSS requirements such as time or log storage, or if it provides the segmentation that isolates the CDE [2]. All applicable PCI DSS requirements apply to systems in this category.
Out-of-scope systems must satisfy every one of the following: they do not store, process, or transmit account data, they are not on the same network segment as systems that do, they cannot connect to or access any system in the CDE, they cannot gain access to the CDE through an in-scope system, and they meet none of the connected-to or security-impacting criteria [2].
Read that last list carefully. Out of scope is not a judgment call, it is a set of conditions that must all hold. Failing any single one puts the system in scope.
Why "It Never Sees a PAN" Is the Wrong Test
Because "does not store, process, or transmit account data" is one condition out of five, and it is the easiest one for an AI system to satisfy while failing the rest.
Consider a retrieval-augmented assistant that answers internal questions by querying a data warehouse. It never returns a card number, because the warehouse holds tokens. But the connector it uses authenticates with a service account, that service account has read access to schemas inside the CDE, and the assistant will follow instructions contained in the documents it retrieves. It satisfies the first out-of-scope condition and fails the third and fifth. It is a connected-to system, and every applicable PCI DSS requirement applies to it.
This is the same structural blind spot we have written about in the context of third-party integrations, where OAuth tokens and service accounts reach into the CDE without appearing on any firewall policy (why PCI DSS internal penetration testing finds the systems your scope diagram missed). AI agents are that problem with a faster deployment cycle and a much shorter approval path.
Which AI Deployments End Up In Scope Without Handling Card Data?
More than most inventories reflect. The pattern we see repeatedly is that the AI system with the widest reach is the one nobody classified, because it was deployed as a productivity tool rather than as infrastructure.
The Clone Systems Four-Question AI Scope Test
Run every AI system in your environment through these four questions before your next scope confirmation. Each maps to a specific condition in the PCI SSC scoping criteria, and each has a corresponding evidence artifact an assessor can actually review.
1. What identity does it authenticate as, and what can that identity reach? An AI agent acts through a service account, an API key, or a delegated OAuth grant. The scope question is not what the agent was designed to do, it is what its credential is permitted to do. If that identity can authenticate to any system in the CDE, the agent is a connected-to system regardless of its intended function. Evidence: the identity's effective permissions, exported from the systems it can reach, not the description in the design document.
2. Can it take actions, or only produce text? An assistant that retrieves and summarizes carries data exposure risk. An agent that can write, execute, call other tools, or trigger workflows can alter configuration, and altering configuration is the definition of a security-impacting system under the scoping criteria [2]. The Mandiant repository-cloning case is precisely this distinction: the assistant's read permissions were legitimate, and its ability to act on them is what turned a retrieval tool into an exfiltration path [1]. Evidence: the tool and function list the agent is permitted to invoke.
3. Does anything it reads come from outside your trust boundary? If the agent ingests customer messages, supplier documents, ticket contents, or web pages, an attacker can place instructions in that content. That makes the agent's behavior partly attacker-controlled, which means its access is partly attacker-controlled too. Evidence: the data sources feeding retrieval, with each one classified as trusted or untrusted.
4. Would its compromise change what an attacker can reach? This is the catch-all, and it is the question the standard is ultimately asking. If compromising the agent gives an attacker a path, a credential, or an ability they did not previously have with respect to the CDE, the agent is in scope. Evidence: a documented reachability path from the agent to the CDE, or a documented demonstration that none exists.
A system that answers cleanly on all four is defensibly out of scope. A system that cannot be answered at all is the more common finding, and it is not a scope problem yet. It is an inventory problem.
If you are heading into a PCI assessment and cannot answer those four questions for every AI system in your environment, that gap is worth closing before an assessor finds it. Clone Systems is a PCI Approved Scanning Vendor, and our penetration testing services include scoping and testing AI-integrated systems against the access paths they actually hold. Contact our team to talk through your current scope.
What Evidence Will a QSA Accept That an AI System Is Out of Scope?
Documentation that the system was considered and classified, not silence. An AI system missing from the scope documentation entirely does not read as out of scope. It reads as unassessed, and that is a different and worse finding.
The Inventory Requirement Comes First
PCI DSS v4.0.1 Requirement 12.5.1 requires an inventory of system components in scope, maintained and kept current. Requirement 12.5.2 requires that scope be documented and confirmed at least once every 12 months and after any significant change, with service providers confirming every six months since that requirement became mandatory on March 31, 2025 [3]. The supporting documentation an assessor expects covers data flows, account data locations, system components, segmentation controls, and connections from third parties with CDE access [3].
An AI assistant deployed through a SaaS platform, wired into an internal data source by someone in operations, appears in none of those artifacts by default. It has no hostname on the network diagram. It may have no infrastructure footprint you own at all. What it has is a credential, and the credential is the thing that carries scope.
Two Artifacts That Settle the Question
In practice, the organizations that get through this conversation quickly bring two things to it.
The first is a scope determination record for each AI system: what it is, what identity it uses, what that identity can reach, which of the four questions above were answered, and who signed the determination. One page per system. The assessor is not looking for elegance, they are looking for evidence that a decision was made deliberately.
The second is a permissions export dated close to the assessment, showing the agent's effective access rather than its intended access. Those two frequently disagree, and when they do, the export is the one the assessor will believe.
Why Do AI Systems Keep Falling Out of the Inventory?
Because they are deployed faster than inventories are updated, and because organizations are systematically overconfident about how many they have.
The Cloud Security Alliance and Token Security surveyed enterprises on exactly this in their report published April 21, 2026. Sixty-eight percent of respondents claimed high confidence in their visibility into AI agents. In the same survey, 82% said they had discovered previously unknown agents in the past year [4]. Those two numbers describe the same organizations. Sixty-five percent had experienced at least one security incident caused by the use of AI agents, with data exposure the most common consequence at 61%, followed by operational disruption at 43% and unintended business process actions at 41% [4].
The finding with the sharpest compliance consequence is quieter. Only one in five organizations has a formal process for decommissioning AI agents, which leaves dormant agents holding live credentials and permissions after the project that created them has ended [4]. A dormant agent with CDE access is in scope, is unmonitored, and appears on no inventory. It is difficult to design a worse combination.
Testing outcomes point the same direction. Cobalt's 2026 State of Pentesting data found that 32% of findings in AI and LLM environments are rated high or critical severity, against roughly 12% in traditional software, and that AI and LLM assets carry the lowest resolution rate of any asset class at 38.4%, compared with 77.3% for APIs [5]. Median time to resolve high-risk AI findings rose from 19 days in 2025 to 36 days in 2026 [5]. The findings are more severe, and they stay open longer. We have written before about why that second half happens, and it is largely a workflow problem rather than a technical one (why your vulnerability management program can't score a prompt injection finding).
Test Your Own Environment: Three Questions
Before your next scope confirmation, ask your team these three.
- Can anyone produce a list of every AI assistant, agent, or copilot with access to an internal system, and when was it last updated? If the list is older than your last quarter of deployments, it is a record of intent, not of state.
- For each one on that list, who can name the service account it authenticates as? If the answer is the vendor, or nobody, you cannot answer question one of the scope test, and neither can your assessor.
- What happens to an agent's credentials when the project that built it ends? If there is no decommissioning step, you have dormant standing access to systems you are attesting about.
An uncertain answer to any of these is a finding in its own right, independent of what the scope document says.
How Clone Systems Can Help
Clone Systems is a PCI Approved Scanning Vendor and Managed Security Services Provider, which means scope conversations are routine work for us rather than an annual scramble. That vantage point is why our position on AI systems is a scoping position rather than a threat-modeling one: the AI deployments that cause assessment problems are rarely the ones handling payments, they are the ones holding credentials nobody classified.
Our penetration testing services cover internal and external testing scoped to PCI DSS Requirement 11.4, including the AI-integrated applications that standard application testing typically leaves out of scope (why your annual penetration test isn't covering your AI systems). Our vulnerability scanning services cover the Requirement 11.3 internal and external scanning obligations alongside the ASV scan, across the full in-scope estate rather than the CDE alone.
If your scope documentation does not currently mention AI at all, that is a straightforward gap to close with enough notice, and a costly one to discover during an assessment. Start the conversation at www.clone-systems.com.
Frequently Asked Questions
Does an AI chatbot put you in PCI scope? An AI chatbot is in PCI DSS scope if it stores, processes, or transmits account data, or if it can connect to or affect the security of the cardholder data environment. A chatbot that never sees a card number can still be in scope through the credential it uses to reach an in-scope system.
Are AI agents covered by PCI DSS? PCI DSS contains no AI-specific requirement, so AI agents are governed by the same scoping rules as any other system component. Where an agent qualifies as a connected-to or security-impacting system, all applicable PCI DSS requirements apply to it.
How do you prove an AI system is out of PCI scope? Document a scope determination for the system covering its identity, that identity's effective permissions, its ability to take actions, and whether any reachability path to the CDE exists. An assessor is looking for evidence that the classification was made deliberately, not for the system's absence from the documentation.
Does an AI assistant need to be on the PCI system component inventory? Yes, if it is in scope. Requirement 12.5.1 requires a current inventory of in-scope system components, and an AI assistant with access to an in-scope system belongs on it even when it runs as a SaaS product with no infrastructure you operate.
What is the difference between a CDE system and a connected-to system? A CDE system stores, processes, or transmits account data, or shares a network segment with one that does. A connected-to or security-impacting system does none of those things but can access the CDE or affect its security, and all applicable PCI DSS requirements still apply to it.
Can using AI tools cause a PCI compliance failure? Yes, most commonly through an in-scope system that was never inventoried or assessed rather than through the AI technology itself. An unclassified agent holding CDE access is a Requirement 12.5.1 and 12.5.2 problem before it is a security problem.
Conclusion
The organizations that get caught here are not the ones being careless with card data. They are careful with card data, which is exactly why they applied the card data test to their AI systems and stopped there. The standard asks a broader question, and it has asked it consistently since long before anyone deployed an agent: can this system reach the cardholder data environment, or affect its security? An AI assistant with a service account and a tool list can do both while never rendering a single account number.
Inventory the agents, determine the identity each one authenticates as, and record the scope decision before an assessor asks for it. If you are preparing for an assessment and your scope documentation does not yet account for the AI systems already running in your environment, Clone Systems can help you close that gap while it is still inexpensive. Visit www.clone-systems.com to talk with our team.
References
[1] Mandiant and Google Threat Intelligence Group — AI Risk and Resilience report, September 16, 2026, covering enterprise AI deployment risks including agent permission abuse and runaway agent incidents. https://www.helpnetsecurity.com/2026/09/16/google-mandiant-enterprise-ai-security-risks-report/
[2] PCI Security Standards Council — Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation, defining CDE systems, connected-to and security-impacting systems, and the conditions required for a system to be out of scope. https://listings.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
[3] PCI Security Standards Council — PCI DSS v4.0.1, Requirement 12.5.1 (inventory of system components in scope) and Requirement 12.5.2 (documented scope confirmation at least every 12 months, and every six months for service providers since March 31, 2025), 2024. https://www.pcisecuritystandards.org/document_library/
[4] Cloud Security Alliance and Token Security — Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, April 21, 2026. https://cloudsecurityalliance.org/
[5] Cobalt — The 2026 State of Pentesting Report and the AI and Pentesting Pulse Report, 2026. https://www.cobalt.io/state-of-pentesting
[6] Clone Systems — In our PCI assessment work, AI systems are evaluated for scope almost exclusively on whether they can see a primary account number, and the deployments that create assessment findings are consistently the assistants and agents that never handle card data but authenticate with service accounts holding standing access to in-scope systems, with no entry on the system component inventory and no record of who classified them.
[7] Clone Systems — Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed. www.clone-systems.com/blog/pci-dss-internal-penetration-testing-scope-gap
[8] Clone Systems — Why Your Annual Penetration Test Isn't Covering Your AI Systems. www.clone-systems.com/why-your-annual-penetration-test-isnt-covering-your-ai-systems/
[9] Clone Systems — Why Your Vulnerability Management Program Can't Score a Prompt Injection Finding. www.clone-systems.com/blog/why-your-vulnerability-management-program-cant-score-a-prompt-injection-finding
[10] Clone Systems — Penetration Testing Services. www.clone-systems.com/penetration-testing