PCI SSC's AI guidance has one 'must' and 130 'should', and asks for explicit human approval in one example

One must, 130 should, 86 may

The PCI Security Standards Council's Security Considerations for AI Systems is an information supplement, version 1.0, dated September 2026, 26 PDF pages long. Counted in the text of the PDF, it uses the word must once, should 130 times and may 86 times. The counts are whole words, any case, page headers and footers excluded: should is 117 plain plus 13 "should not", and may is 83 plain plus 3 "may not". That is 130 + 86 + 1 = 217 modal words, of which 59.9 per cent are should, 39.6 per cent are may and 0.5 per cent are must (derived).

The single must is in the purpose paragraph on page 1. AI is permitted within entities that need to meet PCI requirements, but "any deployed AI systems must be designed, implemented, and used securely". Further down the same page the document says it is guidance only and "does not replace, supersede, or override any existing requirements in PCI standards." The word shall does not appear at all.

So the count says what kind of document this is. It does not say that nothing in it binds. An AI system that receives or has access to account data is, by the document's own statement, in scope of PCI DSS, and the requirements the document names (11 by number, by this briefing's count) apply to that system whether or not a should repeats them. The 130 shoulds are the council's view of good practice. The binding part is the existing standard, which the document says treats AI as "no different from any other form of technology" when scoping.

It is also not new this week. The document is dated September 2026. The council's blog post announcing it is dated 15 September 2026, its press release is dated 7 October 2026 (issued from Edinburgh), and Help Net Security's report is dated 9 October 2026, 24 days after the blog post (derived). The press release and the blog name the Global Executive Assessor Roundtable (GEAR) and the Board of Advisors as collaborators. The document's cover names one author, the council itself. This briefing names no individual, including the executive quoted in the press release.

What the document states and what it leaves out

Read in full, the document has 23 numbered pages (26 in the PDF), five worked examples (Example 2 has two sub-examples), three tables and two figures. Help Net Security's summary matches the PDF on every point this briefing checked. The one place it compresses is its headline, "PCI SSC calls for human approval of AI agent actions involving cardholder data", which rests on one bullet in Example 4 and is covered below.

What the guidance states and does not state, from PCI SSC, Security Considerations for AI Systems v1.0, September 2026. Page numbers are the document's own.

Topic	Stated	Not stated
Status	Guidance only. Does not replace, supersede or override any PCI standard (page 1, repeated in the page footers). One must.	No effective date, no deadline, no assessor testing procedure, no change to how anyone validates.
Human approval, general	Human-in-the-loop means each task is approved by a suitable human individual. Human-over-the-loop means autonomy without per-action approval. The first is "ideal but can fail" against fast attackers, so entities may consider the second (pages 8 to 9).	What an approval consists of, how fast it must come, how many one person can review, how it is evidenced. A "suitable human individual" is only someone positioned, skilled and empowered.
Human approval, cardholder data	Example 4, an agent with cleartext cardholder data: do not use human-over-the-loop and "Require explicit human approval for any actions involving cleartext cardholder data" (page 23).	Whether the same applies to agents holding only encrypted or tokenised data. Example 2 says such an agent may be out of scope.
Named responsibility	Formal acceptance of responsibility for AI output by a suitable human individual. Each AI system has a human, by name or role, who approves its deployment, tasks and data types (pages 4 and 18).	The seniority, title or contractual form of that person, or how a team sharing the role is handled.
Three-way rule	Prevent one AI system holding sensitive data, exposure to untrusted content and external communication together. Where a workflow needs all three, split it across agents. It is "at best as a quick tool", not a substitute for threat modelling (pages 11 to 12).	A test for when untrusted input has really been removed. Protection against agents "infecting" or "colluding" is only to be "considered" (page 9).
Independent controls	Credential limits enforced outside the AI system, through identity policy, brokered access or network controls. Data loss prevention that runs independently of the AI (pages 9, 10 and 16).	Which products or architectures count as independent.
Inventory	An AI inventory and AI bill of materials per system: model, version, harness, data and system access, hosting, retention, users, integrations (page 7). Add AI to data-flow diagrams and the component inventory (page 18).	A template or format, or how often the inventory must be refreshed.
Scope	An AI system with access to account data is in scope. With unrestricted connectivity to systems that hold it, it is "by definition" part of the cardholder data environment (page 15). Encrypted or tokenised data plus the means to decrypt counts as cleartext (page 12).	Whether any given SaaS feature must be treated as in scope. No assessor sampling guidance.
Third-party AI	A provider hosting any part of an AI system with access to sensitive data is a third-party service provider and requirements 12.8.x apply in full, including AI inside document readers, content tools and payment-page chat widgets (page 18).	Terms beyond that list: no breach-notification deadline, no named audit standard, nothing on a UK provider.
AI-assisted attacks	Expect easier vulnerability discovery, exploit building, social engineering and attacks on voice and video biometrics. More continuous scanning and fast triage. Quarterly scans remain a PCI DSS v4.0.1 requirement (page 13).	Any incident, any figure for the rate of change, any named attacker or tool.
Agentic payments	Excluded: the document "does not address the use of AI to perform payments (e.g., agentic commerce)" (page 1).	Anything about an agent spending a cardholder's money.

