Can we use AI agents in the bank without touching PCI scope at all?

For cardholder-data use cases, complete exclusion is rarely achievable — but containment is. Tokenize or redact card data before it reaches agent-readable stores, expose only the tools agents need through a governed gateway, and document the reachable-surface analysis for your QSA. Many agent use cases (operations, reconciliation, service quality, document analysis) never need raw PAN at all.

What do auditors ask for when agents access regulated systems?

Three things, consistently: who performed each action (per-agent identity, not shared accounts), what policy allowed it (per-call authorization decisions), and prove the record was not altered (append-only, hash-chained audit). If you can produce those three for every agent tool call, the agent conversation becomes an architecture review instead of an objection.

Cloud AI tools are banned here — does on-premise actually work for agents?

Yes, and it is increasingly the default posture in banking. An on-premise MCP gateway runs the mediation layer inside your perimeter — including fully air-gapped deployments — with mTLS identities, OPA policy enforcement, and per-call audit, while the agents themselves run where your model governance allows. No cardholder data needs to leave your network for agents to act on it.

Where should a bank start with agentic AI?

With a read-only use case outside the cardholder data environment: operational reconciliation, incident triage, or service-quality analysis on one system. Deploy an on-premise gateway, register that single source, run for a month with per-call telemetry, and bring the evidence — reachability map, policy decisions, audit completeness — to your risk committee. Expansion follows the evidence.

← All insights

Financial Services

Agentic AI in Banking: Core Systems Access Without Expanding PCI-DSS Scope

Q: Do AI agents fall inside the PCI-DSS cardholder data environment?

Any system that stores, processes, or transmits cardholder data — or can connect to a system that does — is in scope. An agent that can query a card database, a payment gateway, or a system adjacent to them is a candidate for inclusion. The design goal is not to hide agents from the QSA but to keep their reachable surface deliberately small and auditable, so the scope conversation is evidence-based rather than fear-based.

By Talentys · September 16, 2026 · 9 min read

Every retail bank we talk to has the same two-slide problem. Slide one, from the innovation team: agents could reconcile disputes, triage incidents, and answer analyst questions across core systems in minutes. Slide two, from risk and compliance: every new system touching the cardholder data environment (CDE) expands the PCI-DSS footprint — more scoped infrastructure, more controls, more audit, more cost. Both slides are true. The question that decides whether agentic AI ships in a bank is not "can agents do the work" but "can they do it without turning a pilot into a scope expansion." This article is the architecture answer we give — with the caveat up front: nothing here replaces your QSA; it is designed to make the QSA conversation evidence-based.

What actually expands PCI-DSS scope

PCI-DSS scope follows connectivity, not intent. A system is in scope if it stores, processes, or transmits cardholder data — or can connect to a system that does. That "can connect" clause is where agent projects quietly inflate scope:

Broad service accounts. An agent running on a core-banking read credential can reach everything that credential can reach — often far more than the use case needs. The reachable surface, not the intended surface, is what your assessor must consider.
Shared agent infrastructure. A "general assistant" platform with plugins into both the data warehouse and the payments API creates a new path into the CDE that didn't exist in the network diagram — and network diagrams are exactly what scoping exercises audit.
Copies of card data. Agents that receive raw PAN in context windows, logs, or vector stores create new locations where cardholder data lives. Each new location is a new scoped asset.

The pattern: scope grows not because agents do anything wrong, but because they could reach too much, through identities nobody individually owns.

The containment pattern: a governed door, not a new corridor

The fix is architectural: agents never hold credentials to core systems at all. Instead, an on-premise MCP gateway sits between agents and the estate, and becomes the only door:

Agents get identities, not accounts. Each agent authenticates with its own mTLS certificate. There is no shared service account to inherit a blast radius from, and every call is attributable to one agent identity.
Access is expressed as tools, not connections. The gateway exposes narrow, purpose-built MCP tools — "list disputed transactions for case X", "fetch reconciliation summary for date Y" — rather than database or API connections. Reachability becomes a short, enumerable list instead of a network diagram.
Policy is evaluated per call, fail-closed. OPA policies decide per agent, per tool, per argument pattern. A write tool an agent was never meant to call is denied at the gateway — deterministically, outside the model's influence.
Everything is sealed in evidence. Each call lands in an append-only, hash-chained audit trail: identity, policy decision, arguments, result summary, timestamp. When the QSA asks "show me everything this agent could do in March," you export a verifiable record instead of reconstructing from logs.

