AI Agents Are Entering Payments. Who Controls What They Can Do?

At the 2026 PCI SSC North America Community Meeting in Vancouver, one topic kept coming up: AI agents.

The discussion was no longer limited to using AI for fraud detection, analytics, or customer support. The harder questions began when AI systems could act: find a product, interact with a merchant, access a payment method, and potentially complete a transaction on someone else's behalf.

That shift matters for payment security.

PCI SSC itself put agentic payments directly on the agenda, including workshops on attack surfaces in agentic payment flows and whether PCI DSS requirements apply differently when the actor is an AI agent rather than a person. On the first day of the meeting, the Council also published a new information supplement on securing AI systems in payment environments.

The central issue is not simply whether an AI agent can make a payment.

It is whether you can establish who authorized the agent, what it is allowed to do, what payment information it can access, and what happens when it acts outside the boundaries you intended.

Those questions become more important as companies and consumers give AI agents greater autonomy.

What changes when an AI agent can make a payment?

The further you move toward the third model, the more security depends on what the agent is actually allowed to do. Consider a simple hypothetical example. A consumer tells an AI shopping agent:

Find these headphones for no more than $200 and buy them from one of the retailers I already use.

The agent may need to search merchants, compare products, choose an option, provide shipping information, and initiate payment.

That is very different from asking a chatbot, "Which headphones should I buy?"

The system now has agency. It can act with financial consequences.

A similar situation can happen inside a company. An organization might authorize an AI agent to buy software licenses or supplies from approved vendors up to a defined limit.

Neither example is necessarily unsafe. But both raise questions that traditional user-driven payment flows don't answer automatically.

• What happens if the price changes before checkout?
• Can the agent select a different merchant?
• Can it change the quantity?
• Which payment method can it use?
• Can it make several smaller transactions that collectively exceed the intended limit?

The security model needs to account for those decisions.

Who authorizes an AI agent's payment, and what does that permission cover?

A legitimate AI agent is not automatically authorized to perform every action it can technically perform. Three related questions need to stay separate.

Agent identity asks whether the system interacting with a merchant or payment service is the agent it claims to be. Delegated authority asks who gave that agent permission to act and what limits were placed on that permission. Transaction intent asks whether the specific payment reflects what the consumer or organization actually authorized.

That distinction matters because an authenticated agent can still take an unintended action.

Return to the shopping example. The consumer authorized a purchase below $200 from an existing retailer.

• If the agent finds the right product for $215, should it continue?
• What if the preferred retailer is out of stock and the agent finds it somewhere else?
• What if the seller changes between product selection and checkout?

The agent may not be malicious. The problem may be that its instructions and technical permissions allow it to make a decision the consumer did not expect.

This is one reason the payments industry is working on mechanisms specifically for agentic commerce. Visa's Trusted Agent Protocol, for example, is designed to let merchants verify recognized agents and associated authorization, including transaction-specific interactions.

Visa also describes the product as still being developed and deployed, which is an important reminder that these mechanisms are emerging rather than universally established.

For businesses building or accepting agentic payments, the practical lesson is straightforward: don't treat authentication as the end of authorization.

An agent may be authenticated and still need restrictions on merchant, transaction value, frequency, payment method, duration, or the kinds of actions it can perform without further approval.

Those limits also need to be enforced somewhere reliable. Telling an AI agent in a prompt that it should never spend more than $500 is not the same as having the payment system reject a $501 transaction.

Does an AI agent need access to cardholder data to make a payment?

Not necessarily.

An AI agent may need access to a payment method, but that does not mean the model itself should automatically receive unrestricted access to the underlying cardholder data.

The right design depends on the payment architecture and what the agent actually needs to accomplish.

PCI SSC's AI principles specifically discuss protecting account data used by AI systems and point to payment tokens and single-use PANs as possible ways to support payment activity while limiting exposure.

