PCI SSC AI Guidance: Human Approval for Agent Actions

Key Takeaways

The PCI Security Standards Council (PCI SSC) has published an information supplement titled Security Considerations for AI Systems, which gives payment-environment operators more detailed guidance on governing AI agents around cardholder data than the Council’s September 2025 AI principles [1][2][4]. The supplement is non-mandatory, and where it conflicts with the formal PCI standards, the standards take precedence [2]. Assessors and acquirers may treat it as a reference point for how existing PCI DSS requirements apply to AI, although the extent of that reliance is not yet established.

Three themes matter most for organizations that deploy agents. First, the guidance as reported recommends explicit human approval for agent actions involving cleartext cardholder data, while allowing a “monitored autonomy” alternative for other actions if defined controls are in place [3]. Second, it expects a suitable individual to formally accept responsibility for AI output, which places accountability on an individual rather than on the model [3]. Third, it applies a least-agency approach that discourages combining sensitive data access, external communication, and untrusted input in a single agent [3].

The guidance builds on principles the Council published in September 2025, which stated that AI should not take on formal responsibility roles such as key custodian or management-level authorizer [4]. Taken together, the two documents describe human accountability as an expected control and not only as a governance preference, although neither document is a binding requirement. Organizations should read the guidance alongside CSA’s work on agent authorization and runtime enforcement, discussed in the CSA Resource Alignment section below.

Background

PCI SSC announced the new guidance on October 7, 2026, ahead of its Europe Community Meeting in Edinburgh (October 20–22), which includes sessions on AI agents and emerging risks in the cardholder data environment [2]. The Council said the resource was developed with the Global Executive Assessor Roundtable and the PCI SSC Board of Advisors [2]. Trade press coverage on October 9 described the document’s human-approval provisions in detail [3].

The supplement follows an earlier publication by the Council. In September 2025, PCI SSC’s Andrew Jamieson set out a set of AI principles organized by obligation level: one “must” (AI systems must be deployed and managed in compliance with applicable PCI requirements), four “should not” statements, eight “should” statements, and four “may” statements [4]. The “should not” items include AI accessing high-impact secrets such as credentials or cryptographic keys, AI assuming formal responsibility roles, AI generating security-sensitive random values, and fully automated creation and deployment pipelines with no human oversight [4]. The “may” items include AI providing input to approval decisions, provided human authorization is required, and AI autonomously performing fail-secure defensive actions [4].

According to PCI SSC’s own announcement of the new supplement, it is organized into four sections: AI deployment and use, defending against malicious use of AI, PCI standards and AI use, and AI use-case examples [1]. The Council’s blog post also emphasizes frequent, if not continual, monitoring and management of vulnerabilities when defending against AI-enabled attacks [1]. Reporting on the document’s contents describes four working areas: defining access and accountability, testing controls and preparing for failure, protecting sensitive data and credentials, and defending against AI-assisted attacks [3].

A note on sources and scope applies to the rest of this document. The Council’s blog post page carries a publication date of September 15, 2026, whereas the press release is dated October 7, 2026 and trade coverage is dated October 9, 2026 [1][2][3]; this note uses October 7 as the announcement date. The provisions described below on human approval are described as reported by Help Net Security [3] and as stated in the Council’s 2025 principles [4]. Readers should consult the supplement itself for authoritative text before quoting any provision in an assessment or policy document.

Security Analysis

The reported guidance is best understood through five themes: how humans approve agent actions, how accountability attaches to a person, how agents are treated as identities, how inventory and incident response extend to AI, and how all of this maps to existing PCI DSS requirements. The subsections below take each in turn and close with the open questions the available material does not answer.

Two approval models for agent actions

The central operational idea in the reported guidance is that organizations choose, and document, how a human stays accountable for what an agent does. Reporting describes two models [3]. In the first, case-by-case approval, an agent that accesses cleartext cardholder data should have explicit human approval for any action involving that data. In the second, monitored autonomy, an agent performs authorized actions under continuous monitoring without individual approvals, provided the organization has defined the permitted actions, the conditions that trigger a shutdown, and the procedures for reversing changes [3].

The distinction maps to a familiar tradeoff in agent design. Per-action approval limits the blast radius of an erroneous or manipulated action but introduces latency and invites approval fatigue, in which reviewers click through prompts without evaluating them. Monitored autonomy preserves throughput but depends on the quality of the monitoring, the reliability of the kill switch, and the feasibility of rollback. Payment actions can be difficult to reverse once settled, although mechanisms such as chargebacks partially offset this, which suggests that the rollback condition in the second model may be hard to satisfy for money-movement actions. The guidance as reported does not address this directly, and the point is an inference by the authors of this note and not a statement from PCI SSC.

The table below summarizes how the two models compare on the dimensions that matter for design decisions.