The consequence for scope: the agent estate's reachable surface is now the tool list, and the data it can touch is what those tools return — ideally tokenized or redacted before it ever reaches agent-readable storage.

Three bank-grade starting points (none touch raw PAN)

Use case	Systems reached	Why it stays contained
Dispute & chargeback reconciliation	Core banking, case management	Card references tokenized; agent sees cases and amounts, never PAN
Payments incident triage	Monitoring, ticketing, gateway status	Read-only operational telemetry; no CDE data path
Analyst research on internal data	Data warehouse (de-identified marts)	PII redaction at the gateway; queries scoped to approved marts
Service-quality document analysis	Complaints archive, CRM	Argument-level injection scanning; per-session call budgets

Notice what is absent: no use case above needs raw cardholder data. In our experience, the majority of high-value banking agent workloads are exactly like this — the CDE is the exception, not the rule, and the architecture should make the exception explicitly gated rather than incidentally reachable.

What to bring to your QSA

Assessors respond to artifacts, not architectures. The gateway deployment gives you four by default:

The reachable-surface map — the enumerated tool list per agent, exportable as documentation of what the agent estate can touch.
The policy decision log — every allow/deny with the policy version that produced it, including denied attempts.
The sealed audit chain — hash-chained, append-only, WORM-compatible; tamper-evidence a QSA can verify offline.
The data-flow record — per call: which source, which fields, redaction applied. Direct input to the data-flow diagram PCI scoping requires.

With those four documents, the agent conversation shifts from "prove agents are safe" to "here is the reachable surface, here is the evidence" — a much shorter meeting.

The on-premise question

Banks with strict data-residency policies often rule out cloud-hosted agent platforms before the architecture discussion starts. An on-premise MCP gateway removes that objection structurally rather than contractually: the mediation layer, the policy engine, the audit chain, and the connectors all run inside your perimeter — including fully air-gapped environments. Cardholder data does not need to leave your network, transit a third party, or sit in a provider's context windows for agents to act on it. This is also why the deployment pattern fits the banking norm: the gateway runs on the Kubernetes the bank already operates, with the same change-control and segregation the rest of the estate is judged by.

Compliance note: ArcaX controls are designed to support PCI-DSS requirements (Requirement 10 audit trails, segmentation-friendly deployment, least-privilege access). "Aligned architecture" indicates architectural readiness, not formal certification — validate scoping decisions with your QSA.

Frequently asked questions

Do AI agents fall inside the PCI-DSS cardholder data environment?

If they can reach cardholder data or systems adjacent to it, they are candidates for inclusion. The goal is a deliberately small, documented reachable surface — so the scoping conversation is evidence-based, not fear-based.

Can we use agents without touching PCI scope at all?

For cardholder-data use cases, containment rather than exclusion: tokenize before agent-readable stores, expose narrow tools through a governed gateway, and document the reachable surface. Most high-value banking workloads never need raw PAN.

What do auditors ask for?

Three things: per-agent identity (no shared accounts), per-call policy decisions, and tamper-evident audit. Produce those for every tool call and the review becomes an architecture discussion.

Cloud AI tools are banned — does on-premise work?

Yes. The gateway runs the mediation layer inside your perimeter — air-gap included — with mTLS identities, OPA enforcement, and per-call audit. No cardholder data leaves your network.

Where should a bank start?

One read-only use case outside the CDE, one source, one month of per-call telemetry — then bring the evidence to the risk committee. Expansion follows the evidence.

Next steps

The banks that ship agentic AI are the ones that walk into the risk committee with a reachable-surface map and a sealed audit trail instead of a demo. That evidence is a deployment artifact, not a consulting deliverable: one on-premise gateway, one contained use case, one month of telemetry.

Request a demo Pair with the Zero Trust checklist