How Is AI Changing PCI DSS Compliance and Data Attacks in 2026?

AI is making existing cardholder data attacks faster and harder to catch. Luckily, PCI DSS 4.0.1 already covers AI risk if merchants map their tools to the right requirements.

Updated:  
September 11, 2026
Security Training
PCI
PCI DSS v4.0
How Is AI Changing PCI DSS Compliance and Data Attacks in 2026?
Quick Answer:
How Is AI Changing PCI DSS Compliance in 2026?
  • AI doesn't create new PCI DSS requirements; it triggers the ones you already have. Map any new AI tool to Requirements 6, 7, 8, 12.3.1, 12.6.3, and 12.8 before deploying it.
  • A payment redirect can be PCI compliant and still be a soft target. FAQ 1588 exempts SAQ A redirects from 6.4.3 and 11.6.1, but the panel's forensic data shows attackers are shifting toward redirects specifically because they're easier to exploit than iframes.
  • Agent-based tools alone aren't enough. The panel's own case study showed a premium agent-based tool getting evaded by an attacker who knew it was there.
  • New AI tool adoption should trigger a targeted risk analysis every time, not just a one-time policy update.

Threat actors are using artificial intelligence (AI) to accelerate the rate of cardholder attacks faster than ever. This blog discusses the SecurityMetrics webinar “How does AI Impact Your Compliance?” hosted by QSA Jen Stone, forensic investigator Aaron Willis, and Director of Threat Intelligence Center Matthew Heffelfinger or “Heff.” 

This panel of experts discovered that PCI DSS v4.0.1 already covers AI-driven risk, as well as other vulnerabilities in e-commerce skimming, forensic investigations, and audit findings.

TL;DR: Key Takeaways

  • AI doesn't create new PCI DSS requirements; it triggers the ones you already have. Map any new AI tool to Requirements 6, 7, 8, 12.3.1, 12.6.3, and 12.8 before deploying it.
  • A payment redirect can be PCI compliant and still be a soft target. FAQ 1588 exempts SAQ A redirects from 6.4.3 and 11.6.1, but the panel's forensic data shows attackers are shifting toward redirects specifically because they're easier to exploit than iframes.
  • Agent-based tools alone aren't enough. The panel's own case study showed a premium agent-based tool getting evaded by an attacker who knew it was there.
  • New AI tool adoption should trigger a targeted risk analysis every time, not just a one-time policy update.
  • "Immediate notification" means someone is actually reading the alert that day, not that a tool technically sent one.

Is AI Actually Making Cardholder Data Attacks Worse?

Yes. SecurityMetrics experts agree that AI isn't inventing new attack types, but rather it's making existing ones faster and harder to catch.

"PCI DSS is reactive to risk related to cardholder data," Jen Stone said. "It's not that AI necessarily is creating different risks; it's accelerating the risks that exist. Because AI can do all of the current and previous threats faster."

Aaron Willis backed that up with what his forensics team is seeing directly on merchant checkout pages; automated bots probing e-commerce sites, a rise in AI-assisted credential compromise, and MFA fatigue attacks that didn't exist like this a few years ago.

What SecurityMetrics experts say is increasing attacks:

  • Agentic bots capable of automated reconnaissance against e-commerce sites
  • AI-assisted credential stuffing and session token theft
  • Automated MFA fatigue attacks
  • A sharp rise in disclosed vulnerabilities and zero-days across major vendors

What Is Spectre AI, and Why Does It Matter for Script Security?

Spectre AI is SecurityMetrics' scanning tool that uses AI to catch malicious scripts that other scanning tools miss.

"Spectre AI is an enhancement on that, where we actually use AI to determine if we're seeing anything malicious on that page," Aaron Willis explained. "We can pick out things now that we just didn't have the time or the bandwidth to see before. We can feed that data to AI and pick out things that are hidden in code at volume and at scale."

That distinction, volume and scale, is the whole point. A human analyst can review a handful of checkout pages closely. AI-assisted scanning can review thousands and flag the same subtle patterns a trained eye would catch, just faster.

Real Case Study: How a Skimmer Beat an Agent-Based Security Tool

One of the most instructive findings Aaron Willis shared involved a merchant with agent based security software actively monitoring its checkout page that still got breached.

"We found a skimmer running on a page that had all the security in place, including an agent running specifically defined JavaScript skimmers on the checkout process," he said. "This is not a low-budget skimmer. This is one of the premier agents, and it flat-out missed it."

The attacker exploited how the merchant's Next.js framework hydrated data client-side, then took an unusual approach:

"Instead of stealing a credit card, they logged the keystrokes, old-fashioned key logging," Willis said. "They were just capturing it, putting it over in local storage, and then they didn't pull it out right away. Every once in a while, they’d just reach into local storage and pull out the keystrokea little bit at a time. So the software that was there, the agent, completely missed it."

The agent missed it because the attacker knew the monitoring tool was present and built the exploit around its blind spots.

"The moment they can see that an agent is there, that gives them a whole lot of information to work around," Willis said. "The neat thing about an agentless solution is the attackers don't know we're there. That's really what allowed us to find that breach."

Does PCI DSS 4.0.1 Actually Cover AI?

Yes, even though it doesn't use the words "artificial intelligence." 

Jen Stone argues that instead of asking whether PCI DSS addresses AI directly, merchants should ask which existing requirement bucket their AI use case falls into.

