Introduction
Artificial intelligence is becoming an integral part of the payment ecosystem, from fraud detection and transaction analysis to software development automation, security monitoring, and customer support. At the same time, AI is expanding the capabilities of threat actors by enabling them to automate vulnerability discovery, enhance social engineering campaigns, and scale attacks.
On September 15, 2026, the PCI Security Standards Council (PCI SSC) published an information supplement entitled *Security Considerations for AI Systems*. The document addresses security considerations associated with the use of AI in payment environments, as well as the protection of traditional information systems against AI-enabled attacks.
The central takeaway is that adopting AI does not eliminate existing information security obligations or create an automatic exemption from PCI DSS requirements. Organizations must assess the actual capabilities of AI systems, their interactions with payment infrastructure, and their potential impact on the security of protected data.
This article examines the practical implications for banks, payment service providers, fintech companies, merchants, and PCI DSS professionals.
1. AI Is a New Technology Within an Existing Threat Model
One of the key considerations for PCI SSC is that AI should be treated as a technology that may affect PCI DSS applicability, rather than as a separate category that automatically determines the scope of compliance.
This distinction is particularly important when determining PCI DSS scope.
Organizations may use AI for a variety of purposes, including:
– Security log analysis and event correlation.
– Payment fraud detection.
– Automated customer support.
– Software development and source code analysis.
– Processing support requests containing payment data.
– Infrastructure management and administrative operations.
– Vulnerability discovery and remediation prioritization.
These use cases have different risk profiles. An AI assistant that analyzes anonymized statistics should not be assessed in the same way as an AI agent with access to payment processing systems.
The relevant security questions are not simply whether an organization uses AI, but **what data the system processes, which resources it can access, and how its operation may affect the security of the payment environment**.
2. How AI Affects PCI DSS Scope
When determining PCI DSS applicability, organizations must consider system architecture, data flows, network connectivity, privileges, and the potential impact of a system on the Cardholder Data Environment (CDE).
Consider three common scenarios.
Scenario A: AI Processes Anonymized Data Outside the CDE
An organization uses an external language model to analyze publicly available documentation, draft internal policies, or process anonymized statistics.
Provided that the solution is genuinely isolated from the CDE and cannot affect the security of the payment environment, the direct applicability of PCI DSS requirements to that component may be limited.
However, organizations must verify that no indirect connections exist through enterprise integrations, privileged APIs, secrets, configurations, or internal repositories.
The absence of PAN in the input data does not, by itself, demonstrate that a system is out of scope.
Scenario B: AI Processes Payment Data
Consider an organization that sends customer requests, transaction histories, or payment system data to an AI service for analysis or customer support automation.
The organization should determine:
– Which data elements are transmitted to the model.
– Whether the data includes PAN, Sensitive Authentication Data (SAD), or other sensitive information.
– Where processing and storage take place.
– Whether the provider retains prompts and responses.
– Whether submitted data is used for model training or service improvement.
– Which subprocessors can access the information.
– How data deletion and retention requirements are enforced.
If an AI component stores, processes, or transmits cardholder data, or otherwise affects CDE security, it must be evaluated against the applicable PCI DSS requirements.
Particular attention should be paid to SAD. The use of AI does not change PCI DSS restrictions on storing sensitive authentication data after authorization.
Scenario C: AI Has Access to Payment Infrastructure
The most complex scenario involves an AI agent capable of reading configurations, creating tickets, executing scripts, modifying security rules, or managing infrastructure through APIs.
Even if the model does not directly receive PAN, its compromise or erroneous execution of commands could affect CDE security.
For example, an agent might receive malicious instructions from an external source to modify a network rule, disable a security control, or transmit a secret to a third-party service.
In this scenario, scope determination must account not only for payment data flows but also for the AI component’s ability to affect the security of systems within PCI DSS scope.
PCI DSS scope must be determined based on the actual architecture, system relationships, and applicable requirements. Excluding an AI system from scope must be justified rather than assumed.
3. AI Is Changing the Economics of Cyberattacks
PCI SSC also highlights the need to protect systems against malicious uses of AI, including in the context of vulnerability discovery.
Modern AI tools can automate individual stages of an attack, including:
– Source code and configuration analysis.
– Identification of potentially vulnerable components.
– Generation of exploit variants targeting known weaknesses.
– Creation of tailored phishing messages.
– Analysis of publicly available technical information.
– Scaling reconnaissance and initial assessment activities.
This does not mean that every AI model can autonomously execute a sophisticated attack. However, reducing the time and cost associated with individual attack stages can increase the potential scale of malicious activity.
For payment organizations, vulnerability detection, timely patching, and effective management of exposed components are particularly important.
PCI SSC emphasizes the importance of frequent—and, where feasible, continuous—vulnerability monitoring and management.
In practice, this supports a shift from periodic assessments toward a more dynamic vulnerability management model:
1. Identify newly disclosed vulnerabilities and infrastructure changes promptly.
2. Determine which assets are affected, taking their role in the payment environment into account.
3. Assess risk based on exploit availability, network exposure, and system criticality.
4. Prioritize remediation of the most significant vulnerabilities.
5. Validate remediation and monitor for recurrence.
AI can improve the efficiency of both attackers and defenders. However, automated detection does not replace accountability for risk prioritization, remediation, and validation.
4. AI-Specific Risks That Require Additional Assessment
Traditional infrastructure security assessments may not be sufficient when a system uses language models, external data sources, tools, or autonomous actions.
In addition to conventional application and infrastructure risks, organizations should consider the following scenarios.
Prompt Injection
A model receives malicious instructions through user input, documents, emails, web pages, or external tool outputs.
If the AI system has access to internal data or tools, these instructions may result in information disclosure or unauthorized actions.
Sensitive Data Exposure
Employees may submit log fragments, source code, configuration files, secrets, payment data, and other sensitive information to AI services. The level of risk depends on the service architecture, retention settings, access controls, and the provider’s data processing terms.
### Excessive AI Agent Privileges
An agent with broad permissions can turn a model error or successful prompt injection into a real infrastructure compromise.
Risk reduction measures should include least-privilege access, restricted toolsets, environment isolation, and human approval for critical operations.
Supply Chain Risks
AI systems may depend on external models, libraries, plugins, APIs, datasets, and provider infrastructure.
Organizations should assess not only the model itself but also every component through which it receives data or performs actions.
Insufficient Observability
If an organization does not log prompts, tool calls, privilege changes, and AI agent actions, incident investigation becomes significantly more difficult.
Logging must also be designed to avoid creating an additional channel for the exposure of PAN, SAD, secrets, or other sensitive information.
5. Integrating AI Into a PCI DSS Compliance Program
PCI SSC positions its new information supplement as guidance rather than a standalone set of mandatory requirements. Where recommendations differ from formal standards, the applicable requirements of the relevant standard take precedence.
Organizations should therefore not interpret the document as establishing a separate AI certification standard. Its practical value lies in helping structure risk assessments and evaluate the applicability of existing requirements.
A recommended approach consists of six stages.
Stage 1: Inventory AI Systems
Maintain an inventory of AI components, including enterprise solutions, external SaaS services, APIs, and locally deployed models.
For each component, document its owner, purpose, provider, data types processed, integrations, privileges, and business criticality.
The inventory should not be limited to formally approved deployments. Informal employee use of AI services must also be considered.
Stage 2: Analyze Data Flows and Architecture
Determine what data enters the AI system, what information it generates, and where that information is subsequently transmitted.
Specifically, assess:
– Connections to the CDE and related systems.
– The presence of PAN and SAD.
– Access to secrets and configurations.
– Network connectivity and API integrations.
– Retention of prompts, responses, and processing outputs.
– The ability of AI to affect security controls.
Stage 3: Determine PCI DSS Scope
Map the architecture against the PCI DSS scope criteria. Identify components that are part of the CDE, systems connected to it, and systems capable of affecting its security.
Document the rationale for including or excluding each relevant component from scope.
If the architecture changes—for example, an AI agent receives access to a new API or administrative capability—the scope assessment should be revisited.
Stage 4: Assess AI-Specific Risks
Extend the existing threat model to cover prompt injection, data leakage, tool misuse, excessive privileges, and dependency compromise.
Test not only the correctness of model outputs but also the security of its interactions with external systems.
For AI agents, a critical testing objective is the entire execution path, from input data to the resulting action.
Stage 5: Implement Controls and Monitoring
Depending on the architecture and identified risks, consider the following measures:
– Least-privilege access and network segmentation.
– Input data filtering and classification.
– Restrictions on available tools and APIs.
– Controls over outbound connections.
– Protection of secrets and tokens.
– Approval workflows for high-risk actions.
– Logging of tool calls and administrative operations.
– Vulnerability monitoring and timely remediation.
– Change management and periodic risk reassessment.
These measures are practical security recommendations. Their specific implementation and mandatory status must be determined based on the applicable PCI DSS requirements and the organization’s risk assessment.
Stage 6: Validate Controls and Maintain Evidence
Every security decision should have a defensible basis and supporting evidence.
Depending on the use case, this may include architecture diagrams, data flow diagrams, AI system inventories, scope assessments, risk registers, access control configurations, test results, event logs, and remediation evidence.
The existence of an AI usage policy alone does not demonstrate that an AI system is secure.
6. Practical Example: An AI Agent for Security Monitoring
Consider a payment service provider deploying an AI agent to analyze SIEM events, investigate suspicious activity, and generate recommendations for its Security Operations Center (SOC).
Initially, the agent has read-only access to a restricted set of logs. It cannot execute commands on servers, modify network rules, or manage user accounts.
The risks in this scenario are comparatively easier to control, but several concerns remain: sensitive information in logs, prompt injection through event data, excessive disclosure, and access to internal resources.
In a second phase, the agent is granted permission to automatically block accounts, modify access rules, and execute incident response scripts.
This significantly changes the risk profile.
A compromised agent, an incorrect interpretation of events, or malicious instructions could now directly affect the infrastructure.
Before expanding the agent’s permissions, the organization should reassess the architecture, privileges, potential impact on the CDE, approval mechanisms for critical actions, and rollback capabilities.
This example demonstrates why AI security assessments should not be limited to a product name or a vendor’s assurance that its solution is secure. The actual capabilities of the system are what matter.
7. Implications for QSAs and Internal Auditors
For professionals conducting PCI DSS assessments, the growing adoption of AI introduces additional considerations when gathering evidence and reviewing system architecture.
Relevant assessment questions include:
– Is AI used within or outside the assessed environment?
– What data and metadata are transmitted to the model?
– Which components can access the CDE?
– Can AI affect security controls or system configurations?
– How are external integrations and privileges controlled?
– How does the organization detect and remediate vulnerabilities?
– How are AI agent actions logged and investigated?
– Which changes trigger a reassessment of PCI DSS scope?
AI should not automatically expand an assessment to every system within an organization. As with traditional infrastructure, scope determination must be based on a defensible analysis of the environment and its connected systems.
Conversely, a component should not be excluded from scope simply because it is described as an analytics tool, operates through an API, or does not directly store cardholder data.
The decision must be based on the actual architecture and the applicable PCI DSS scope criteria.
Conclusion
The PCI SSC publication *Security Considerations for AI Systems* reinforces an important principle: adopting AI requires organizations to adapt their risk management practices, but it does not eliminate existing information security obligations.