Two small facts about the references. The document lists ISO/IEC 42001, the NIST AI Risk Management Framework and its generative AI profile, OWASP, the Cloud Security Alliance and MITRE ATLAS, and it lists one AI vendor document, Anthropic's Zero Trust for AI Agents, in the same group. It maps no clause of any of them to a recommendation. It does not use the words UK, NCSC or FCA once.

What is new in it, and what is only restated

PCI SSC has published two earlier AI items. Integrating Artificial Intelligence in PCI Assessments, version 1.0 (March 2025, 12 numbered pages), covers assessors using AI and says AI is a tool, not an assessor. A council blog post of 11 September 2025, AI Principles: Securing the Use of AI in Payment Environments, sets out principles as things AI systems must be, should not be, should be and may be. It too has a single must: AI systems must be deployed and managed in compliance with applicable PCI SSC requirements. The new document is 26 PDF pages against 15 for the March 2025 one, and much of it restates the September 2025 post in more detail.

Where each theme already sits in PCI SSC text, and whether the new document adds to it. Requirement numbers are as PCI SSC's own documents cite them.

Theme	Where it already sits	New here?
Least privilege for AI	September 2025 post: Requirement 7, least privilege and need to know.	The name "least agency" and its definition are new. The idea is restated.
A named human is responsible	September 2025 post: an AI cannot accept responsibility, one individual is held responsible. March 2025 assessors document: AI is a tool, not an assessor.	Restated, with a definition of "suitable human individual" and an owner for each system.
Log and monitor AI actions	September 2025 post: Requirement 10.	Restated. New: logs should support reconstruction while avoiding storage of account data.
Third-party AI	March 2025 assessors document: assessor contracts bar training on client data. New document: requirements 12.8.x.	The tie to 12.8.x for AI, including chat widgets, is new. The training bar is restated.
Scoping AI	Requirements 12.5.2 (scope), 12.5.1 (component inventory), 1.2.4 (data-flow diagrams), 3.3.1 (no storage of sensitive authentication data after authorisation).	New: explicit AI rules, including encrypted data plus a decryption path equals cleartext (Examples 2a and 2b).
Three-way rule	No numbered requirement. Not in the September 2025 post as read.	New to the PCI SSC text read for this briefing.
AI bill of materials	Requirement 12.5.1, component inventory.	An extension: model versions, harnesses, retention and users per system.
AI and multi-factor authentication	Requirement 8.4.2.	New: an AI system cannot hold possession or inherence factors, so device-bound credentials are the minimum.
Human-over-the-loop	September 2025 post: no full agency over software creation and deployment without a human in the loop, yet blanket approval and fail-secure autonomy are allowed.	A shift in emphasis. Eleven questions to answer before using it, and Example 3 (see below).
AI-assisted attacks	PCI DSS v4.0.1 quarterly scans, with more frequent scans recommended in the guidance.	Restated, now asking for continuous monitoring and fast triage.

By this briefing's count the document cites 11 PCI DSS requirements by number (1.2.4, 3.3.1, 6.2.3, 6.2.3.1, 6.2.4, 6.5.1, 8.4.2, 12.5.1, 12.5.2, 12.8.x and 12.10.x), plus Requirement 3 as a whole and the quarterly scan requirement without a number. Least agency, the three-way rule and human-over-the-loop have no numbered requirement behind them. They are the council's advice and nothing more.

There is one difference in emphasis worth watching. In September 2025 the council wrote that "the entirety of the creation and deployment pipeline should not be fully automated". The new document's Example 3 describes a developer agent, a testing agent and a deployment agent. It names no human approval step between testing and deployment, and says the deployment agent "has no direct prompt interface to human developers or other agents". Example 1, by contrast, ends with a patch regimen that "may then be approved by a suitable human individual for deployment". The document does not reconcile the two, and says a human should always be "in command" without having to approve each action. That is a reading of the text, not a statement the council makes.

