PCI DSS 4.0 and AI coding agentsWhich requirements apply. What to fix first.

PCI DSS 4.0 became the only accepted version in March 2024. Stricter enforcement landed in March 2025. Most SAQ A and SAQ A-EP shops adapted their prod infrastructure without too much trouble. Dev environments are a different story.

The problem is specific. A developer exports STRIPE_SECRET_KEY in their shell to test a webhook flow. They open Claude Code or Cursor. The agent reads the full environment, including that key. It might write a test fixture with the value inline. It might persist the key in a local state file. The dev workstation, which was nowhere near your cardholder data environment two years ago, now touches live payment credentials.

Under PCI DSS 4.0 requirement 12.5.2, you confirm the scope of your cardholder data environment annually. The AI tools your developers use during payment feature work belong in that scope review. Most shops have not done this yet.

The February 2026 Knostic disclosure showed exactly how this goes wrong: Claude Code's settings.local.json file was capturing environment variables, including API keys, and the file ended up in published npm packages. That specific bug is patched. The underlying pattern is not. If the key was in the agent's environment, the key was at risk.

The short version

• PCI DSS 4.0 does not have an AI-specific section. It applies existing requirements to the new surface.
• A live Stripe key in a dev agent session expands your cardholder data environment to include that workstation.
• Requirement 12.5.2 (annual scope confirmation) means you have to document this.
• Tokenization drops most of the obligation. If your agents never touch raw card numbers, you have already handled the hardest part.
• The dev environment is the gap. Prod infrastructure is usually tighter. The live-key-for-local-testing habit is where most SAQ A shops are exposed.

Which PCI DSS 4.0 requirements apply to agents

Requirement 3.5: primary account numbers must be unreadable wherever stored

Stripe and other payment processors use tokenization to keep raw PANs off your systems. That is why SAQ A exists: you iframe the payment form, Stripe handles the card number, you get a token. Your systems never see the PAN.

The problem comes from test fixtures. Developers sometimes use real card numbers in test files to debug edge cases. An agent reads those fixtures and may output, log, or store the value during a session. If a raw PAN appears in an agent's context window and the agent writes it to a state file, you have a requirement 3.5 violation regardless of whether your prod systems are clean.

The fix is strict: never put real card numbers in test data, even in sandboxed dev environments. Stripe's test card numbers (4242 4242 4242 4242, 4000 0025 0000 3155, etc.) exist for this reason. Use them everywhere an agent might read fixture data.

Requirement 7.2.4: confirm that access to system components is least privilege

This requirement asks you to verify that each account and role can access only what it needs, and only from systems where that access is justified.

An AI agent that runs with a developer's full environment, including their live Stripe restricted key with charges:write, has more access than a role reviewing webhook logic needs. If the developer's role was scoped for development work, passing live payment API credentials to an automated agent process almost certainly violates 7.2.4.

The fix is role separation. Test keys have no payment throughput. If the agent does not need live key access to complete the task, do not give it live key access.

Requirement 8.3.6: MFA for non-console administrative access to cardholder data systems

Developers authenticate to their machines. They do not re-authenticate when they start an agent session. The agent inherits the authenticated session and any credentials in the environment.

This is a compensating control problem, not a hard violation: most QSAs accept that local process inheritance does not require per-agent MFA. The requirement becomes relevant when an agent takes authenticated actions against remote systems in the cardholder data environment, for example, updating Stripe webhook configurations via API. In that case, the agent is acting as an administrative actor without any MFA event on record.

Document the compensating control: the agent runs only on the developer's workstation, behind their authenticated session, with keys scoped to the minimum permission set required for the task. That documentation needs to exist before your QSA visit, not after.

Requirement 10.x: audit trails for system components in the cardholder data environment

If a workstation or process touches cardholder data, actions from that workstation belong in your audit trail. That includes agent sessions that used live Stripe keys.

Most AI agents produce no durable audit log of their own. Claude Code does write per-session logs, but they are not in a format your QSA will accept as a compliant audit trail. The log needs to show who (the developer), what (which key, which API call), and when.

The practical answer for now: route all live-key agent activity through a session that logs to your SIEM. Or, more practically, do not let agents touch live keys at all, which eliminates the audit trail problem entirely.

Requirement 12.5.2: annual scope confirmation of the cardholder data environment

This is the administrative requirement with the broadest reach. Every system, tool, or process that stores, processes, or transmits cardholder data, or that connects to a system that does, belongs in your scope.

AI coding agents that are granted live payment credentials during development sessions are now in scope. So is the machine they run on. So is any file they write to on that machine.

If your scope review has not included your AI development tooling, it is incomplete. Add it before the next review cycle. The list to document: which AI tools developers use, which credentials those tools can access, and what the data handling policy is for agent session output.

Tokenization is your floor

