PCI DSS: scope discipline before anything else
Every PCI DSS conversation about AI should start with scope, not features. If cardholder data never enters the AI path, most of this is a short conversation. If it can enter, the gateway is a component in scope and every control below applies.
- The instrument
- PCI DSS v4.0.1, with the future-dated requirements mandatory since 31 March 2025
- Status
- In force
- Who it applies to
- Merchants and service providers whose AI use cases can reach cardholder data.
Where AI-FW fits
PCI DSS is assessed against the cardholder data environment. An AI gateway is in scope the moment cardholder data can reach it, through a prompt, an uploaded file, an agent payload or a model response. AI-FW's most valuable contribution is provable exclusion: a blocking rule and a data-flow statement that keep the AI path out of the environment altogether.
What stays with you
Read this list first. It is the boundary of what a product can do for you, and it is where the remaining work sits.
- Network segmentation, firewalling and wireless controls
- Physical security, and the annual penetration test
- Approved scanning vendor scans
- Key custodian procedures for the keys you supply
- Personnel screening and security awareness training
What the framework asks, and what the product does
The obligations that touch the AI path, paired with the capability that answers each one. Everything else in this framework is organisational work, listed above.
Reduce where cardholder data lives and flows
A blocking rule for card number patterns, so the AI path can be documented as out of scope rather than argued about
Protect stored cardholder data, and mask the number on display
Metadata-first capture, masking rules for card data, and no raw prompt or response storage unless your policy turns it on
Protect keys and never expose them
Provider credentials held server-side, secrets masked in configuration, and no key material inside evidence packs or logs
Encrypt cardholder data across open networks
TLS on every listener endpoint and on upstream model calls
Build and maintain secure systems, and manage vulnerabilities
Images pinned by tag and digest, with dependency vulnerability review as part of release checks
Protect public-facing applications from attack
Prompt and response inspection for injection and abuse patterns, with rate and quota enforcement to bound how hard a caller can try
Limit access by business need to know
Role policies, per-agent identity, owner-scoped views, and an audit trail of every access change
Identify users, and use strong authentication
Hashed and revocable keys, client certificates validated against your trust anchors, and Kerberos with allowlists
Record who did what, when, from where, and whether it succeeded
Transaction and access records with identity, model, outcome, source and timestamp, plus a separate record of administrative change
Review records, and detect failures
Activity, error and access views for routine review, and drift findings raised when a required rule is switched off
Keep twelve months, with three months readily available
Retention is a setting, so the twelve-month requirement is a value rather than a limitation
Know and manage your service providers
A model inventory that enumerates every provider and endpoint in the AI path, ready for the responsibility matrix
A rule pack to start from
The enforcement that makes the controls real. Severity runs 1 to 5, and a rule that is switched off reports as a gap, so these are meant to be live from day one.
Keeping card data out of the AI path is the scope decision that matters most
A model can repeat what it was given, including across a conversation boundary
Files and logs are the routes people forget
Public-facing application protection
Keeps the third-party register true by construction
What the evidence pack contains
Per period, and without prompt or response content, which is what makes it safe to hand over.
- Card-data block rule stateEnabled: a disabled scope rule is a scope-changing event
- Masking rule stateWhere content capture is on, masking is applied
- Retention valuesAt least twelve months, with evidence retention aligned
- Authentication configurationOnly the methods in use, with no shared credentials
- Third-party inventoryEvery provider and endpoint in the AI path
Customer responsibilities and sources
- Determine and document whether cardholder data can enter the AI path, and include the gateway in scope if it can.
- Segment the network, control wireless access and secure physical locations.
- Run vulnerability scanning and the annual penetration test.
- Operate key management procedures and custodian duties for any key you supply.
- Screen personnel and run security awareness training, and maintain the responsibility matrix for third parties.
Common questions
No, and that distinction is worth money. It is in scope if cardholder data can reach it. If you can show a blocking rule that refuses card number patterns, plus a data-flow statement that documents the boundary, the strongest position is that the AI path stays out of the cardholder data environment. If card data can enter, everything above applies.
Masking protects the value while it is stored or displayed. Blocking prevents the value from entering the path at all, which is what keeps the system out of scope. Masking still matters where content capture is enabled, but it is the second line, not the first.
No. Records carry identity, model, decision, rule, outcome and timing. Evidence packs exclude payloads, so there is no card data and no secret material in the artefacts you hand to an assessor.
Validate it yourself with our Technical Plan
Ask us to run this framework against your own environment: the rules that would be created, what the assessment reports, and what the evidence pack contains for a real period.
This page maps product capabilities to published expectations. It is not legal, audit or certification advice, and it creates no compliance representation. Applicability and sufficiency are judgements for your counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed; check the primary sources above, and the page itself, before relying on a date or a threshold.