PCI DSS v4.0.1 itself was not read for this briefing. Its PDF sits behind a licence form that asks for a name, job title, company, country and contact details before an accept or decline, and the form was not completed. The scope figure and every requirement number here are therefore taken as PCI SSC's own documents and FAQs quote them.

The three-way rule, and where the document splits it

The document uses the term "lethal trifecta", defines it in its terminology table and uses it 10 times. This briefing covers the idea under its own description, the three-way rule. As the document states it, an AI system should be prevented from having all three of: access to sensitive data, exposure to untrusted content, and external communication or access. The more sensitive the data, the more the system should be kept from untrusted content and outside access. Where a workflow needs all three, it should be split across several agents, each given only what its narrow role needs (pages 11 to 12).

Read the figure against the document's own tables. In Example 1 the triage agent has the outside access and the untrusted input, and holds only high-level configuration and software bill of materials data. The other three agents hold the sensitive access, have no outside access, and are classed "Referred" for prompts: their input comes from the triage agent. The document's own notes say that input "may be polluted" by what the triage agent read. So the split removes direct exposure from the later agents, while the untrusted input still arrives second-hand. That is this briefing's reading of Table 1, and the table's own notes say the same. The document does describe one protection: the developer agent scans patches that come from triage "using pre-validated functional tools" (page 19). Whether that is enough is the entity's call.

Example 4 takes the other route and removes two of the three: no outside access, no untrusted input except through a separate verified channel, and explicit approval for any action involving cleartext cardholder data. Table 3, for AI-assisted coding, shows the developer agent with restricted outside access, indirect untrusted prompts and read-only access to detailed source code. All three columns are filled, with the outside access limited to sites it needs. The document does not say whether that counts as the combination it warns against.

This is a rule about the defender's own agents being steered by what they read. The site's earlier briefings cover the opposite direction, attackers running agents against card environments. In the first briefing on Gambit Security's report, the 617,938 stolen card records came from stored card data in two companies' databases, not from the skimmed sites. In the second, the one documented intrusion chain had 14 steps and none named a CVE. Neither briefing describes an AI system inside a victim being manipulated. The PCI document covers both halves, securing your own agents and defending against attackers' agents, but it cites no incident for either. The evidence this site has read so far sits on the attacker half.

What the document does not establish

• No new requirement. It says so on page 1 and in the page footers.
• No assessor testing procedure. It gives no test steps. It asks that AI systems be reviewed under the assessment of Requirement 12.5.2 and that isolation controls sit inside penetration and segmentation testing, and it says an AI system cannot be considered an assessor.
• No definition of what a human approval looks like or how fast it must come. It defines human-in-the-loop as approval of each task by a suitable human individual, warns of "automation bias" three times, and says approving every action is often infeasible. It sets no time, volume or evidence standard.
• Nothing on model providers beyond the third-party service provider rules. No breach-notification deadline, no audit standard, no list of providers, no UK reference.
• No mapping to the NCSC or to ISO/IEC 42001. ISO/IEC 42001 appears once, in the reference list, with no clause cited. The NCSC does not appear.
• No incident data. It cites no breach, no attack rate and no vendor failure.
• No treatment of agentic commerce. An agent that pays on a cardholder's behalf is outside it.

UK: merchants, payment service providers and their suppliers

None of the sources read presents PCI DSS as a statute, and the council says it does not enforce it: its Getting Started guide states "PCI SSC is not responsible for enforcing PCI DSS compliance." The council's FAQ pages say PCI DSS is intended for all entities involved in payment processing, whatever their size or volume, and that whether a small merchant must validate is decided by the payment brands, so a merchant should ask its acquirer or brand. They also say that outsourcing payment processing does not remove a merchant's duty to keep a written agreement with the provider (12.8.2) and to monitor its compliance at least annually (12.8.4). Visa's page says compliance is required of all entities that store, process or transmit Visa cardholder data, that Visa manages enforcement and validation, and that issuers and acquirers are responsible for their merchants and service providers. A non-compliance assessment may go to the issuer or acquirer. This briefing makes no claim about enforcement beyond those pages and the decision below.

UK-relevant sources read on the morning of 9 October 2026, what each says and what it does not say

