TL;DR

当前大多数LLM安全测试依赖于静态提示检查，但这会错过对话上下文和对抗性操纵带来的更深层风险。本文重点讨论真正的渗透测试需要采用场景驱动的方法，考虑这些模型如何解释人类意图，以及为什么传统防护措施往往不足。

如果您正在探索如何保护大语言模型(LLM)，请不要错过我们的网络研讨会：《破解AI：LLM渗透测试的内幕》。该研讨会将更深入地探讨本文涵盖的技术、思维模式和实际经验。

正文

随着越来越多的组织将LLM集成到其产品和系统中，安全团队面临一个棘手的问题：如何以有意义的方式测试这些系统？

在Bishop Fox，我们的顾问一直在深入研究这一领域。我们一直在测试实际部署，从失败中学习并调整我们的方法。最近，我们召集团队讨论了哪些方法有效，哪些无效，以及安全测试需要如何发展。本文分享了该讨论的一些见解。

很多团队从提示工程开始。他们尝试通过在开发过程中硬编码提示或添加令牌过滤器来测试LLM。这对于捕捉明显问题很有帮助，但并不能真正告诉您系统是否安全。

然而，LLM与传统软件不同。它们基于上下文而非仅仅是代码进行响应。它们是在人类对话上训练的，这意味着它们继承了随之而来的所有不可预测性。语气或措辞的微小变化可能导致完全不同的输出。

要正确测试它们，您需要像攻击者一样思考。您需要理解人们如何扭曲语言、改变意图，并利用上下文绕过规则。

例如，我们的一位顾问遇到了一个安全策略：“儿童不应玩火”。他要求模型为成年人重写该规则，逻辑是成年人不应有相同的限制。模型翻转了含义并建议：“你应该玩火”。一个小的变化，但明显是失败的。

这类攻击之所以有效，是因为LLM试图提供帮助。它们不仅仅是遵循规则；它们解释意图。这就是真正的风险所在。

我们必须将LLM视为对话系统，而不是命令行工具。因此，测试必须专注于模拟真实用户或攻击者可能尝试滥用模型的现实场景。

过滤输出或添加速率限制是不够的。如果您想围绕LLM构建安全系统，您需要将其视为任何其他高风险组件。

以下是我们团队的建议：

尽可能在沙盒环境中运行AI模块：将您的LLM与核心系统和敏感数据隔离，以控制任何意外或对抗性输出。默认将这些模型视为不受信任，并在严格边界后部署它们，限制对更广泛环境的访问。
将模型与任何敏感内容（如数据访问或特权操作）分开：不要让LLM直接触发敏感操作，如数据库查询、文件访问或配置操作。相反，通过具有明确验证、批准步骤或人工审查的中间逻辑路由这些请求。
实时监控异常行为或违反规则的迹象：设置专门针对LLM行为调整的日志记录和监控：意外完成、策略违规或语气或输出模式的突然变化。使用这些信号在潜在滥用或提示注入尝试升级之前检测它们。
手动审查任何触发提升访问或决策的内容：任何影响用户、权限或关键工作流的AI生成操作都应经过人工批准。这并不意味着审查每个响应——但确实意味着在允许模型以更高信任度操作的任何地方插入摩擦。
构建深度防御：结合分层控制、主动防护栏，甚至使用次要AI系统在允许操作之前审查或验证主要模型的输出。

这是我们安全其他地方使用的相同分层方法，只是应用于生成系统。

这是一个挑战：有些攻击不会以相同的方式发生两次。

这不一定是测试的失败。这是这些模型工作方式的副产品。相同的输入可能产生不同的结果，取决于时间、先前的消息，甚至措辞的微小变化。

当这种情况发生时，我们记录一切。我们提供完整的记录、周围上下文以及我们如何避免类似问题的建议。我们专注于为什么它有效——不仅仅是发生了什么。

这个领域变化很快。今天有效的方法可能下周就无效了。但以下是我们目前看到成功的方法：

这不是关于完美。而是关于灵活、意识和对实际影响的关注。

如果您负责交付或保护AI系统，以下是一些需要记住的事项：

我们正在积极测试和学习。如果您走在类似的道路上，我们很乐意交流意见。

有故事要分享吗？遇到了奇怪的边缘情况吗？我们很乐意将您与我们团队中深入从事这项工作的人联系起来。