一笔0.01欧元的银行转账可能危及银行AI代理

# Blue41 — 在生产环境中控制AI智能体的风险 来源：https://blue41.com/blog/how-we-helped-bunq-secure-their-financial-ai-assistant/ --- Blue41 帮助了 Bunq（https://www.bunq.com/）——欧洲第二大数字银行，拥有超过 2000 万客户——保护其 AI 助手免受鱼叉式网络钓鱼攻击的风险。在我们的测试中，我们发现了一个间接提示注入漏洞：一笔简单的银行转账就能将该助手变成高度可信的钓鱼攻击的传递渠道。 我们分享这个案例，因为根本问题并非某家银行独有。对于部署 AI 助手来处理交易数据、客户记录、文档、消息或其他不可信输入的金融机构来说，这是一个更广泛的架构挑战。 金融助手*从一笔 0.02 欧元的银行转账到银行 AI 助手内的个性化钓鱼场景。*## 背景 现代银行应用越来越多地集成 AI 驱动功能。这些功能位于用户与后台多种数据源之间，后者包括交易记录、产品文档、账户详情、支持内容以及其他内部系统。它们利用大语言模型，根据上下文回答自然语言问题。 金融助手*典型金融 AI 助手的架构：用户通过银行应用交互，而助手从交易数据、文档及其他来源检索上下文，并可能调用外部工具。*当用户问“给我一份近期交易的概览”时，助手会获取相关记录并将其作为上下文传递给 LLM。然后模型以对话形式总结数据。 安全挑战在于，并非所有检索到的上下文都应被同等信任。交易描述是由第三方设定的数据。它可能看起来像普通文本，但当它被放入 LLM 的上下文窗口时，模型可能将其解释为指令而非数据。 这就是间接提示注入的核心问题：恶意指令并非由与助手交互的用户输入，而是隐藏在后来助手处理的外部或检索数据中。对于开发者和安全团队而言，评估每块间接进入 AI 模型的数据的风险级别相当复杂。 ## 攻击场景 这个概念验证不需要访问受害者的设备，不需要恶意软件，也不需要传统的社交工程。攻击者只需要发送一笔小额银行转账。 **第 1 步。** 攻击者向目标转账少量金额，本例中为 0.02 欧元。在交易描述字段中，他们包含精心构造的提示注入载荷。这是攻击者需要采取的唯一行动。 **第 2 步。** 受害者打开银行应用，向 AI 助手提问一个日常问题，例如“显示我最近的交易”。攻击的其余部分由 AI 助手自动且自主执行。 为了回答这个问题，AI 助手检索交易数据，包括攻击者的转账，并将其作为回答用户所需上下文的一部分传递给 LLM。LLM 随后处理交易描述中的注入指令。在我们的受控演示中，助手被操纵向银行用户发起一次鱼叉式网络钓鱼攻击，伪装成银行发出的合法重新认证请求。 提示注入*攻击的解剖：攻击者通过交易描述注入恶意指令（1），用户查询助手（2），交易数据被检索到 LLM 上下文中（3），助手的响应受到注入内容的影响（4）。*结果消息出现在银行自己的应用中，来自银行自己的 AI 助手。它可以引用真实的交易详情和用户特定信息，使其成为高度可信的钓鱼攻击。 相同的信任边界缺陷可能导致多种攻击场景，具体取决于 AI 智能体的能力。 ## 为什么这对金融机构至关重要 以下几条特性使这类攻击对银行和金融服务尤为相关。 **注入面很常见。** 交易描述、支付附言、商户元数据、支持消息、上传文档、电子邮件和 CRM 备注都是可能最终被 AI 助手检索的数据字段示例。其中许多字段在设计时从未被视为可信的指令边界。 **传递机制廉价且可信。** 一笔微小转账就能将攻击者控制的文本放入受害者的交易历史中。然后载荷通过高度可信的渠道——银行自己的应用——进行传递。 **助手拥有特权上下文。** 与钓鱼邮件不同，银行 AI 助手可以访问真实的账户上下文。这使得被操纵的响应更具个性化、及时性和可信度。 **风险随能力增长。** 只读助手仍然可能误导用户。具备工具、工作流或账户操作权限的助手会引入更大的风险面。助手越有用，其安全模型就越重要。 更广泛的教训很简单：每一个进入 AI 助手上下文的不可信数据源，都会成为助手攻击面的一部分。 ## 为什么仅靠护栏是不够的 自然的回应是添加输入过滤器、提示注入分类器或内容审核规则。这些控制手段有所帮助，但本身并不足够。 Bunq 的 AI 应用已设置了护栏。问题之所以持续存在，是因为单看交易描述，恶意意图并不明显。载荷不需要说“忽略之前指令”或使用其他经典越狱模式。它被设计成融入交易数据，只有在助手检索、放入上下文并生成响应后才会变得危险。 金融助手*一个简单的提示注入被高置信度捕获（上图）。而更精心构造的载荷在单独审查时难以与普通交易数据区分开（下图）。*这就是仅依赖静态文本分类的局限性。风险不仅仅存在于文本本身。风险产生于不可信数据、检索逻辑、模型行为、应用上下文以及助手可用输出或动作之间的交互。 结论是：仅靠护栏是不够的，它们需要成为分层安全模型的一部分。输入过滤有助于减少明显攻击。输出约束可以防止某些有害响应或数据泄露。最小权限访问限制影响范围。运行时监控有助于检测助手是否偏离其预期运行模式。 ## 有效的缓解措施是怎样的 没有单一的机制能解决间接提示注入。实际目标是减少暴露、约束危险行为，并在防护失效时检测到入侵。 在这个案例中，我们讨论了补救选项，例如减少对不可信交易字段的不必要暴露、明确区分数据与指令、约束出站链接，以及监控助手行为以发现异常输出。随后我们共同验证已实施的缓解措施有效解决了该漏洞。 更广泛地说，部署 AI 助手的金融机构应考虑四层控制。 **1. 尽量减少不必要的上下文。** 除非用户任务需要，否则不要将字段传递给助手。如果交易描述不需要用来回答问题，就不应默认进入模型上下文。 **2. 将检索到的数据视为不可信。** 交易描述、客户消息、文档、电子邮件和 API 响应应作为数据处理，而非指令。助手架构应明确保持这种区分。 **3. 约束敏感输出和动作。** 在没有额外控制的情况下，助手不应自由生成链接、索要凭据、发起敏感工作流或调用高影响工具。 **4. 监控运行时行为。** 即使有良好的预防控制，新颖的攻击仍会出现。安全团队需要了解助手检索了什么、生成了什么、使用了哪些工具，以及这些行为是否与应用的预期画像相匹配。 ## 为什么行为监控很重要 预防所有可能的注入载荷是不切实际的。攻击者可以调整措辞、隐藏意图，并利用通用分类器无法理解的应用特定上下文。 但当 AI 助手被入侵时，其行为通常会出现可观察的变化。它可能开始嵌入外部 URL、抑制通常会显示的信息、遵循异常响应模式、访问意外的数据源，或以不符合正常使用的方式调用工具。 这就是 Blue41 采取的方法。我们监控 AI 智能体的运行时行为，并为每个助手建立行为画像：它通常访问哪些数据源，预期响应模式是什么，使用哪些工具和 API，以及哪些偏差应触发调查。 目标是为安全和 AI 团队提供所需的可见性，一旦 AI 助手成为真实业务流程的一部分。 ## 更大图景 金融服务中的 AI 助手不再是实验性的副项目。它们正被部署到面向客户和面向员工的工作流中，处理敏感数据并影响真实决策。 传统应用安全假设代码与数据之间有一个相对清晰的边界。AI 助手模糊了这条边界。它们检索数据、解释数据、进行推理，并最终可能对数据采取行动。因此，曾经无害的文本字段可以变成强大应用中的指令通道。 这一点在银行业尤为重要，因为助手可能处理交易数据、客户记录、合规信息、产品文档、支持工单，并最终与运营工具交互。 金融机构无需停止部署 AI 助手。但它们确实需要将这些助手视为拥有新信任边界、新故障模式和新监控需求的生产系统。 ## 结论 这个案例展示了一笔微小普通的银行转账如何暴露 AI 助手架构中一个更大的问题。问题不在于转账本身，而在于不可信数据可以进入助手的上下文并影响助手所说或所做的事。 更广泛的教训适用于任何部署 AI 助手的金融机构：提示注入不仅是模型问题。它是应用安全问题、数据流问题，也是运行时监控问题。 如果你的团队正在金融服务领域部署或评估 AI 助手，Blue41 可以帮助评估不可信数据从何进入智能体上下文、应监控哪些行为，以及在扩展至生产前需要哪些控制。 预约一次简短的介绍（https://blue41.com/meet-with-thomas）。我们很乐意了解你的 AI 部署情况，并探讨我们能从何处提供帮助。