"Instead of saying we need to address artificial intelligence we say, in what ways are we using artificial intelligence that's already covered by PCI DSS," she said. 

Here's how she mapped it:

  • Requirements 7 and 8 (access and authorization): If AI systems can see cardholder data, that access needs the same least-privilege justification as any human user or application.
  • Requirement 6 (secure development): If AI tools are helping write code, the full secure software development lifecycle still applies to that code.
  • Requirement 12.3.1 (targeted risk analysis): Adopting a new AI tool should trigger a fresh TRA. "If you adopt a new tool in your business, not only should you do a new TRA for all of the ones that apply, you should also say to yourself, this is a major change to my environment," Stone said.
  • Requirement 12.6.3 (security awareness training): Phishing training needs to reflect AI-generated phishing examples, not just older templates.
  • Requirement 12.8 (third-party service providers): An AI chatbot or tool is a third-party service provider. "A lot of people aren’t aware that an AI that they’re now using is another third-party service provider," Stone said.

Bottom line from Stone: "Making sure you have updated all of the ways in which anything can interact with cardholder data, (including AI), could trigger new network diagrams and new data flow diagrams."

Do I Still Need to Worry About Requirement 6.4.3 and 11.6.1 If I Use a Payment Redirect?

This question is perhaps the most confusing part of the current standard. The compliance answer is under FAQ 1588, full URL payment redirects that qualify for SAQ A are exempt from Requirements 6.4.3 and 11.6.1.

The security answer is that we don't treat that exemption as a reason to skip script protection.

"We care about protecting scripts on a page because the scripts on a page are what's stealing cardholder data," Stone said. 

For merchants who aren't exempt, she laid out two compliant paths: "Either get your service provider to say that your environment is not susceptible to these kinds of attacks, which is insane... or you have to implement script management and tamper detection."

Aaron Willis explained why skipping it is risky even when it's technically allowed. His team has tracked a real trend toward exploiting redirects specifically because they're easier to attack than an iframe.

"We've seen an almost 300% increase in merchants using payment redirects because it's an easy way to get around all this stuff," Willis said. "An iframe is a security box around that payment data, and an attacker has to know what they're doing to get in and defeat that iframe. What's a payment redirect? It's a link. Is there anything around that link protecting it? No. The hacker just literally goes in and changes the link."

Does an Agent-Based Security Tool Fully Satisfy 6.4.3 and 11.6.1?

SecurityMetrics experts say that an agent-based security tool helps, but it's not sufficient on its own.

"Agent-based tools are absolutely better than nothing," Willis said, pointing back to the Next.js keylogging case as proof that agents can be studied and evaded. His recommendation is layered coverage: "Pairing a client-side control with external agentless monitoring, like SecurityMetrics Shopping Cart Monitor, is a winning combination."

What Counts as a "Payment Page Script" Under PCI DSS 4.0.1?

Broader than most merchants assume. Per the panel, it includes:

  • Payment fields
  • Analytics tools
  • Marketing pixels
  • Tag managers
  • Any script that can interact with the payment page, including a single redirect link

What's the Notification Requirement Under 11.6.1 If a Script Changes?

"You have to immediately notify," Stone said. "It has to be a full conversation for it to be an immediate notification, not just a shout in the dark." 

Willis added that his forensic team regularly finds cases where alerting tools worked, but nobody was watching the inbox: "We find out nobody's paying any attention. It went to an email account that nobody's reading, or they read it once a month."

Public AI Tools vs. Private Enterprise AI: Does It Matter for PCI Compliance?

Yes, and the gap is bigger than most business owners assume. 

Public AI tools can train on whatever data employees enter, which creates a real path for cardholder data or intellectual property to leak outside the business entirely.

Their recommended approach isn't banning AI outright: "I don't think that a rational response is, well, we will not use any AI in our business," one panelist said, "because if you don't give your people the tools that are locked down and controlled by the enterprise, they're going to go use public tools." 

The fix is giving employees an approved, enterprise-controlled AI option so they aren't pushed toward unsanctioned public tools to get the productivity boost they're after.

The Three-Tier Compliance Framework the Panel Recommends

Compliance is a floor, not a ceiling, and the panel framed AI-era security as three layered tiers:

  1. Continuous compliance: Real-time monitoring instead of point-in-time checks. "Compliance is not an event," the panel noted, "it's a moving iceberg."
  2. Extended controls for AI: Updated AI usage policies and acceptable use policies, since many organizations haven't formally addressed whether AI tools are permitted at all.
  3. Script inventory and baseline visibility: Know what's actually running on the checkout page. Willis noted his team has found 300 to 400 scripts on a single checkout page, representing potentially millions of lines of third-party code with access to cardholder data.

Talk to a QSA About Where Your AI Tools Actually Fall

If your business has adopted AI chatbots, AI-assisted coding tools, or AI-powered analytics on pages that touch cardholder data, those tools already fall under existing PCI DSS 4.0.1 requirements, whether or not anyone has mapped them yet. 

SecurityMetrics QSAs can help identify where AI fits into your current scope, and where a targeted risk analysis is overdue. You can also better protect your online shopping carts and meet PCI requirements by purchasing an agentless tool like Shopping Cart Monitor

Speak with an expert about your PCI requirements today.