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