The Council also notes that controls outside PCI DSS requirements, such as limiting total spend, transaction frequency, merchant use, or credential lifetime, may further reduce risk.

That leads to a useful design question:

Those are not the same thing.

Where architecture allows, an agent may initiate a transaction through a payment service without freely viewing or retaining the full Primary Account Number (PAN). In other implementations, the agent or supporting application may handle payment account data directly.

The difference has implications for both security and PCI DSS scope. Tokenization can help reduce exposure, but it should not be treated as an automatic route out of PCI DSS. Scope still depends on the implementation, including how tokens are created, where the underlying PAN exists, which systems can retrieve it, and what components can affect the security of the cardholder data environment.

Protect the payment data, not just the AI model

AI security conversations can become too model-centric.

A team might spend significant effort protecting the LLM against prompt injection while missing what happens to payment information after the model calls an API or passes data to another component.

The real workflow may include the agent, orchestration software, APIs, payment services, logs, third-party AI infrastructure, plugins or tools, and conventional application components.

Payment data can be exposed at any point where those systems store, process, transmit, log, or otherwise handle it. PCI SSC's guidance reinforces this broader view. It applies existing PCI DSS principles to AI systems, including protecting cardholder data at rest and in transit, limiting access based on least privilege and need to know, and logging relevant actions.

So the right question is not only, "Is the model secure?" It is, "Where does payment data go from the moment the agent decides to purchase something to the moment the transaction is completed?"

How does PCI DSS apply to AI-enabled payment workflows?

AI does not create an exemption from PCI DSS, and it does not automatically put every AI system in PCI DSS scope. PCI SSC's September 2026 Security Considerations for AI Systems takes a practical position: when determining applicable PCI requirements, AI should generally be considered like other technology.

Organizations still need to examine what the system does, what data it handles, what it connects to, and how it could affect payment security. The Council is clear that this information supplement is guidance, not a new set of mandatory PCI requirements.

Which existing PCI DSS control areas matter?

Several existing PCI DSS control areas become particularly relevant when AI systems interact with payment environments. Requirements 3 and 4 address protecting account data, including stored cardholder data and its transmission where applicable. If an AI-enabled application handles that information, those protections do not disappear because an AI component is involved.

Requirement 7's principles of least privilege and need-to-know are especially relevant for agents. An agent that only needs to initiate a narrowly defined transaction should not automatically receive broad access to payment systems or unrelated information.

Requirement 10 addresses logging and monitoring. PCI SSC's AI principles recommend that AI actions be traceable and monitored, with a human responsible for overseeing them.

The Council also points organizations toward Requirements 6 and 11 when considering validation throughout an AI system's lifecycle, and Requirement 12 when considering AI within security policies and incident response.

This does not mean those are the only PCI DSS requirements that could apply. Applicability depends on the environment and the system's role.

The point is simpler: existing controls still matter.

What should organizations review when determining PCI DSS scope?

Start with the architecture, not the label "AI."

Map where payment account data enters the workflow, which components handle it, where it is transmitted, where it may be logged, and which services can affect its security.

Then look at the agent itself.

• What credentials does it use?
• Which APIs can it invoke?
• Can it modify payment parameters?
• Does it interact directly with the cardholder data environment (CDE)
• Does it connect to another system that does?
• Can it affect the security of an in-scope component even if it never sees the PAN directly?

The answers determine whether and how the AI implementation affects the existing PCI DSS scope. That is why adding an AI agent to a payment workflow should trigger a scope review, not an assumption.

Simplify Your PCI Compliance

The path to compliance requires expert guidance. Let GRSee's team help you through the process.

Talk to Us

What safeguards should organizations put in place around AI agents in payment environments?

The exact safeguards will depend on the use case, but three areas deserve particular attention.

Establish and enforce the agent's boundaries

Give the agent only the access it needs to perform its intended task.

That may mean agent-specific credentials rather than shared service accounts, narrowly defined API permissions, limits on transaction values, restrictions on which merchants or services the agent can use, and rules governing when human approval is required.

