TL;DR

当今大多数LLM安全测试依赖于静态提示检查，这忽略了对话上下文和对抗性操纵带来的更深层风险。本文重点讨论真正的渗透测试需要采用场景驱动方法，考虑这些模型如何解读人类意图，以及传统安全措施为何经常失效。

如果你正在探索如何保护大型语言模型，不要错过我们的网络研讨会：Breaking AI: Inside the Art of LLM Pen Testing。它将更深入地探讨本博客涵盖的技术、思维模式和实际经验。

引言

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

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

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

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

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

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

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

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

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

以下是我们团队的建议：

尽可能在沙箱环境中运行AI模块 将LLM与核心系统和敏感数据隔离，以控制任何意外或对抗性输出。默认将这些模型视为不可信，并在严格边界后部署，限制对更广泛环境的访问。

将模型与任何敏感内容分开 不要让LLM直接触发敏感操作，如数据库查询、文件访问或配置操作。相反，通过具有明确验证、批准步骤或人工审核的中间逻辑路由这些请求。

实时监控异常行为或违规迹象 设置专门针对LLM行为调整的日志记录和监控：意外完成、策略违规或语气/输出模式的突然变化。使用这些信号在潜在滥用或提示注入尝试升级之前检测它们。

手动审查任何触发提升访问或决策的内容 任何影响用户、权限或关键工作流的AI生成操作都应经过人工批准。这并不意味着审查每个响应，但确实意味着在允许模型以更高信任度操作的任何地方插入摩擦。

构建深度防御 结合分层控制、主动防护栏，甚至使用辅助AI系统在允许操作之前审查或验证主要模型的输出。

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

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

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

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

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

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

如果你负责交付或保护AI系统，请记住以下几点：

我们正在积极测试和学习。如果你也在类似的道路上，我们很乐意交流经验。

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