LLM 红队测试基础

红队测试是一种有纪律的实践，旨在抢在对手之前探查系统的失败点。对于 LLM 来说，这意味着系统性地攻击您的提示、防护栏和工具，以暴露不安全、不正确或违反策略的行为。

这是服务于防御的攻击性测试，目标是获得可复现的发现，而不是一次性的巧妙漏洞利用。

在发起攻击之前，请定义您要保护什么，以及要防范谁：

• 资产：秘密、用户数据、特权工具操作、品牌安全。
• 对手：好奇的用户、诈骗者、自动化滥用者、内部人员。
• 能力：他们能看到系统提示、控制检索到的文档，或串联工具调用吗？

只有相对于威胁模型而言，某项发现才有意义。

请围绕危害类别组织探查，使覆盖范围系统化：

• 安全——有害指令、禁止内容。
• 安保——提示注入、数据窃取、工具滥用。
• 隐私——PII 泄露、训练数据提取。
• 完整性——幻觉、错误信息、偏见。

两种攻击面：

• 直接——用户输入恶意指令。
• 间接——攻击载荷隐藏在模型稍后读取的内容中（网页、PDF、检索到的文档或电子邮件）。

间接注入更加危险，因为受害者从未输入攻击内容；攻击会通过系统信任的数据传入。

请先从手动探查开始，以建立直觉：选择一个危害类别，设计一个探测，观察响应，并记录结果以及所使用的技术。一次只改变一个因素，这样才能将成功归因于特定策略。

当模型产生被禁止的行为时，攻击便成功了。您需要一个客观的判定器来大规模判断这一点：可以是确定性检查（是否出现了秘密模式？），也可以是用于细微策略判断的 LLM 评审器。没有清晰的判定器，结果就只是轶闻。

请固定所有会影响结果的因素：模型版本、系统提示、温度、可用时的种子以及工具定义。无法复现的发现无法修复，也无法进行回归测试。请保存每次探查的完整请求和响应。

请只对您自己的系统或获授权测试的系统进行红队测试。避免生成真正危险的产物；探测的目的应是测试防护栏是否触发，而不是造成真实伤害。请按照策略处理任何提取出的敏感数据，并负责任地披露发现。

并非每项发现都需要紧急处理。请根据影响（暴露了什么）和可能性（触发有多容易）为每项发现评分。一次提示就能窃取用户 PII 属于严重问题；而一个刻意构造的十步漏洞利用，即使泄露了无害标签，也属于低风险问题。分流决定修复顺序。

一次红队测试很快就会过时：提示会变化，模型会更新，新的攻击会出现。请将每项已确认的发现转化为永久测试用例，使其不会在无声无息中回归。红队测试应成为持续流程，而不是年度活动。

模型只是其中一个组件。请攻击完整路径：检索（被投毒的文档）、工具（不安全的参数）、记忆（持久化的注入）以及编排（多智能体交接）。许多真实漏洞存在于连接层，而不是模型本身。

红队测试基础：

• 从威胁模型开始：资产、对手、能力。
• 覆盖危害类别：安全、安保、隐私、完整性。
• 区分直接注入与间接注入。
• 定义客观的成功判定器，并固定所有因素以确保可复现性。
• 按严重程度分流；将发现转化为永久测试；攻击整个系统。

下一步：具体的越狱技术。