If your shop processes payments through Stripe, Adyen, or Braintree, tokenization has already done most of the compliance work for you. The payment processor holds the PAN. Your systems hold a token. Your AI agents, if they work only with tokens, are largely outside the hardest PCI requirements.

This is why SAQ A exists as a reduced validation questionnaire. The cardholder data environment is deliberately small. Tokenization plus iframe or hosted payment page keeps it that way.

The scope creep problem with AI agents is that developers pull live keys into dev environments for convenience, and those keys are not tokens. A live Stripe secret key is a capability to charge cards. An agent session that reads it is now touching something PCI-relevant even if the agent never sees a card number.

Tokenization saves you 90% of the obligation. The remaining 10% is keeping the keys that control your Stripe account away from automated processes that you cannot fully audit.

The dev environment trap

Production is usually cleaner than development. Prod gets the security review. Prod gets the access controls. Prod has the documented roles and the SIEM.

Development environments run on developer laptops, with keys exported to shell profiles, test fixtures checked into repos, and AI agents reading ambient environment state. The February 2026 Claude Code disclosure illustrated the gap: the agent was not in prod, but it was reading live credentials and persisting them to a file that ended up in published packages.

For PCI purposes, "dev environment" is not a safe harbor. If a dev workstation touches live Stripe credentials, it is in scope. Period.

The trap most SAQ A shops fall into is using test mode for most work but switching to live mode to debug a specific webhook behavior. The agent is running, the key swaps, and the dev workstation becomes a scoped system for the duration of that session.

The discipline to build: test keys for agent-assisted work, always. Live keys only for human-supervised, logged sessions. No exceptions for "just a quick check."

What the conventional advice misses

Most PCI guidance for developers focuses on the production path: encrypt at rest, TLS in transit, rotate secrets quarterly, enforce MFA. That advice is correct and insufficient.

The weak point in AI-assisted development is not prod. It is the informal handoff where a developer exports a live key to debug something and forgets to remove it. An AI agent that runs in that shell session for the next two hours has read a live payment credential. If the agent wrote a state file, a test fixture, or a log entry containing that key, you now have a PCI-relevant artifact sitting in a dev directory.

Standard secret rotation guidance does not cover this. You rotate the key on a schedule. The leaked value from three sessions ago is still in the agent's old state file in a directory you have not touched in a month.

The Knostic disclosure is the worked example. The breach disclosure obligation under PCI DSS section 12.10 applies if a live payment credential is compromised. "The agent read it but I don't think it went anywhere" is not a documented compensating control.

Compliance checklist for agent-enabled dev shops

PCI DSS 4.0 AI agent audit (SAQ A / SAQ A-EP)

Scope
- [ ] AI coding tools (Claude Code, Cursor, Codex, Aider) added to annual scope inventory
- [ ] Dev workstations with agent access to live payment keys identified and documented
- [ ] Agent session output directories added to data flow diagram

Credential handling
- [ ] Live Stripe / Adyen / Braintree keys absent from developer shell profiles (~/.zshrc, ~/.bashrc)
- [ ] .env files with live keys excluded from agent-readable directories
- [ ] Test keys confirmed for all agent-assisted dev work (Stripe sk_test_..., not sk_live_...)
- [ ] No raw PANs in test fixtures (use Stripe test card numbers only)

Agent configuration
- [ ] Agent state directories (.claude/, .cursor/, .aider/) in .gitignore
- [ ] Same directories excluded from any artifact that ships (npm, Docker, PyPI)
- [ ] Agent invocation wrapped to strip live payment keys from inherited env

Access control (req 7.2.4)
- [ ] Live key access restricted to human-supervised sessions
- [ ] Agent processes confirmed to run with minimum-permission key scopes
- [ ] Compensating control for MFA bypass documented (req 8.3.6)

Audit trail (req 10.x)
- [ ] Agent sessions touching live credentials logged to SIEM or equivalent
- [ ] Log retention confirmed to meet 12-month requirement
- [ ] Log format sufficient for QSA review (who, what, when)

Test data
- [ ] Test fixtures reviewed for real card numbers
- [ ] Automated scan for PAN-shaped strings in repos (16-digit sequences matching Luhn)

What this means for your stack

The structural problem is that AI agents inherit whatever credentials live in the developer's environment, and most dev environments are not scoped as cardholder data environments. The fix is not purely technical. It requires a policy that keeps live payment credentials out of agent sessions, a scope inventory that includes AI tooling, and documented compensating controls for the MFA and audit trail gaps.

hasp is one working implementation of the technical layer. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent gets a reference instead of the live key. Session-scoped, process-tree-contained, HMAC-chained audit log included. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

The policy layer is yours to own regardless of tooling. Document which AI tools your developers use, which credentials they can access, and how agent session output is handled. That documentation is what your QSA will ask for at the next review.