The enforcement point matters.

If a payment must never exceed a certain value, the limit should ideally be enforced by a control that doesn't depend on the model following an instruction. That same principle applies to merchant allowlists, transaction frequency, credential lifetime, and other boundaries.

A model instruction defines expected behaviour. A technical control defines what the system is actually allowed to do.

Monitor actions and maintain accountability

Greater autonomy should not mean less visibility.

Organizations need enough logging to understand which agent acted, what authorization context applied, which systems were accessed, and what the transaction resulted in.

PCI SSC's AI principles call for logging and monitoring AI actions and for a human individual to remain responsible for those actions. They also recommend designing AI systems so they can be disabled when necessary. That does not answer every legal question about liability for an AI-initiated transaction. Those questions may vary by use case and jurisdiction.

From a security perspective, however, the requirement is clearer. If something unexpected happens, you need to investigate it and intervene.

An organization should know who owns the agent, who can revoke its access, what triggers escalation, and how the team would respond if the agent began behaving outside its intended boundaries.

Test how the agent behaves when something goes wrong

An agent can be properly authenticated, correctly scoped, and still behave unexpectedly when it processes malicious or misleading input.

Prompt injection is an obvious example.

Imagine a purchasing agent that reads content from external websites. A malicious instruction embedded in the content could try to redirect the agent, change its objective, expose information or improperly invoke one of its connected tools.

PCI SSC specifically warns about malicious inputs such as prompt injection and data poisoning, which could cause AI systems to perform privileged actions, disclose sensitive information, or change behaviour.

OWASP's Top 10 for Agentic Applications similarly identifies risks such as agent goal hijacking, tool misuse, and identity or privilege abuse.

Testing therefore needs to cover more than whether the model generates an undesirable answer.

For a payment agent, the higher-value questions are whether manipulated inputs can change payment parameters, bypass approval boundaries, invoke tools the agent should not use, expose sensitive data, or cause transactions outside the intended scope.

A simple way to review an agentic payment use case is to ask:

This is not a PCI DSS checklist. It exposes gaps that become important once software is allowed to make payment decisions.

Key takeaways

• Agent identity is not the same as transaction authority. A legitimate agent still needs defined limits on what it may do.
• Payment capability does not automatically require unrestricted cardholder data access. Design the workflow around the minimum information and permissions needed.
• PCI DSS still applies based on the actual environment. Scope AI based on its data handling, integrations, and ability to affect payment security.
• Controls need to exist beyond the model itself. Technical restrictions, monitoring, testing, and revocation mechanisms are what keep delegated authority within its intended boundaries.

Assess your AI payment risks with GRSee

The discussions in Vancouver made one thing clear: agentic payments are moving from an interesting AI concept to a practical payment security question.

The answer is not to create a separate security universe for AI. It is to understand exactly what the agent can do, how payment account data moves through the workflow, which PCI DSS requirements apply, and where the organization needs stronger technical or governance controls.

GRSee works across both sides of that problem.

Our PCI DSS assessment services help organizations understand their payment environment, define scope, identify gaps, and prepare for the appropriate assessment.

Our AI Risk Assessment examines how AI is used across the business, including data handling, third-party dependencies, model security, and accountability. Where technical validation is needed, our AI penetration testing services assess AI-enabled systems for issues such as prompt injection, data leakage, model manipulation, and misuse of connected functionality.

If your organization is introducing AI agents into payment workflows, the useful starting point is not "Are we using AI?" It is: "What have we allowed the agent to do, what can it reach, and are the controls around that authority strong enough?" That is the question worth answering before the agent clicks "Pay."

Expert PCI DSS Guidance

Partner with GRSee Consulting to guide your startup through PCI DSS compliance.

Expert gap analysis to identify and fix security weaknesses quickly.

Certified QSAs to manage audits and ensure smooth certification.

Continuous monitoring and support to keep your certification current.

Learn More