How to use this tool

Agent Payment Flow Simulator — Guide

A walkthrough of the Agent Payment Flow Simulator: what the four placement options mean, how to read the scope analysis and PCI controls panels, and how to use the exported Architecture Brief in your design and compliance process.

What is this tool for?

Where you deploy an AI payment agent in your architecture has significant consequences for your PCI DSS scope, your network segmentation requirements, and the security controls you need to implement. The wrong placement can put your entire infrastructure in PCI scope — or worse, expose cardholder data to an agent that has no business seeing it.

The Agent Payment Flow Simulator is a PCI DSS Scope Analyser. It shows you a live architecture diagram for each of the 4 standard placement options, lists the PCI controls triggered by each, and generates an Architecture Brief you can use as design documentation or QSA evidence.

This tool does not write code. Its output is a placement decision document — the first artefact you should produce before writing any agent infrastructure.

Step-by-step walkthrough

Step 1 — Select a placement option
  1. Click one of the 4 placement cards at the top: Before API Gateway, After API Gateway, Inside CDE, or Parallel via Step Functions.
  2. The architecture diagram on the left updates immediately — it shows the zone layout (Internet, Edge, App Tier, CDE) and places the pulsing amber agent node in the corresponding position.
  3. The scope analysis panel on the right updates with: in/out of scope badge, a plain-English analysis paragraph, "Suitable for" chips (green), and "Risks" chips (red).
Step 2 — Review the PCI controls triggered
  1. Below the scope analysis, the PCI controls triggered panel lists each relevant requirement (Req 1.3, 3.5, 6.4, 8.2, 10.2, 11.3, 12.3) with a status dot.
  2. Green dot: this control is satisfied by the placement pattern itself. Amber dot: the pattern partially satisfies this control but you need to add configuration. Red dot: this placement introduces a risk against this requirement that needs active mitigation.
  3. For amber and red items, review the control description and plan your mitigation before finalising the placement decision. If you cannot mitigate a red item, consider a different placement.
Step 3 — Export the Architecture Brief
  1. Click Export Architecture Brief to download a .md file named agent-placement-brief-{positionId}.md.
  2. The brief includes: placement name and rationale, full scope analysis, list of triggered PCI controls with status, "suitable for" and "risks" summaries.
  3. Store this file in your architecture documentation alongside your network diagram and DFD. Present it to your QSA as evidence of a deliberate, documented placement decision.

The four placement options

Inside CDE is rarely the right choice for AI agents. Unless your agent's core function requires direct access to raw cardholder data (card numbers, CVVs), the parallel Step Functions pattern achieves the same result with far less compliance burden.
Before API Gateway (Edge)
The agent intercepts requests at the edge before they reach your API Gateway. Reduces latency for early fraud decisions but increases PCI scope significantly — the agent sees raw payment data before any tokenisation.
After API Gateway (App Tier)
The agent sits in the application tier after API Gateway. This is the most common placement — the agent has access to authenticated, validated requests but operates behind your API security layer. PCI scope depends on whether your agent accesses CDE data.
Inside CDE
The agent is deployed inside the Cardholder Data Environment. Maximum capability but maximum PCI scope — every PCI requirement applies to the agent and its infrastructure. Avoid this unless the agent's function genuinely requires direct CDE access.
Parallel via Step Functions (Recommended)
The agent runs in a parallel execution path orchestrated by Step Functions, outside the CDE. Communicates with CDE systems through tokenised references only. This is the recommended pattern — the agent gains orchestration capability without expanding PCI scope.

Key terms

PCI ScopeThe set of AWS resources (and the people and processes that interact with them) that must comply with PCI DSS requirements. Any resource that stores, processes, or transmits cardholder data — or is connected to one that does — is in scope.
CDECardholder Data Environment — the systems that store, process, or transmit primary account numbers (PANs), CVVs, or expiry dates. Placing an agent inside the CDE subjects it to all 12 PCI DSS requirements.
Network SegmentationThe use of firewalls, security groups, and VPC configuration to isolate in-scope systems from out-of-scope systems. PCI Req 1.3 requires adequate segmentation to reduce scope.
Step Functions ParallelAn AWS Step Functions pattern where the agent executes in a parallel branch, orchestrating calls to CDE systems through tokenised references rather than direct access. Keeps the agent out of PCI scope.
Data Flow Diagram (DFD)A diagram required by PCI DSS showing all flows of cardholder data across your environment. Used to define scope and identify where controls are needed. The Architecture Brief from this tool feeds into your DFD.
TokenisationReplacing a sensitive value (card number, CVV) with a non-sensitive token before it leaves the payment processor. An agent that only sees tokens is out of PCI scope for that data element.

Frequently asked questions

Ready to analyse your agent placement?
Select a placement, review the PCI scope analysis, and export your Architecture Brief.