The “likely fit” row is the authors’ interpretation and is not drawn from the guidance. CSA’s research on GhostApproval, a trust boundary gap in six AI coding agents, shows why the approval-fatigue risk is concrete: in that work, approval prompts for agent actions could be bypassed through symlink confusion, so that the human approved something other than what executed [11].

Accountability must land on a person

Reporting on the supplement says a suitable individual should formally accept responsibility for AI output and that organizations should specify which actions require human approval [3]. This is consistent with the 2025 principles, which state that AI should not serve as a key custodian or provide management-level authorizations, and that AI may provide input to approval decisions only when human authorization is still required [4]. The practical effect is that a human approver cannot be a nominal sign-off. If an assessor asks who authorized a given agent action, the answer needs to identify a person with the authority and the information to have made the decision.

This has implications for how approval workflows are built. An approval prompt that shows only the agent’s summary of what it intends to do depends entirely on that summary, and if the agent has been manipulated through prompt injection, the summary may itself be compromised. A more defensible design, in the authors’ view, shows the approver the concrete action parameters (the API call, the record set, the destination) as rendered by deterministic code outside the model, and records the approver’s identity and decision in a tamper-evident log. CSA’s runtime-enforcement work, described below, specifies this kind of pre-execution interception and receipt generation.

Agents as identities, with least agency

Reporting on the supplement states that AI tools able to act without direct human involvement should be managed with a least-privilege approach [3]. The Council’s 2025 principles likewise call for limited, context-specific credentials and for considering AI as a potential insider threat in security planning [4]. The newer guidance adds a least-agency formulation: each system receives only the access and capabilities needed for its assigned tasks [3]. CSA’s work on non-human identity governance treats agents in the same way, as identities that need registration, lifecycle management, and revocation in the same manner as other non-human identities [12].

The guidance as reported also advises against combining three properties in one agent: access to sensitive data, the ability to communicate externally, and exposure to unrestricted input from untrusted sources [3]. This combination is a widely discussed precondition for data exfiltration through prompt injection, since an attacker who controls the untrusted input can instruct an agent that holds the data to send it out. Where a workflow needs all three, the guidance recommends splitting responsibilities across agents that hold different permissions [3]. In a payment context, one agent might read tokenized transaction data, a second might handle customer-facing input, and a third might hold outbound communication rights, with a human or deterministic gate between them. The 2025 principles also say AI may access protected payment data via tokenization or single-use PANs, which reduces what is exposed if an agent is compromised [4].

Inventory, shadow AI, and incident response

The reported guidance expects an AI inventory and bill of materials documenting models, versions, hosting, integrations, data policies, and intended users, along with acceptable-use policies and technical controls to identify and restrict shadow AI tools [3]. Incident response plans are expected to cover prompt injection, model poisoning, actions that exceed approved scope, and unauthorized AI tool access to sensitive data [3]. Logs should support investigation without retaining sensitive payment information, and data-loss prevention controls should operate independently of the AI system [3].

The requirement for independent data-loss prevention deserves attention. A control that runs inside the agent’s own context can be bypassed by the same manipulation that subverts the agent. Placing it at the network or data layer, outside the model’s influence, is consistent with the broader security principle of enforcing policy at a point the protected component cannot alter.

Mapping to PCI DSS

The Council’s 2025 principles tie AI governance to existing PCI DSS requirements, citing Requirements 3 and 4 for data at rest and in transit, Requirement 7 for least privilege and need-to-know, Requirement 6 for change management and patching, Requirement 10 for audit logging, and Requirement 12 for policies and incident response [4]. The one-line descriptions of each requirement may reflect the authors’ summary and not the Council’s wording. The implication is that agent approval records, agent identities, and agent logs are likely to be examined under controls that assessors already test. The authors infer that organizations should not expect a separate AI compliance track, and the Council states that AI use does not exempt an entity from PCI requirements [4].

Gaps and open questions

Several questions remain open based on available information. The guidance is an information supplement and not a requirement, so the strength of assessor expectations will become clear only through assessment practice. The reported text does not appear to define what counts as “cleartext cardholder data” access for an agent that processes tokenized or truncated values, nor how approval should work for agents operating at transaction speeds where per-action human review is impractical. Multi-agent delegation chains, in which one agent invokes another, raise the question of which human is accountable at each hop. These gaps should be tested against the primary document.

Recommendations

The recommendations below are the authors’ suggestions, drawn from the reported guidance, and the timeframes are indicative and not sourced from PCI SSC. They are grouped by horizon, beginning with actions that establish visibility and ownership.

Immediate Actions

