Payment Security and Compliance in the Age of AI

Payment security and compliance now has an AI rulebook: the PCI Security Standards Council has published dedicated AI guidance for payment environments. Here is what it actually says, why agentic AI changes the risk picture, and the controls the Council now recommends.

Most commentary on payment security and compliance still frames AI as a future problem. It isn’t. The PCI Security Standards Council (PCI SSC) has now issued two distinct pieces of AI guidance — one on securing the use of AI in payment environments, and one on integrating AI into PCI assessments. Neither is codified into PCI DSS requirements yet. However, both set out clearly what good looks like. More importantly, they signal where assessors will start asking questions.

Payment security and compliance: the one non-negotiable

The Council’s AI Principles, authored by Andrew Jamieson, VP and Distinguished Standards Architect at PCI SSC, follow a deliberate hierarchy: things that must be, things that should not be, things that should be, and things that may be. Only one item sits in the “must” tier, and it is the foundation for everything else:

AI systems must be deployed and managed in compliance with applicable PCI SSC requirements. Using AI does not remove or bypass the need to meet any applicable requirement.

The Council acknowledges the tension directly: AI systems “often operate in ways that are not easily decomposed and understood.” That complexity is not a defence. If your implementation is in scope for PCI DSS, the AI is in scope too — including how data is secured as it is stored, processed and transmitted.

Agentic AI is the shift that matters

The genuinely new risk is not fraud models. Those have scored transactions for decades. Instead, it is agentic AI. These are systems with, in the Council’s words, a level of agency to perform actions on their own behalf. In payments, that now extends to agents which facilitate and even make payments for a cardholder.

This creates a category of payment security and compliance risk that PCI DSS was not written for:

• Prompt injection and data poisoning. Attacks on an unsecured AI interface aimed at making the system reveal sensitive data, perform privileged actions, or change its behaviour — in payments, specifically to execute fraudulent transactions.
• Non-determinism and drift. The same input can produce different output, and behaviour changes over time as the system ingests more data — including malicious data planted by threat actors.
• Data leakage. AI systems can emit sensitive information, either unprompted or through maliciously crafted prompts. Furthermore, their data flows may not stay fully within your control.
• Supply-chain opacity. Where did the model come from? Where did the training data come from? Assessors now ask both questions.
• The accountability gap. An AI cannot accept responsibility. It is not a person.

That last point drives the Council’s sharpest recommendation: AI systems should be “considered as a potential ‘malicious insider’ during threat analysis exercises and incident response walk-throughs.” If you have given an agent agency inside your network, your PCI DSS Requirement 12.10 incident response plan should rehearse the scenario where that agent itself is the threat.

The payment security and compliance control set being recommended

The Council’s guidance is useful for one key reason. Rather than inventing a parallel regime, it maps AI risk onto requirements you already operate.

Hard limits — what AI should never be given

• No high-impact secrets or unprotected data. Keep API tokens, user credentials, cryptographic keys and unsecured account data out of AI datasets entirely — and sanitise training data before use.
• No roles requiring formal responsibility. No key custodian duties, no management-level authorisation or approvals. Each of these needs a person you can hold accountable.
• No generating security-sensitive secrets. AI is as bad as humans at inventing randomness; use a known-good RNG.
• No fully autonomous build-to-deploy pipeline. AI may perform individual create, test and deploy actions, but a human must own the end-to-end process (Requirement 6). Note too that a model trained to write software is not necessarily trained to write secure software.
• No access beyond operational need. Least privilege and need-to-know (Requirement 7) apply unchanged. The temptation to give an agent broad access is exactly the risk.

Positive payment security and compliance controls to put in place

• Protect the data the agent touches (Requirements 3 and 4). Where an agent needs payment data, use payment tokens, single-use PANs, truncated PANs, or PANs encrypted while retaining cleartext BIN. Layer on spend limits, frequency caps, single-merchant restrictions and short lifetimes.
• Log to a named human (Requirement 10). Your logs must trace every action to the system that performed it, and to one accountable individual. Where possible, logging should capture prompt inputs and the reasoning that produced the output.
• Validate continuously (Requirements 6 and 11). Before deployment, at deployment, and throughout life — covering drift and model/data provenance.
• Issue bound, use-case-specific credentials (Requirement 7). Give each AI system its own credentials. Keep them easy to track and revoke, and bind them where you can to blunt theft and reuse.
• Segment and isolate (Requirement 1). Separate AI systems from other users, tenants and other AI systems — at network, VM, OS or container level.
• Build a kill switch. Plan a clear, well-understood way to disable the system before you deploy it, not after something goes wrong.
• Filter input and output. Constrain the commands the system will act on and filter what it returns.

