Securing Banking AI Agents Against Indirect Prompt Injection

Indirect Prompt Injection via Bank Transfers

A single bank transfer of as little as ‘’0.02 can compromise a banking AI assistant by turning it into a delivery channel for highly credible spearphishing attacks. This vulnerability, identified by Blue41 during testing for the digital bank Bunq, occurs when an AI assistant retrieves untrusted transaction data and passes it to a Large Language Model (LLM) as context, allowing the model to interpret malicious instructions hidden in a transaction description as legitimate commands.

The Attack Mechanism: From Data to Instruction

Indirect prompt injection occurs when malicious instructions are not provided by the user but are embedded in external data that the AI assistant later processes. In the case of the Bunq AI assistant, the attack follows a specific sequence:

1. Injection: An attacker sends a small bank transfer (e.g., ‘’0.02) to the target. The transaction description field is used to house a carefully crafted prompt injection payload.
2. Retrieval: The victim asks the AI assistant a routine question, such as ‘‘Show me my recent transactions’’. The assistant fetches the transaction records, including the attacker’s transfer, and feeds them into the LLM context window.
3. Execution: The LLM processes the injected instructions within the transaction description. In the demonstrated proof of concept, the assistant was manipulated into launching a spearphishing attack, presenting the user with a fake reauthentication request that appeared to come from the bank itself.

Because the message is delivered through the bank’s own application and can reference real account details, the phishing attempt is significantly more credible than traditional email-based phishing.

Why Financial AI Assistants are High-Risk

Financial institutions are particularly susceptible to this class of attack due to several structural factors:

• Common Injection Surfaces: Fields such as payment references, merchant metadata, and support messages are frequently retrieved by AI assistants but were never designed as trusted instruction boundaries.
• Low-Cost Delivery: A tiny transfer allows an attacker to place controlled text directly into a victim’s transaction history.
• Privileged Context: Unlike external phishing, AI assistants have access to real account data, making manipulated responses more personalized and believable.
• Expanding Capability: As assistants move from read-only summaries to executing tools and workflows, the potential impact of a successful injection increases.

The Failure of Static Guardrails

Standard security measures, such as input filters and prompt injection classifiers, are often insufficient because malicious intent is frequently invisible when the payload is viewed in isolation.

Blue41 noted that Bunq’s AI application had guardrails in place, yet the vulnerability persisted. The payload did not rely on classic jailbreak patterns like ‘‘ignore previous instructions’’; instead, it was crafted to blend into transaction data, only becoming dangerous once the LLM integrated it into the broader application context.

Mitigation Strategies for AI Agents

Effective defense requires a layered security model rather than a single control. Recommended mitigations include:

1. Context Minimization

Do not pass data fields to the LLM unless they are strictly necessary for the user’s current task. If a transaction description is not required to answer a query, it should be excluded from the model context.

2. Explicit Data-Instruction Separation

Architecture should treat retrieved data (transaction descriptions, emails, API responses) as untrusted data, not as instructions. This involves maintaining a strict boundary between the user's intent and the retrieved context.

3. Output Constraints

Assistants should be restricted from freely generating external links, requesting credentials, or initiating sensitive workflows without secondary, independent verification.

4. Behavioral Runtime Monitoring

Since preventing every possible payload is unrealistic, security teams should monitor for anomalous behavior. This includes tracking if an assistant suddenly begins embedding external URLs, suppressing standard information, or calling APIs in patterns that deviate from its established behavioral profile.

Technical Perspectives and Critiques

Industry discussion surrounding this vulnerability highlights a fundamental tension in LLM architecture. Some critics argue that the inability of LLMs to inherently separate data from instructions makes them fundamentally insecure for financial applications.

"I feel like as long as this is case, we'll never have secure LLMs... how do you plan on separating data from instructions?"

Other technical observers compared the issue to the early days of the web, noting that prompt injection is essentially a modern version of the SQL injection or Cross-Site Scripting (XSS) vulnerabilities that occurred before developers began sanitizing all human-provided input.

Some skeptics questioned the practicality of the attack, noting that a user must proactively ask the AI about a specific transaction and then click a link, which may be seen as a high friction path for a mass-scale attack. However, the core vulnerability remains a failure of the trust boundary between external data and model instructions.