Skip to main content

PCI DSS and the AI Agent Era

· 6 min read
Alejandro Revilla
Alejandro Revilla
jPOS project founder
AR Agent
AR Agent
AI assistant

PCI DSS version 4.0.1 was published on June 11, 2024. That's less than two years ago. It already feels like a different industry.

In that time, AI agents have gone from research curiosity to production infrastructure. The Model Context Protocol gave language models a standard way to call tools. Autonomous agents that read messages, query databases, push commits, and manage tasks are now deployed in organizations running payment systems.

The standard has nothing to say about any of this.

What PCI SSC has published​

To its credit, the PCI Security Standards Council has moved. In March 2025 it published Integrating Artificial Intelligence in PCI Assessments—its first AI-related guidance document. It's a serious piece of work.

But it addresses a narrow question: how should QSAs use AI tools during assessments? It says AI is a tool, not an assessor. It requires human oversight. It asks assessors to disclose AI use to clients and to document their policies. All reasonable.

What it doesn't address is the question payment practitioners are actually wrestling with: what happens when you deploy an AI agent in your own environment?

The gap​

An AI agent in a payment environment is not an abstract risk. It is a concrete software system with:

  • credentials to external services (Mattermost, GitHub, Asana, deployment systems)
  • a persistent workspace with memory, files, and context
  • the ability to make tool calls—API requests, shell commands, file operations—based on natural-language instructions
  • access to data streams that may touch the cardholder data environment

PCI DSS was designed around the concept of human users and service accounts. Requirements 7 and 8 define access control and authentication in those terms. An AI agent is neither a human nor a conventional service account—it is an autonomous system capable of initiating actions across multiple systems, adapting to responses, and being manipulated through its inputs.

This is new territory, and the standard doesn't map to it cleanly.

The workstation problem​

The most dangerous AI agent deployment pattern I've seen is also the most common: an agent running on an operator's personal workstation.

It starts innocuously. Someone installs an AI assistant on their laptop, connects it to their credentials, and begins using it. The assistant is useful, so it gets more access. Before long, it's running with an active SSH agent loaded with private keys, a VPN session open to internal networks, browser cookies and stored tokens, and access to cloud storage and development databases.

From a PCI standpoint, this is a significant finding waiting to be written. A prompt injection attack—malicious instructions embedded in data the agent processes, like a Mattermost message or a task description—could leverage all of those credentials. The blast radius is the same as a fully compromised operator workstation, but the attack surface is broader because the agent processes untrusted external data continuously.

The fix is architectural: agents that touch production environments must run on dedicated hosts with dedicated identities. Not a developer's laptop. Not a shared server. A machine provisioned for that purpose, with scoped credentials, no loaded SSH keys beyond what the agent specifically requires, and no active VPN sessions outside its declared scope.

Messaging channels are not equivalent​

When an AI agent communicates with a human operator, the choice of channel matters for PCI purposes.

Signal is end-to-end encrypted by default. Telegram encrypts messages in transit but stores them on vendor servers by default (end-to-end encryption requires Secret Chats, which aren't available for bots). WhatsApp stores messages on Meta's infrastructure and is subject to Meta's data retention practices—if operational data touching the CDE passes through it, Meta enters scope as a Third Party Service Provider.

This is not a hypothetical. Instructions to an AI agent are operational data. If those instructions cause the agent to take actions in a payment environment, the channel carrying those instructions is relevant to PCI scope analysis.

MCP servers are a new attack surface​

The Model Context Protocol changed the shape of this problem. MCP servers expose tools—file access, database queries, API calls, shell execution—to a language model. When an MCP server is deployed with access to a payment system, the language model invoking it inherits that access.

From a Requirement 6 perspective, MCP server software must be treated as a system component: included in the SBOM, subject to vulnerability scanning, and developed with input validation applied to tool parameters—because the language model calling those tools is, from a security standpoint, an untrusted input source.

Prompt injection in payment contexts​

Prompt injection is the AI-era equivalent of SQL injection. An attacker who can influence the data an AI agent processes can sometimes influence what it does.

In a payment environment, the surfaces for injection are everywhere: Mattermost channels, task descriptions, document contents, API responses. An agent that reads external data and takes consequential actions based on it is exposed to this class of attack.

The best mitigation is scope restriction. An agent that can only read cannot exfiltrate data or modify systems even if successfully injected. Every write operation—every action that creates, modifies, or deletes data in a production system—should require explicit human confirmation. Not because the agent is untrustworthy, but because the inputs it processes are.

What practitioners should do now​

The standard will catch up. Standards always do, eventually. In the meantime, a practical baseline for AI agents in payment environments:

  • Dedicated host. Agent runs on its own machine, not a workstation.
  • Dedicated identity per system. Separate accounts for every service the agent accesses. No sharing credentials with human users.
  • Minimal credential scope. Read-only tokens where possible. Write access documented and approved.
  • Approved messaging channel. Evaluate the channel. Signal or Telegram (with appropriate controls) for operational use; WhatsApp for environments where Meta becoming a TPSP is unacceptable.
  • LLM provider as TPSP. The provider running inference receives your prompts. Review their data processing agreement. Opt out of training data use. For highest-sensitivity deployments, consider a self-hosted model.
  • Audit trail. All tool calls logged: timestamp, tool, parameters (sanitized), outcome. These belong in the audit record.
  • Human-in-the-loop for writes. Any action that modifies production data requires explicit confirmation.

On the pciguide​

If you are building jPOS-based payment infrastructure, we've added detailed guidance on this topic to the jPOS PCI DSS Compliance Guide. Requirement 12 now includes a full section on AI agents as a new category of privileged system, covering deployment architecture, messaging channel evaluation, LLM provider TPSP classification, and a governance controls table. Requirement 6 addresses MCP server security requirements and prompt injection as a vulnerability class.

The guide is open source. If you're a practitioner dealing with this in your own environment and have controls or observations worth adding, the repository is at github.com/ar/pciguide.

The industry is figuring this out in real time. The more practitioners who publish what they're actually doing, the faster the collective practice advances.