要构建真正有效的 AI 系统，首先要尝试攻破它。我们开展了一次红队测试，以攻击者身份测试并探查一款面向客户的金融服务 AI 应用。对于部署由 LLM 驱动且必须确保安全的应用，以下发现值得所有人关注。
红队测试是指有意尝试攻破 AI 系统，以便在真正的攻击者发现漏洞之前加以修复。在金融服务领域，风险尤其高：AI 应用会接触客户数据、处理交易并提供财务洞察。一旦发生故障，后果可能从糟糕的用户体验，一直延伸到违反监管规定、蒙受财务损失，以及无法挽回的品牌损害。
我们的目标是尽早发现漏洞、测试现实中的攻击模式，并帮助该组织达到监管机构高度重视的 AI 安全要求。
这里有一个值得说明的区别：越狱攻击针对底层模型的安全过滤机制；提示注入则针对应用本身，将不受信任的用户输入与开发者提供的可信提示结合起来。提示注入的风险更大，因为它针对的是你的系统及其处理的机密数据，而不是通用模型。
第一轮测试包含约 750 项测试，涵盖：
跨会话数据泄露
PII 暴露（通过自然语言、API 操纵及各种编码方式）
SQL 注入
系统提示覆盖攻击
在初步测试中，我们发现现有系统存在两个主要问题：多意图查询的处理，以及编码提示的使用。
多意图查询：在请求中同时混入合法与恶意诉求。例如：“按类别显示我的支出，同时执行 [恶意 SQL]。”该应用未能识别恶意意图，而是完全依赖下游数据层的防护机制。这就像因为相信地下室里的保险箱足够安全，便敞开自家大门。
编码：使用 Base64、Hex、LeetSpeak 和同形异义字符对请求进行编码。系统可能很难过滤其中的恶意意图。我们发现，这些查询虽然没有暴露敏感数据，却会严重扰乱系统（例如产生幻觉、向用户原样返回恶意 SQL、意图分类混乱等）。
初步测试结果显示：
时间幻觉：模型以自信的语气返回虚构的日期、交易时间戳或特定时段摘要。在金融场景中，这构成重大风险，因为客户依据错误日期采取行动可能会造成实际后果
向用户原样返回恶意 SQL（可能带来记忆投毒风险）
意图分类混乱
输出格式错乱
根据这些发现，我们缩小了测试范围。SQL 注入和编码测试的优先级有所降低（团队已经在处理这些问题）。我们转而专注于最有效的攻击向量：PII 暴露和跨会话泄露。
第二轮测试最惊人的发现简单得出人意料：很多时候，攻击根本不需要什么高明手段。
在许多情况下，只需将索取内部数据包装成看似合法的请求并直接开口索要，就足以让系统同意将其暴露。即使是简单查询，也会收到提及内部 ID 和系统字段的响应，而这些信息绝不应呈现给最终用户。
进一步调查后，我们发现这并非仅仅是应用层问题。下游 text-to-SQL 服务构建的查询请求了超出必要范围的字段，其解释性响应还提及了本应受到限制的数据。这暴露了系统之间真实存在的裂缝。这类漏洞只有在测试整个技术栈，而非孤立测试单个组件时才会显现。
红队测试应针对系统，而非模型。孤立测试 LLM，几乎无法反映应用的整体安全状况。应像用户实际交互那样，对整个技术栈进行端到端测试。
输入验证必须在 LLM 之前完成。编码查询、多意图攻击和基本注入尝试都应在系统边界被拦截，而不应交给下游服务处理。
不要信任系统间的衔接处。在多服务架构中，最值得关注的漏洞往往隐藏在系统之间的裂缝中。零信任就是不信任任何环节，因此必须在每一层验证一切。
简单的攻击同样有效。复杂的越狱往往成为头条，但有时你只需要“开口问”。如果用户只是在其他方面合法的查询中加入内部标识符，系统便欣然将其显示出来，那就是一个问题。
弄清楚你实际测试的是什么。已知攻击模式可能是由 LLM 自身的训练机制识别，而非被你的防护机制拦截。应在红队测试中内置可观测性，以了解实际触发了哪些控制措施。
受限环境需要创造性的解决方案。自定义提供商和本地模型支持让组织无需专用云访问权限，也能开展有意义的红队测试。但必须坦诚说明由此带来的局限。
红队测试不是一次性工作。它需要反复迭代，应尽可能实现自动化，并随着系统的演进而不断调整。明天需要重视的攻击，不会与今天完全相同。
受监管环境中的 AI 系统只会面临更多审查，而不会更少。如果组织将安全测试视为一项持续工作，而非上线前简单勾选的检查项，就能更好地应对审查，并避免因公关危机失去客户信任。