0.01 欧元转账即可攻破银行 AI 代理：Bunq 安全案例深度解读

背景

随着现代银行应用程序日益集成 AI 驱动的功能，金融机构面临着新的安全挑战。这些 AI 助手通常位于用户与后端数据源（如交易记录、产品文档、账户详情、支持内容等内部系统）之间，利用大语言模型（LLM）基于上下文回答用户的自然语言问题。

Blue41 是一家安全公司，近期在 RSAC Launch Pad 中获胜。他们通过一个案例研究，展示了如何帮助欧洲第二大数字银行 Bunq（拥有超过 2000 万客户）保护其金融 AI 助手免受“鱼叉式网络钓鱼”（spearphishing）风险的侵害。在测试过程中，Blue41 发现了一种间接提示注入（indirect prompt injection）漏洞：攻击者仅需发送一笔极小额的银行转账，即可将 AI 助手转化为极具可信度的钓鱼攻击投递渠道。

这一案例表明，该问题并非某一家银行独有，而是金融机构在部署处理交易数据、客户记录、文档、消息或其他不受信任输入的 AI 助手时，所面临的更广泛的架构性挑战。

核心内容

间接提示注入的原理与风险

现代银行 AI 助手在回答用户查询（如“给我最近交易的概览”）时，会检索相关记录并将其作为上下文传递给 LLM，由模型生成对话式摘要。然而，安全挑战在于：并非所有检索到的上下文都应被视为同等可信。

交易描述是由第三方设置的数据。虽然它看起来像普通文本，但当它被放入 LLM 的上下文窗口时，模型可能会将其解释为“指令”而非“数据”。这就是间接提示注入的核心问题：恶意指令并非由与助手交互的用户直接输入，而是隐藏在助手后续处理的外部或检索数据中。对于开发人员和团队而言，评估间接拉入 AI 模型的每部分数据的风险级别非常复杂。

攻击演示：仅需 0.02 欧元

该概念验证（PoC）无需访问受害者设备、无需恶意软件，也无需传统的社会工程学手段。攻击者只需执行一步操作：发送一笔小额银行转账。

1. 步骤一：攻击者向目标发送一笔小额转账（在本例中为 0.02 欧元）。在交易描述字段中，攻击者包含了一个精心设计的提示注入载荷（payload）。这是攻击者唯一需要采取的行动。
2. 步骤二：受害者打开银行应用程序，向 AI 助手提出一个常规问题，例如“显示我最近的交易”。攻击的其余部分由 AI 助手自动且自主地执行。

为了回答该问题，AI 助手检索交易数据（包括攻击者的转账），并将其作为回答用户所需上下文的一部分传递给 LLM。LLM 随后处理交易描述中注入的指令。在受控演示中，助手被操纵，向银行用户发起鱼叉式网络钓鱼攻击，伪装成来自银行的合法重新身份验证请求。

为何此类攻击极具威胁性

生成的消息出现在银行自己的应用程序中，由银行自己的 AI 助手发出。它可以引用真实的交易细节和用户特定信息，使其成为极具可信度的钓鱼攻击。这种信任边界失效可能导致多种攻击场景，具体取决于 AI 代理的功能。

此类攻击在银行和金融服务领域特别相关，主要基于以下特性：

• 注入面普遍存在：交易描述、付款参考、商户元数据、支持消息、上传的文档、电子邮件和 CRM 笔记都是可能被 AI 助手检索的数据字段示例。许多这些字段从未被设计为受信任的指令边界。
• 投递机制廉价且可信：一笔微小的转账即可将攻击者控制的文本放入受害者的交易历史中。随后，载荷通过高度可信的渠道（银行自己的应用程序）投递。
• 助手拥有特权上下文：与网络钓鱼电子邮件不同，银行 AI 助手可以访问真实的账户上下文。这使得操纵后的回复更具个性化、更及时、更令人信服。
• 风险随功能增长：只读助手仍可能误导用户。而能够访问工具、工作流或账户操作的助手则引入了更大的风险面。助手越有用，其安全模型的重要性就越高。

静态过滤的局限性

自然的反应是添加输入过滤器、提示注入分类器或内容审核规则。这些控制措施有帮助，但单独使用并不足够。

Bunq 的 AI 应用程序已设有护栏（guardrails），但问题依然存在，因为恶意意图从孤立的事务描述中并不明显。载荷不需要包含“忽略之前的指令”或其他经典的越狱模式。它被设计为融入交易数据，只有当助手检索它、将其放入上下文并从中生成响应时，它才变得危险。

这揭示了仅依赖静态文本分类的局限性。风险不仅在于文本本身，更在于不受信任的数据、检索逻辑、模型行为、应用程序上下文以及助手的可用输出或动作之间的相互作用。

解决方案：分层安全模型

结论是：仅靠护栏是不够的，需要成为分层安全模型的一部分。输入过滤有助于减少明显的攻击。输出约束可以防止某些有害响应或数据泄露。最小权限访问限制影响范围。运行时监控有助于检测助手是否在其预期的操作配置文件之外行为。

没有单一的控制措施可以解决间接提示注入。实际目标是减少暴露、限制危险行为，并在保护失效时检测妥协。

Blue41 讨论的补救选项包括：减少对不受信任的事务字段的非必要暴露、明确分离数据与指令、限制出站链接，并监控助手行为以发现异常输出。随后，他们共同验证了实施的缓解措施有效解决了该漏洞。

关键要点

• 数据即指令的风险：当第三方数据（如交易描述）被放入 LLM 上下文时，模型可能将其误读为指令，而非单纯的数据。
• 攻击门槛极低：攻击者无需恶意软件或设备访问权限，仅需发送一笔包含恶意载荷的小额转账即可触发攻击。
• 高可信度钓鱼：攻击消息源自银行官方应用及 AI 助手，引用真实交易细节，极大增加了受害者的信任度和点击率。
• 静态防御失效：传统的输入过滤器和静态文本分类无法识别隐藏在上下文交互中的恶意意图，因为载荷本身看起来像普通数据。
• 分层防御必要性：单一控制措施无效，必须采用包含输入过滤、输出约束、最小权限访问和运行时行为监控的多层安全模型。

意义与影响

对金融机构的启示

金融机构在部署 AI 助手时，应考虑以下四个控制层：

1. 最小化不必要的上下文：除非用户任务需要，否则不要将字段传递给助手。如果交易描述不是回答问题所必需的，默认情况下不应进入模型上下文。
2. 将检索数据视为不受信任：交易描述、客户消息、文档、电子邮件和 API 响应应作为数据处理，而非指令。助手架构应明确保留这种区别。
3. 限制敏感输出和操作：助手不应自由生成链接、请求凭据、启动敏感工作流或调用高影响力工具，除非有额外的控制措施。
4. 监控运行时行为：即使有良好的预防性控制，新型攻击仍会出现。安全团队需要可见性，了解助手检索了什么、生成了什么、使用了哪些工具，以及这些行为是否与应用程序的预期配置文件匹配。

行业影响

防止每一种可能的注入载荷是不现实的。攻击者可以调整措辞、隐藏意图，并利用通用分类器无法理解的应用程序特定上下文。

然而，当 AI 助手被攻破时，其行为通常会以可观察的方式发生变化。它可能会开始嵌入外部 URL、抑制通常显示的信息、遵循不寻常的响应模式、访问意外的数据源，或以不符合正常用法的方式调用工具。

Blue41 的方法正是基于此：监控 AI 代理的运行时行为并建立行为配置文件。这标志着 AI 安全从单纯的“输入/输出过滤”向“行为异常检测”的转变，对于构建真正安全的金融 AI 系统至关重要。