PCI SSC publishes new guidance for securing AI in payment environments

Sourced news briefing

The PCI Security Standards Council announced additional guidance on securing artificial intelligence in payment environments on 7 October 2026. PCI SSC says the material covers how AI is deployed, risks of misuse, alignment with existing PCI standards and practical use cases. The council highlights human accountability, access management and controls for systems that can act with limited human involvement. It also states expressly that the publication is guidance rather than a mandatory requirement and that official PCI standards take precedence if there is any difference.

PCI SSC developed the guidance with industry participants including its Global Executive Assessor Roundtable and Board of Advisors. The announcement refers to both defensive uses of AI and threats such as more convincing phishing and scalable exploitation. It does not certify a product, replace PCI DSS or declare a merchant compliant. These are attributed facts from PCI SSC. The analysis below is independent and does not claim that FixPays provides an AI security product, PCI assessment or compliance service.

Independent merchant analysis: Inventory AI that can reach payment data

A merchant cannot govern systems it has not identified. The inventory should include customer-support assistants, fraud tools, code generators, observability platforms, marketing agents, document processors and employee browser tools that may receive payment-related information. For each use, record the owner, vendor, model, data inputs, permissions, output, retention and connection to the cardholder-data environment. The key question is not whether a vendor markets something as AI, but whether the system can read, infer, alter or transmit sensitive payment or authentication information.

Employees may paste logs, screenshots or customer messages into general-purpose tools to solve an incident quickly. That convenience can create an unapproved data path. Merchants should define what information may enter each tool, provide approved redaction methods and block unnecessary access. Training should use realistic support and engineering examples. A policy that merely says “do not share card data” is weak if staff cannot distinguish masked information, tokens, account identifiers, authentication data and sensitive personal details.

Independent merchant analysis: Apply least privilege to agents and integrations

An AI agent that can search documentation presents a different risk from one that can refund transactions, change routing or modify code. Permissions should follow the narrowest task. Separate reading from writing, development from production, and recommendation from execution. Require explicit human approval for high-impact actions until evidence supports a controlled alternative. Service accounts need managed credentials, rotation, logging and rapid revocation. Do not let an agent inherit a powerful employee session simply because integration is easier.

Tool calls and downstream APIs should validate authorisation independently rather than trusting an AI-generated instruction. Input and output controls must consider prompt injection, poisoned content and fabricated identifiers. A customer message should not be able to persuade an internal agent to expose records or issue money. Use allowlisted actions, schema validation, transaction limits and secondary checks. Preserve enough context to investigate an incident without logging complete sensitive data that the system did not need.

Independent merchant analysis: Test changes and abnormal behavior

Model and vendor updates can change behavior even when the merchant's own code remains stable. Record versions where available, require change notices for material services and rerun representative tests after major updates. Testing should cover fabricated payment advice, unsupported refund claims, leakage attempts, multilingual prompts, unusual encodings, malicious attachments and unavailable dependencies. Red-team exercises should remain authorised and should not introduce live card data into unsafe environments.

Monitoring should detect unusual access, volume, destinations, actions and error rates. A sudden increase in refund recommendations, failed authentication or data retrieval may indicate misuse or a model-quality problem. Build a kill switch and a manual fallback for essential operations. Incident plans should identify who can disable the AI component without unnecessarily stopping ordinary payment processing. Review whether existing breach, provider and customer notification procedures apply to the observed facts.

Independent merchant analysis: Keep evidence aligned with PCI obligations

AI guidance does not change the need to define PCI scope, maintain required controls and use qualified assessment where applicable. Merchants should ask how an AI vendor affects network segmentation, access control, vulnerability management, logging, software development and third-party responsibility. Vendor assurance can support review but does not transfer accountability automatically. Contracts should address data use, subprocessors, incident notice, deletion and evidence access.

Governance should connect security, payments, privacy, legal, procurement and operations. A committee is useful only if it can approve, restrict or retire a use case. Record risk decisions and compensating measures. Measure confirmed incidents, false alerts, manual overrides and customer outcomes rather than presenting a list of experiments as maturity. Where the merchant lacks evidence, limit the deployment and seek specialist help instead of making broad claims about secure or compliant AI.

Independent merchant analysis: operating review

Merchants should put boundaries around software-development uses as well as customer-facing agents. Code suggested by a model must pass ordinary review, dependency checking, secrets scanning, testing and change approval before it reaches payment systems. Documentation generated by AI should be checked against the real environment; an invented endpoint, control or data flow can mislead assessors and incident responders. Security teams should review retrieval sources because a trusted agent can repeat inaccurate or malicious material from an internal knowledge base. Procurement should ask whether model inputs are used for training, where processing occurs, how long prompts and outputs remain, and which subprocessors can access them. Where answers are incomplete, reduce data exposure and capability. A practical governance record should show why the use is necessary, which safeguards apply, who accepted residual risk and what evidence would cause the merchant to pause or retire it. Customer-facing deployments need a separate review of disclosure, accessibility, escalation and harmful output. Support agents should identify when a response came from an automated system and have a route to correct payment status using authoritative records. Do not allow a model to invent refund policy, approval outcomes or security instructions. Test whether the system exposes another customer's information through conversation history or retrieval. Review costs and latency during peak demand, because a degraded model can push staff toward unsafe manual shortcuts. Retain evidence of periodic access review and remove integrations that no longer serve an approved purpose. Include AI dependencies in asset inventories and incident exercises, with owners who understand both the model behavior and the payment process it influences.