Prompt Injection Defense for Banks: Limiting the Blast Radius

You cannot filter prompt injection away, so a bank’s defense has to assume that some injected instruction will eventually reach the model. The question that matters is what the agent can do when it does. That is blast-radius design: restrict what the agent can reach, put a human approval step in front of high-risk actions, log every decision, and test every agent before and after each change.

This article is a Q&A for CIOs, CTOs, COOs and compliance leads at banks, wealth managers and fintechs who are moving AI agents from pilot to production. It stays with what the primary sources support and says plainly where the evidence stops.

S-PRO

Keep Banking AI Within Safe Boundaries

S-PRO builds AI agents for financial services, with solutions designed for FINMA, DORA and other regulatory requirements.

Explore S-PRO’s AI services

TL;DR

Prompt injection is a risk to design around, not a bug to patch. OWASP states that no prevention method is foolproof, so limit the damage an injected instruction can do.
Give each agent the narrowest permissions it needs, with no administrative credentials, and run high-risk actions in deterministic code outside the model.
Require human approval for actions that move money, change client data or send information outside the bank.
Log every guardrail decision, and run an evaluation suite on every agent, repeated after each model or prompt change.
Map the work to your supervisory frameworks: DORA testing for EU-regulated entities and FINMA Guidance 08/2024 for Swiss institutions.

What prompt injection means for a bank agent
What the best published numbers actually say
Blast-radius design: four decisions per agent
Evaluation on every agent
Supervisory angle: DORA and FINMA
Our perspective
Building this into a pilot-to-production plan
How S-PRO helps
FAQ
Sources

What prompt injection means for a bank agent

What is the difference between direct and indirect injection?

In a direct injection, the person typing into the agent crafts input that changes its behavior. In an indirect injection, the instruction hides in content the agent reads while doing its job. OWASP’s LLM01 entry on prompt injection draws exactly this line, and adds that such inputs can affect a model even when a human cannot see them.

For a bank the indirect case is the harder one. A chatbot facing clients is one surface. A KYC agent that reads uploaded passports, corporate registry extracts and adverse media is another, and so is a relationship manager copilot summarizing inbound emails. Each of those channels carries text written by someone outside the bank.

Why are banks more exposed than most?

Because agents in banking are useful only when they are connected: to a CRM, a document store, a screening list, sometimes a payment or messaging system. Connection is what turns a manipulated sentence into a manipulated action. A model that can only draft text produces a bad draft. A model with a send button and a client list can produce a data leak.

The UK National Cyber Security Centre made the same point about banks early on. In its post on building with LLMs, it describes an LLM assistant for account holders and how an attacker could use it to push through unauthorized transactions. The lesson is about architecture rather than any single product.

Is there a reliable filter?

No. OWASP lists mitigations, including least privilege, human approval for high-risk actions, labeling untrusted content and adversarial testing, and says that no method is foolproof. A classifier or a system prompt can reduce the rate of successful attacks. Neither is a boundary you can rely on alone.

There is a subtler trap. A second LLM acting as a guardrail is still an LLM. The OWASP prevention cheat sheet makes the practical argument that defensive layers should differ in their attack surface from the model they protect, for example purpose-built deterministic checks, instead of another chat model that may share the same weaknesses.

What the best published numbers actually say

How much do defenses reduce risk?

The most useful public data point comes from Anthropic. In its 24 November 2025 post on prompt injection in browser use, the company reports that, against an internal adaptive attacker in a browser-agent test, its defenses brought the attack success rate to about 1%. Anthropic is equally direct about the limit: “No browser agent is immune” to prompt injection.

Read that number carefully. It describes one test, one kind of agent, and one internal attacker. It is not a figure for banking workflows, and it is not a promise for any other deployment. We do not have, and do not cite, an attack-success figure for banks. What the result does show is that layered defenses move the odds, and that a residual risk remains even for a well-defended agent. That residual is what blast-radius design is for.

What should a CIO take from this?

Two things. First, do not accept a vendor claim of immunity from any model provider, including ours or anyone else’s. Second, treat the residual rate as a design input: if one attempt in a hundred could succeed under adversarial pressure, the consequence of that one attempt must be survivable by design.

Blast-radius design: four decisions per agent

Every agent in a bank should go through the same four questions. They are not a product feature list. They are the questions a security review should be able to answer on one page.