Organizations with agents that touch the cardholder data environment should begin with an inventory of every agent, model, tool integration, and credential in scope, which supports the bill-of-materials expectation and exposes shadow AI use [3]. Each agent should be assigned a named accountable individual, and the list of actions requiring human approval should be written down. Any agent with access to cleartext cardholder data should be reviewed against the case-by-case approval model, and exceptions should be documented. Teams should also confirm that no agent holds credentials, cryptographic keys, or key-custodian roles, in line with the Council’s 2025 “should not” principles [4].

Short-Term Mitigations

Over the following quarter, teams should separate agents that combine sensitive data access, external communication, and untrusted input, and put a deterministic gate between the resulting components [3]. Approval prompts should show concrete action parameters generated outside the model, and approval decisions should be logged with approver identity, timestamp, and the exact action authorized. Logging should be reviewed so that it supports investigation without capturing PAN or other sensitive payment data [3]. Incident response runbooks should be extended to cover prompt injection, model poisoning, out-of-scope actions, and unauthorized AI access to sensitive data, and the disable mechanism for each agent should be tested [3][4].

Strategic Considerations

Longer term, organizations should decide where monitored autonomy is defensible and where it is not. A reasonable starting criterion is whether the action is bounded, reversible, and observable, which is the authors’ interpretation of the guidance’s preconditions of defined actions, shutdown triggers, and change reversal [3]. Approval fatigue should be treated as a measurable risk, for example by tracking approval rates and review times. Organizations should also engage their Qualified Security Assessors early about how agent approvals and logs will be evidenced, and should monitor PCI SSC follow-up materials discussed at the Europe Community Meeting [2].

CSA Resource Alignment

CSA’s AI Liability Inflection: Enterprise Accountability in the Agentic Era analyzes how regulation, litigation, and governance standards are converging to place legal accountability for autonomous AI agents on the deploying enterprise [5]. That framing is consistent with the PCI SSC expectation that an individual accepts responsibility for AI output, since both place accountability with people in the deploying organization and not with the model. Organizations can use the CSA paper to understand why a PCI approval record may also serve as evidence in contractual or regulatory disputes.

CSA’s research note Meta AI Support Bot Authentication Bypass examines the 2026 Meta AI support chatbot incident, in which an agent delegated identity-changing authority acted without enforced verification [6]. It illustrates the kind of failure that approval and least-agency provisions address: an agent with authority over sensitive account actions and no independent check on those actions. The authorization lessons in that note are relevant to payment workflows that involve cardholder account changes.

The Autonomous Action Runtime Management (AARM) specification, stewarded by CSA and the CSAI Foundation, defines runtime enforcement in which every agent action is intercepted before execution and evaluated against policy, with outcomes that include allow, deny, modify, step-up, and defer, and with tamper-evident action receipts [7][8]. AARM’s step-up and defer outcomes can implement the case-by-case approval model, and the receipts address the need to evidence who authorized what. CSA’s GhostApproval research documents how approval prompts in coding agents can be bypassed, which reinforces the case for showing approvers deterministic action parameters [11], and CSA’s non-human identity governance whitepaper supports treating agents as managed identities [12]. Finally, CSA’s AI Controls Matrix (AICM) v1.1 and MAESTRO threat-modeling guidance provide a control catalog and a threat framework for assessing the agent architectures that PCI assessors will now ask about [9][10].

References

[1] PCI Security Standards Council. “Just Published: Security Considerations for AI Systems.” PCI SSC Blog, September 15, 2026.

[2] PCI Security Standards Council. “PCI SSC Publishes Additional Guidance on Securing AI in Payment Environments.” Press release, October 7, 2026.

[3] Help Net Security. “PCI SSC calls for human approval of AI agent actions involving cardholder data.” Help Net Security, October 9, 2026.

[4] Jamieson, A. “AI Principles: Securing the Use of AI in Payment Environments.” PCI SSC Blog, September 11, 2025.

[5] Cloud Security Alliance. “AI Liability Inflection: Enterprise Accountability in the Agentic Era.” CSAI Foundation, June 27, 2026.

[6] Cloud Security Alliance. “Meta AI Support Bot Authentication Bypass.” CSAI Foundation, 2026.

[7] AARM. “Autonomous Action Runtime Management Specification.” AARM, February 2026.

[8] Cloud Security Alliance. “CSAI Foundation Announces Key Milestones to Secure the Agentic Control Plane.” Press release, April 29, 2026.

[9] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, June 22, 2026.

[10] Cloud Security Alliance. “MAESTRO: Agentic AI Threat Modeling Framework.” Cloud Security Alliance Labs.

[11] Cloud Security Alliance. “GhostApproval: A Trust Boundary Gap in Six AI Coding Agents.” CSAI Foundation, July 15, 2026.

[12] Cloud Security Alliance. “The Non-Human Identity Governance Vacuum.” CSAI Foundation, 2026.