A tiny bank transfer could compromise a banking AI agent

Blue41 published a case study on helping the European digital bank Bunq strengthen the security of its financial AI assistant. The core issue described in the article is “indirect prompt injection”: attackers do not enter malicious instructions directly into the AI assistant, but instead hide instructions in external data. When the AI assistant later retrieves that data to answer a user’s question, the model may misinterpret the data as instructions it should execute. The attack method in the case is very low-cost: the attacker only needs to transfer a tiny amount of money into the target account. In Blue41’s test, the amount was 0.02 euros, with a specially crafted payload placed in the transaction description field. When the victim opens the banking app and asks the AI assistant for an overview of recent transactions, the assistant retrieves transaction data that includes the transfer and sends it into the LLM context, after which it may be induced to generate a re-verification or phishing message that appears to come from the bank’s official AI assistant. This type of attack is more dangerous than ordinary phishing emails because the message appears inside the bank’s own app and can reference real transactions and user context, making it more credible. The article notes that the issue is not limited to Bunq, nor is it merely a flaw in the model itself, but rather a trust-boundary problem in the architecture of financial AI assistants. Fields such as transaction descriptions, payment notes, merchant metadata, customer service messages, documents, emails, and CRM records were originally just data, but once they are sent into the model context, they can become an attack surface. Blue41 argues that input filtering, prompt-injection classifiers, or content moderation alone are not sufficient defenses, because a carefully designed payload may look like ordinary transaction data when viewed in isolation, and only become dangerous when combined with a specific retrieval flow, application context, and the model’s output capabilities. Recommended mitigations include reducing unnecessary context input, explicitly treating external data as untrusted data rather than instructions, limiting the AI assistant’s ability to generate external links or initiate sensitive processes, applying least privilege, and monitoring the assistant’s runtime behavior, such as whether it suddenly embeds unusual URLs, accesses unexpected data sources, hides normal information, or calls unusual tools. Overall, the article frames financial AI assistant security as a matter of application security, data-flow design, and runtime monitoring, not merely adding a few layers of guardrails.