1. What can the agent reach?

Start from least privilege. The OWASP cheat sheet advises against giving an LLM agent administrative credentials or broad API tokens. In practice that means:

Read scope. The agent sees only the client records and document folders needed for the task in front of it, resolved per session, not the whole CRM.
Write scope. Most agents should write to a staging area, such as a draft, a case note or a proposed field value, not to the system of record.
Tool scope. Each tool is a narrow function with typed parameters. “Look up screening hit by ID” is a tool. “Run this query” is a hole.
Egress. Limit where the agent can send data. An agent that can read client files and also call arbitrary URLs or send external email has the two halves of an exfiltration path.
Identity. The agent acts with its own service identity, subject to the same access reviews as a human user, and the human on whose behalf it works is recorded in every log line.

A useful test: if an attacker took over the agent’s next instruction completely, what is the worst thing it could read, change or send? Write that sentence down for each agent. If it makes the risk committee uncomfortable, the scope is too wide.

2. Which actions need human approval?

Sort every action the agent can take into three classes.

Class	Examples in a bank	Control
Read and summarize	Summarize a KYC file, draft a meeting note, pull a policy paragraph	Agent acts alone, output labeled as AI-generated
Reversible write	Propose a risk rating, tag a document, draft a client email	Agent acts into a staging area, a named person accepts or rejects
High-risk or irreversible	Release a payment, change account or beneficiary data, send client data externally, close a screening alert	Executed by deterministic code outside the model, only after explicit human approval

The cheat sheet’s principle is that high-risk actions run outside the model’s control, behind an approval step that applies whatever the model outputs. The approval screen should show the action itself, in plain language and with the actual parameters, not the agent’s own description of what it is about to do. A reviewer who reads only the model’s summary can be misled by the same injection that fooled the model.

Also watch for approval fatigue. If reviewers approve 99 of 100 prompts in two seconds each, the control exists on paper only. Keep the approval class narrow and meaningful, and measure how long reviewers actually spend.

3. How do we treat untrusted content?

Treat every channel the agent reads as untrusted: retrieved documents, API responses, email bodies, conversation history and free-text fields such as transaction descriptions or counterparty names. Internal does not mean safe. Anything a client, counterparty or third party could have typed into is attacker-reachable.

Two practices help:

Label and separate. Keep trusted instructions apart from external data and mark the external material clearly as data. OWASP lists labeling untrusted content as a mitigation. Its cheat sheet adds a warning worth repeating: text labels and prompt wording are not an enforcement boundary. Labels lower the likelihood of confusion. Permissions and approval gates are what enforce.
Constrain outputs. Where the agent’s result feeds another system, require a fixed schema and validate it in code. Free text that flows straight into a downstream tool is how one injected sentence becomes an action.

4. What do we log?

Log more than model responses. For each run, record:

The inputs and their sources, including which documents were retrieved.
Every tool call with parameters, and the result.
Every guardrail decision: what was blocked, what was allowed, and by which control.
Every human approval or rejection, with the approver and the time.
The model version, prompt version and configuration in force.

This serves two purposes. It gives incident response something to reconstruct, and it gives you a signal. A drift in approval rates, or a sudden change in refusal patterns, can indicate that someone is probing the system. Logs that nobody reads are only evidence after the fact, so assign an owner and thresholds for alerts.

Evaluation on every agent

Why is testing once not enough?

Model outputs vary between runs, and models and prompts change. A case the agent resisted last month may succeed after an update. So the evaluation suite is a regression suite: a maintained set of adversarial cases, run repeatedly, and rerun whenever the model version, system prompt, tools or data sources change. A release that fails a previously passing case does not ship.

What belongs in the suite?

Build it from your own agent’s surfaces, not from a generic list:

Direct attempts to override instructions through the user channel.
Indirect payloads placed in the documents and fields the agent actually reads: a PDF annex, a registry extract, an email signature, a payment reference.
Attempts to make the agent call a tool outside its task, widen its own scope, or reveal other clients’ data.
Attempts to pass an approval gate with a misleading description.
Benign cases, so you can measure whether defenses make the agent refuse legitimate work.

OWASP names adversarial testing among its mitigations. Run it before go-live, after changes, and on a schedule. Add a red team exercise with people who did not build the agent. Report results as pass rates per case category, and never as one reassuring number.

