银行业 AI 中的间接提示注入：Bunq 案例研究

间接提示注入允许攻击者将受信任的银行界面武器化

当大语言模型 (LLM) 将不受信任的数据（例如交易描述）解释为一组指令而非被动信息时，就会发生间接提示注入。在对欧洲第二大数字银行 Bunq 进行的安全评估中，Blue41 展示了恶意行为者可以通过在交易参考字段中包含精心设计的有效载荷，发送一笔极小的银行转账（例如 €0.02）。当受害者要求银行的 AI 助手总结近期交易时，助手会检索该有效载荷并执行它，从而可能直接在银行自己的应用程序内发起极具可信度的鱼叉式网络钓鱼攻击。

攻击机制

该攻击绕过了传统的安全边界，因为它不需要恶意软件、设备访问权限，也不需要初始的社会工程学手段。它利用了数据检索与模型执行之间的信任边界失效。

攻击工作流

有效载荷交付：攻击者向目标发送一笔小额资金。交易描述中包含一个隐藏的提示注入有效载荷，旨在劫持 LLM 的行为。
用户触发：受害者使用常规查询与银行 AI 助手进行交互，例如“显示我最近的交易”。
上下文检索：AI 助手获取交易历史记录，包括攻击者的转账，并将此文本输入到 LLM 的上下文窗口中。
执行：LLM 处理注入的指令。在 Bunq 的演示中，助手被操纵去呈现一个虚假的重新身份验证请求，看起来像是来自银行的正规通知。

由于响应源自官方银行应用，并且可以引用真实的账户详情，因此这种网络钓鱼尝试比标准的电子邮件或短信更具可信度。

为什么传统的防护栏会失效

标准的输入过滤器和提示注入分类器对于间接注入通常是不够的，因为恶意意图在孤立的数据字段中并不明显。

虽然“越狱”尝试可能会使用诸如“忽略所有之前的指令”之类的明显短语，但复杂的间接注入被设计为融入预期的数据格式中。危险性仅在数据与助手的特定系统提示词和用户的查询相结合时才会显现。因此，静态文本分类无法可靠地地区分合法的交易备注与休眠的指令有效载荷。

缓解 AI 智能体风险的策略

保护金融服务中的 AI 助手需要一种分层的深度防御方法，而非单一的过滤器。Blue41 建议了四个主要的控制层：

1. 上下文最小化

避免将不必要的数据字段传递给 LLM。如果交易描述对于回答特定的用户查询不是必需的，那么在它到达模型之前就应该将其从上下文中剥离。

2. 显式的数据与指令分离

架构必须将检索到的数据视为不受信任的。这涉及使用技术来清晰地划分数据与指令，确保模型理解检索到的内容应当被总结或报告，而不是被执行。

3. 输出与操作约束

应限制 AI 助手执行高影响的操作——例如生成外部链接、请求凭据或发起工作流——而不经过独立的、非 AI 验证步骤或严格的目的地允许列表。

4. 运行时行为监控

由于防止所有可能的有效载荷是不现实的，安全团队应当监控异常行为。失陷指标包括：

突然生成外部 URL。
抑制响应中通常会出现的信息。
工具或 API 调用中的异常模式。
偏离助手已建立的行为特征。

社区观点与技术批判

该漏洞的披露在技术观察者中引发了关于在关键金融基础设施中使用 AI 的必要性和安全性的重大辩论。

架构层面的担忧

一些批评者认为，使用 LLM 来显示确定性数据（例如交易列表）本身就是一种架构缺陷。正如一位观察者所指出的，显示数据库查询结果不应涉及 LLM，因为这对于一个不需要概率性推理的任务来说引入了不必要的风险。

与经典漏洞的对比

行业评论员已将间接提示注入与 SQL 注入的回归进行了对比。正如 SQL 注入发生在用户输入被视为代码时，提示注入发生在检索到的数据被视为指令时。

实用性与风险评估

一些怀疑论者质疑其实际影响，指出用户必须从陌生人那里收到钱并主动询问 AI 关于那笔特定交易，攻击才能生效。然而，反方观点认为，银行应用界面的高度信任感使得此类网络钓鱼的成功转化率可能远高于传统方法。

"我感觉只要这种情况存在，我们就永远无法拥有安全的 LLM... 你打算如何将数据与指令分离？"

这个根本性的问题突显了生成式 AI 应用中“数据 vs. 代码”边界持续存在的挑战。