Source	What it says	What it does not say
PCI SSC FAQ pages and Getting Started guide	PCI DSS is for any entity that stores, processes or transmits cardholder data, in-house or through a provider. Validation is set by brands and acquirers. The council is not responsible for enforcing it.	Anything about AI, or UK law.
Visa, Account Information Security page (global)	Compliance is required of those handling Visa cardholder data. Visa manages enforcement. Acquirers answer for their merchants. Assessments may go to the issuer or acquirer.	A UK-specific rule, or any position on AI.
Financial Ombudsman Service, decision DRN-4881477	A UK acquirer charged a merchant monthly PCI DSS non-compliance fees under the merchant agreement. The ombudsman upheld the complaint in part, on that merchant's facts.	Any rule about AI. Any precedent beyond its facts.
FCA, Bank of England and HM Treasury statement, 15 May 2026	Frontier AI makes cyber attack faster and cheaper. Regulated firms should triage and fix vulnerabilities faster, manage third parties and limit what an attacker can reach. It says it is not intended to introduce new expectations.	PCI DSS, card data, or a firm's own AI agents. It speaks to regulated firms and financial market infrastructures.
NCSC, "Managing the cyber risk of agentic AI", 20 August 2026	Interim advice, to be superseded by formal guidance. Match controls to autonomy, name who is responsible, sandbox the agent, give it its own identity, protect its logs, keep an emergency shutdown.	PCI DSS, cardholder data or payment advice.
NCSC, "Prompt injection is not SQL injection", 8 December 2025	Current language models do not enforce a boundary between instructions and data, so prompt injection may never be fully mitigated. Design deterministic safeguards that constrain what the system can do.	Anything about card environments, or a success rate.
ICO, guidance on AI and data protection	Updated 15 March 2023 and under review after the Data (Use and Access) Act. Personal data must be processed with appropriate security, and AI can make security risks worse.	Agents, language models or payment data: none is mentioned.
ISO/IEC 42001:2023 (ISO catalogue page)	The AI management system standard, edition 1, December 2023. UK buyers purchase it from BSI.	Clause text is paywalled and was not read. This briefing makes no claim about it.

Three points follow from the table. The first two are this briefing's reading, not anything the sources say. First, the FCA, Bank of England and Treasury statement and the PCI document overlap only on the second half of the council's subject, defending against AI-assisted attack. Neither the statement nor the NCSC posts mention PCI DSS, and the PCI document does not mention them. Second, if an AI system holds card details tied to an identifiable customer, the UK GDPR security duty the ICO page describes may also be in play, but the page does not say so about card data. Third, the PCI document's one explicit tie to a management system standard is the reference list's mention of ISO/IEC 42001. The site's ISO 42001 readiness tool scores an AI management system clause by clause, for readers who want a place to start.

Oversight side by side: PCI SSC, September 2026, and the NCSC, 20 August 2026

Topic	PCI SSC	NCSC
Oversight modes	Human-in-the-loop, each task approved. Human-over-the-loop, also called human-on-the-loop, monitored.	Human-in-the-loop, approve before action. Human-on-the-loop, monitor and intervene. Human-out-of-the-loop, no review.
Who is responsible	A suitable human individual, by name or role.	Named individuals or a group, where unintended activity would matter.
Approvals	Which actions need approval is for the entity to decide. Form and speed not defined.	Decide when the agent must stop and seek approval, and make approvals "both guaranteed and gated".
Identity	Credentials unique to the AI system, attributable and revocable.	A unique identity in a class that differs from humans, with the shortest credential lifetime.
Logs	Enough to reconstruct actions, while avoiding storage of account data.	Save transcripts and reasoning traces. Protect them from change or deletion. They may hold sensitive data.
Shutdown	Easy isolation or disablement, reversal of actions, logs that cannot be removed.	Always able to "pull the plug", including network and model links.

The logs row is a design question neither document answers. An agent that touches card data and keeps full transcripts, as the NCSC advises, may write account data into those transcripts. The PCI document says to avoid storing it. Which wins depends on what the agent can see, and that is for the entity, its assessor and its acquirer to settle. PCI SSC's Europe Community Meeting in Edinburgh from 20 to 22 October 2026 has sessions on AI agents in the cardholder data environment and on human versus machine accountability, according to its press release. No programme detail beyond the titles was read.

What to do, in order

The question that exposes the gap

If an assessor asked you today for every AI system that can see a card number, including the ones inside your suppliers' products, and for the named person who approves what each one may do with it, how many would you list, and how many of those approvers have ever said no?

Key facts