Supervisory angle: DORA and FINMA

What does DORA expect?

For EU-regulated financial entities, Regulation (EU) 2022/2554 on digital operational resilience sets rules on ICT risk management, incident reporting, operational resilience testing and ICT third-party risk. An AI agent is part of the ICT estate. If it supports a critical or important function, it belongs in your ICT risk framework and in your testing programme, with the same evidence expectations as other systems.

The regulation does not name prompt injection. Our reading is that an injection test is the AI counterpart of input validation testing, and that it belongs in the programme. Agree the scope with your own compliance and legal teams against the regulation and the technical standards.

What does FINMA expect from Swiss institutions?

FINMA’s Guidance 08/2024 on AI governance and risk management states that Switzerland has no AI-specific legislation and that the technology-neutral, principle-based governance and risk management requirements of financial market law cover the risks of using AI. FINMA expects supervised institutions to align their governance, risk management and control systems accordingly. For an agent this means named accountability, documented risk assessment, independent review, and monitoring that continues after launch. Blast-radius documentation per agent, covering reach, approvals, logging and evaluation results, maps directly onto those expectations. Check the guidance text on FINMA’s own site when you write your control framework.

If your agent also falls under the EU AI Act, for example because you serve EU clients, the high-risk classification and its documentation duties are a separate assessment. Do it explicitly rather than assuming the DORA or FINMA work covers it.

Our perspective

A sound design starts by drawing the agent’s boundary before choosing a model. The usual order in a pilot is reversed: the team shows a capable demo, then asks security how to make it safe. That is the expensive path, because the permissions and tool design are already baked in.

Our view is simple. Model quality matters, and a stronger model is a better starting point. But the control that stays valid when the model errs is the one around it: narrow credentials, deterministic execution of risky actions, human approval where consequences are real, logs that capture every decision, and tests that run on every change. We would not tell a bank that a classifier or a good system prompt is enough, and we would not tell it that any model is immune.

Approvals should also be boring. A well-designed approval queue has few items, each showing the actual action. That is more protective than a long queue of screens people click through.

— Igor Izraylevych

Building this into a pilot-to-production plan

Treat the controls as acceptance criteria, not as a hardening phase after launch. A workable sequence:

Scope the agent’s task and list every system, data source and tool it touches.
Write the worst-case sentence for a fully hijacked agent, and reduce scope until it is acceptable.
Classify actions into the three classes above and assign approvers.
Build the logging before the features, and decide who reviews it.
Build the evaluation suite alongside the first prototype and keep it in the release pipeline.
Document reach, approvals, logs and test results for risk, audit and supervisors.

For the wider security context, our article on cyber security standards in banking covers the institution-level controls that agent controls sit on top of. For compliance-specific agents, see how we approach AI agents for AML and transaction monitoring.

How S-PRO helps

S-PRO is a Zurich-based software development company for banks, wealth managers, asset managers and fintechs. We design AI agents for banks and financial services with audit trails, human-in-the-loop controls and documentation for the EU AI Act, FINMA and DORA, and we take them from pilot to production. S-PRO is a Certified partner in the Claude Partner Network, and our team includes Claude-certified engineers and architects. We are ISO 27001 and ISO 27701 certified, founded in 2014, with 250+ engineers.

If you have an agent in pilot, we can review its reach, approval points, logging and evaluation set with your security and compliance teams. Start with our AI agent development service, or read more on security and compliance for financial institutions.

FAQ

Can a system prompt stop prompt injection?

No. A system prompt states intent, but it is not an enforcement boundary, and the OWASP cheat sheet says prompt wording should not be treated as one. Use it as one layer next to least privilege, deterministic execution of risky actions and human approval.

Does a stronger model remove the need for these controls?

No. Anthropic reports about 1% attack success against an internal adaptive attacker in a browser-agent test and states that no browser agent is immune. A lower rate is useful, but you still need to limit what a successful attack can do.

Should every agent action need human approval?

No. Approval on everything creates fatigue and teaches reviewers to click through. Reserve it for high-risk or irreversible actions such as payments, changes to account data and external data transfers, and let read-only and staged actions run with logging.

How often should we test an agent?

Before go-live, after every change to the model, prompts, tools or data sources, and on a recurring schedule. Outputs vary between runs, so repeat each case several times instead of relying on a single pass.