Where AI genuinely helps

The guidance is not restrictive for its own sake. AI may provide input to an approval decision that a human then makes, and act on it afterwards (Requirement 6 change management). It may be trusted with autonomous fail-secure responses — proactive isolation or network throttling during an active attack — although the Council warns this can open a denial-of-service vector if attackers misuse it. It may gather, review and summarise content, log review under Requirement 10.4 being the obvious case — with the important caveat that the worst outcome is an AI cheerfully reporting that everything is fine when it isn’t.

What this means for your next assessment

For payment security and compliance assessments, the Council’s position is unambiguous: AI is a tool, not an assessor. Its guidance document, “Integrating Artificial Intelligence in PCI Assessments – Guidelines, Version 1.0,” permits AI to review artefacts, build work papers, support remote interviews and generate report drafts — while human assessors remain responsible for all findings and final decisions, because AI introduces false positives, incorrect assumptions and bias. Notably, it also expects assessors to tell clients they are using AI and obtain consent, plus give assurances on data handling and result accuracy. If your QSA is using AI on your assessment, you are entitled to know.

Closing the payment security and compliance gap

None of these controls are exotic. They are inventory, access governance, logging, validation and evidence. Instead, what defeats organisations is scale and continuity. You must know every AI system touching the cardholder data environment. You must prove least privilege on each one. Above all, you must produce that evidence on demand, rather than reconstructing it before an audit. This is the same discipline we set out in our guide to building a practical GRC framework in 90 days, and it intersects with the control sets compared in ISO 27001 vs NIST vs CIS.

How the GRCLens PCI Module operationalises this

The GRCLens PCI Module turns this guidance into a running payment security and compliance process, rather than a document you read once.

• Pre-mapped PCI DSS control library covering the requirements above out of the box, alongside the other frameworks we support including ISO/IEC 27001 and NIST — so AI-relevant controls sit inside your existing programme, not beside it.
• An AI and agent register approach to scoping: record each AI system touching the CDE, its credentials, its data access and its accountable owner — the inventory the Council’s principles assume you already have.
• Automated evidence workflows. GRCLens assigns controls to named owners with recurring tasks, reminders and live status roll-up. Consequently, readiness does not decay between assessments, and it documents Requirement 10 accountability continuously.
• AI-assisted evidence review with guardrails. Baseerah, our AI agent, reviews submitted evidence and recommends approve or reject with a confidence score — but a person always makes the final call, every decision is audit-logged, and we never train on your data. That is the human-in-the-loop model the Council describes, implemented in the tooling itself.

Reporting, remediation and deployment

• Continuous posture and audit-ready reporting through role-based dashboards for technical, management and executive audiences, with one-click PDF and Word reports that compress QSA preparation from weeks to minutes.
• Gap analysis and remediation tracking with SIEM and ticketing integrations, so your team drives findings to closure instead of parking them in a report.
• Deployed your way — on-premises in your own data centre or in a compliant cloud region, so regulated data never leaves your control.

As a result, you gain process efficiency where it counts. Manual evidence chasing drops. Errors fall. Attestation moves faster. Above all, the organisation stays continuously audit-ready. You can model the saving with the GRCLens ROI calculator.

Security Solution Consultants delivers PCI DSS readiness, AI risk assessment and continuous compliance across Australia, New Zealand and the Middle East, and we are happy to provide customer references from those regions. To see the GRCLens PCI Module applied to your environment, book a demonstration with our team.

Related reading

• Network Security Policy and Posture Management: Are Your Firewall Rules Actually Protecting You?
• ISO 27001 Implementation Roadmap: 2026 Guide
• How to Build a Practical GRC Framework in 90 Days

Primary sources: PCI SSC – AI Principles: Securing the Use of AI in Payment Environments; PCI SSC – Integrating Artificial Intelligence into PCI Assessments; PCI Perspectives AI topic hub. This article is commentary; PCI SSC guidance documents are not standards and do not replace PCI DSS requirements.