€0.01 转账破坏银行 AI Agent

Blue41 帮助一家领先的欧洲银行保护其 AI 助手免受鱼叉式网络钓鱼风险。在我们的测试过程中，我们发现了一个间接 prompt injection 漏洞，其中一笔银行转账就可以将助手变成投递高度可信网络钓鱼攻击的渠道。

我们分享这个案例，是因为根本问题并非某家银行独有。它是一个更广泛的架构挑战，涉及部署处理交易数据、客户记录、文档、消息或其他不可信输入的 AI 助手的金融机构。

现代银行应用越来越多地包含 AI 驱动的功能。这些功能位于用户和一系列后端数据源之间，如交易记录、产品文档、账户详情、支持内容和其他内部系统。它们使用大语言模型基于这些背景信息回答自然语言问题。

当用户问"给我一个最近交易的概览"时，助手会获取相关记录并将其作为背景信息传递给 LLM。模型随后以对话式的响应对数据进行总结。

安全挑战在于并非所有检索到的背景信息都应该被同等信任。交易描述是由第三方设置的数据。它看起来像普通文本，但当它被放入 LLM 的上下文窗口时，模型可能会将其解释为指令而非数据。

这是间接 prompt injection 背后的核心问题：恶意指令不是由与助手交互的用户输入的。它们隐藏在助手随后处理的外部数据或检索数据中。对于开发者和安全团队来说，评估每条间接拉入 AI 模型的数据的风险等级很复杂。

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

第 1 步。攻击者转账一笔小额，在我们的案例中是 €0.02，给目标用户。在交易描述字段中，他们包含一个精心设计的 prompt injection 有效载荷。这是攻击者需要采取的唯一行动。

第 2 步。受害者打开银行应用，向 AI 助手提出例行问题，比如"显示我最近的交易"。攻击的其余部分由 AI 助手自动且自主地执行。

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

生成的消息出现在银行自己的应用内，来自银行自己的 AI 助手。它可以引用真实的交易详情和用户特定信息，使其成为一次高度可信的网络钓鱼攻击。

同样的信任边界失败可能导致多种攻击场景，具体取决于 AI agent 的能力。

为什么这对金融机构很重要

有几个特性使得这类攻击对银行和金融服务特别相关。

注入表面很常见。交易描述、支付参考、商户元数据、支持消息、上传的文档、电子邮件和 CRM 备注都是可能最终被 AI 助手检索的数据字段示例。这些字段中有许多从未被设计为可信的指令边界。

投递机制成本低且可信度高。一笔微小的转账可以将攻击者控制的文本放入受害者的交易历史中。有效载荷随后通过一个高度信任的渠道投递：银行自己的应用。

助手具有特权背景。与网络钓鱼电子邮件不同，银行 AI 助手可以访问真实的账户背景。这使得被操纵的响应更具个人性、更及时、更可信。

风险随着能力而增长。只读助手仍然可能误导用户。具有访问工具、工作流或账户操作权限的助手引入了更大的风险面。助手变得越有用，其安全模型就变得越重要。

更广泛的教训很简单：每个进入 AI 助手上下文的不可信数据源都成为助手攻击表面的一部分。

为什么仅有防护措施还不够

自然的反应是添加输入过滤器、prompt injection 分类器或内容审核规则。这些控制措施可以有所帮助，但单独并不充分。

银行的 AI 应用有防护措施。问题依然存在，因为恶意意图从交易描述的孤立来看并不明显。有效载荷无需说"忽略之前的指令"或其他经典越狱模式。它被精心设计为混入交易数据，只有在助手检索它、将其放入上下文并从中生成响应时才会变得危险。

这是仅依赖静态文本分类的局限。风险不仅在于文本本身。风险来自于不可信数据、检索逻辑、模型行为、应用上下文和助手的可用输出或操作之间的交互。

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

有效缓解的样子

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

在这个案例中，我们讨论了修复选项，如减少对不可信交易字段的不必要暴露、明确分离数据和指令、限制出站链接以及监控助手行为是否存在异常输出。我们随后一起验证了实施的缓解措施有效解决了该漏洞。

更通俗地说，部署 AI 助手的金融机构应该考虑四层控制。

1. 最小化不必要的背景。除非用户任务需要，否则不要将字段传递给助手。如果回答问题不需要交易描述，默认情况下它不应进入模型上下文。

2. 将检索的数据视为不可信。交易描述、客户消息、文档、电子邮件和 API 响应应该被当作数据而非指令处理。助手架构应该明确地保持这种区别。

3. 限制敏感输出和操作。助手不应该在没有额外控制的情况下自由生成链接、请求凭证、启动敏感工作流或调用高影响工具。

4. 监控运行时行为。即使有良好的预防性控制，新型攻击也会出现。安全团队需要了解助手检索了什么、生成了什么、使用了哪些工具，以及该行为是否与应用的预期配置文件相匹配。

为什么行为监控很重要

防止每个可能的注入有效载荷是不现实的。攻击者可以改变措辞、隐藏意图，并利用通用分类器不了解的应用特定背景。

但当一个 AI 助手被妥协时，其行为通常会以可观察的方式改变。它可能开始嵌入外部 URL、抑制它通常会显示的信息、遵循不寻常的响应模式、访问意外的数据源，或以不符合正常使用的方式调用工具。

这是 Blue41 采取的方法。我们监控 AI agent 的运行时行为，并为每个助手建立行为配置文件，了解它如何正常运作：它访问哪些数据源、期望哪些响应模式、它使用哪些工具和 API，以及哪些偏差应该触发调查。

其目标是为安全和 AI 团队提供他们需要的可见性，一旦 AI 助手成为真实业务工作流的一部分。

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

传统应用安全假定代码和数据之间有一个相对清晰的边界。AI 助手模糊了这个边界。它们检索数据、解释数据、对数据进行推理，最终可能对其采取行动。因此，曾经是无害文本的字段可以成为强大应用内的指令通道。

这在银行业尤为重要，助手可能与交易数据、客户记录、合规信息、产品文档、支持票据以及最终的运营工具互动。

金融机构无需停止部署 AI 助手。但他们需要将其视为生产系统，具有新的信任边界、新的故障模式和新的监控需求。

这个案例表明，一笔微小、普通的银行转账如何能暴露 AI 助手架构中更大的问题。问题不在转账本身。问题在于不可信数据可以进入助手的上下文，并影响助手说什么或做什么。

更广泛的教训与部署 AI 助手的任何金融机构相关：prompt injection 不仅是一个模型问题。它是一个应用安全问题、一个数据流问题，以及一个运行时监控问题。

如果你的团队在金融服务中部署或评估 AI 助手，Blue41 可以帮助评估不可信数据在哪里进入 agent 上下文、应该监控哪些行为，以及在扩展到生产前需要哪些控制。

预订简短介绍。我们很乐意了解你的 AI 部署，并探索我们如何能提供帮助。