0.01 欧元转账就能攻破银行 AI 助手 — Bunq 金融 AI 安全深度解析

原文来源：Blue41 — How we helped Bunq secure their financial AI assistant — 安全公司 Blue41 揭示了银行 AI 助手面临的新型间接提示注入攻击：通过交易描述字段注入恶意指令，整个攻击仅需 0.01 欧元转账。

2026 年 4 月，安全公司 Blue41 公开了一个令人后背发凉的案例：仅通过向目标账户转账 0.01 欧元，攻击者就能利用银行内置 AI 助手发动高度定制化的钓鱼攻击。

这不是传统意义上的黑客攻击——不需要恶意软件、不需要破解设备、甚至不需要传统的社交工程。攻击者唯一需要做的，就是填写一条交易备注。

攻击手法：藏在交易描述里的恶意指令

Bunq 是欧洲第二大的数字银行，拥有超过 2000 万客户。和许多现代银行一样，Bunq 在应用中集成了 AI 助手，帮助用户查询交易记录、管理账户。而这个助手正是整个攻击链的突破口。

攻击流程出奇地简单：

第一步：攻击者向目标账户转账 0.01 欧元，在交易描述字段中嵌入精心构造的提示注入（Prompt Injection）载荷。这是攻击者唯一需要主动执行的步骤。

第二步：受害者打开银行应用，向 AI 助手发起一个日常查询，比如"显示我最近的交易记录"。

第三步：AI 助手从后台获取交易数据，其中包括攻击者转入的那笔带有恶意指令的交易记录。这些数据被传入大语言模型作为上下文。

第四步：LLM 将交易描述中的恶意指令解读为有效指令，在响应中生成一条看起来像银行官方重新认证通知的钓鱼信息——包含链接、提及真实交易详情，可信度极高。

整个攻击完全自动化，受害者毫无察觉。

为什么这对金融行业尤为重要

Blue41 指出，这个漏洞并非 Bunq 独有，而是 AI 助手在金融行业落地时面临的结构性架构挑战。

几个关键风险点：

注入面无处不在。交易描述、付款备注、商户元数据、客服消息、上传的文档、邮件、CRM 备注——所有这些数据字段都可能最终被 AI 助手检索并纳入上下文。而这些字段在设计之初，从未被视为需要严格区分的"指令边界"。

传递机制廉价且可信。一笔微型转账就能将攻击者控制的文本植入受害者的交易记录。而攻击载荷是通过银行自有应用呈现的——这是用户高度信任的渠道。

助手拥有特权上下文。与钓鱼邮件不同，银行 AI 助手可以获取真实的账户信息。这意味着被操纵的响应可以更加个性化、更具时效性、更令人信服。

风险随着能力增长而扩大。只读的 AI 助手已经可能误导用户。如果助手具备工具调用、工作流执行、账户操作等能力，攻击面将急剧扩大。

为什么"护栏"不够用

你可能会想：加个输入过滤或提示注入分类器不就行了？

Blue41 的结论是：仅靠护栏远远不够。

Bunq 的 AI 应用实际上已经部署了防护措施，但问题依然存在。原因在于，恶意的交易描述在单独审查时并不起眼——它不需要说"忽略之前的所有指令"这种经典的越狱模式。精心构造的载荷可以巧妙地融入正常交易数据中。

Blue41 用两幅图做了对比：一个简单直接的提示注入很容易被过滤器发现，但一个更老练的载荷在单独审查时，与普通交易数据几乎无法区分。

问题的本质不在于文本本身，而在于不可信数据、检索逻辑、模型行为、应用上下文和助手可用输出之间的相互作用。

有效的缓解方案

Blue41 建议金融 AI 助手采用四层防护：

1. 最小化非必要的上下文 只在需要时才将字段传入模型。如果某个交易描述对回答用户问题不相关，就不应该默认进入模型上下文。

2. 将检索数据视为不可信 交易描述、客户消息、文档、邮件、API 响应——所有这些都应该被当作"数据"而非"指令"来处理。架构上应当明确维护这一区分。

3. 约束敏感输出和操作 AI 助手不应随意生成链接、索要凭据、发起敏感工作流或调用高风险工具。

4. 监控运行时行为 即使防护措施到位，新形式的攻击也一定会出现。安全团队需要看到助手检索了什么、生成了什么、使用了哪些工具、行为是否与预期相符。

行为监控的价值

Blue41 的核心论点：防止每一种可能的注入载荷是不现实的。攻击者可以改写措辞、隐藏意图、利用应用特定的上下文绕过通用分类器。

但当 AI 助手被攻陷时，其行为往往会发生可观察的变化。 它可能开始嵌入外部链接、压制本该显示的信息、遵循异常响应模式、访问不应访问的数据源、或以不符合正常使用模式的方式调用工具。

这正是 Blue41 采用的方案：监控 AI Agent 的运行时行为，构建每个助手正常操作的行为基线——它访问哪些数据源、响应模式是什么、使用哪些工具和 API——并识别偏差。

更大的图景

金融行业的 AI 助手不再是实验性的副项目。它们正在被部署到面向客户和面向员工的工作流中，处理敏感数据并影响真实决策。

传统应用安全假设代码和数据之间有相对清晰的边界。AI 助手模糊了这个边界——它们检索数据、解释数据、对数据推理，并可能最终基于数据采取行动。曾经只是无害文本的交易描述字段，现在可能成为通向潜在攻击的信道。

对于独立开发者来说，这个故事同样值得警醒：如果你的应用涉及 LLM 处理用户或第三方提供的不可信数据（评论、消息、文件内容等），你就需要认真思考信任边界问题。 这不是大公司才需要担心的事情——一个简单的评论区功能，如果被 AI 索引并在上下文中呈现，同样可能成为注入点。

不过，这个案例也并非全然的警示故事。Blue41 帮助 Bunq 识别并修复了漏洞，Bunq 积极响应的态度值得肯定。AI 的安全问题需要开发者和安全团队共同面对，而不是回避 AI 落地的浪潮。