不要只盯着245/250：大模型安全防护与真实攻防之间隔着什么

最近在安全社区里，一则关于 Claude Mythos 5.1 的讨论很吸引眼球：关闭模型内置防护后，在一次针对 Firefox 相关场景的 250 次试验里，模型生成了 245 个看起来可用的漏洞利用样本。很多人看到这个数字，第一反应是“AI 攻击已经自动化了”，也有人觉得“模型自带的安全护栏形同虚设”。作为一个长期接触代码审计和应用安全的人，我的判断不太一样：这类实验真正值得讨论的，并不是“AI 多能打”，而是我们在使用大模型时，必须搞清楚“模型内建防护”和“真实安全工程”之间到底隔了多少层。

这类实验很容易带来误导，因为它把一个需要复杂外部条件才能真正成立的结论，压缩成了一个简单的成功率。安全研究确实需要攻防验证，但把“让模型生成可利用攻击样本”放到标题里，并不能帮助大多数团队把系统变得更安全。真正能抬高安全水位的是另一件事：把 AI 放进“发现问题、理解影响、修复缺陷、验证效果”的闭环里，同时清楚哪些边界不能碰。

1. “245/250”能说明什么，又说明不了什么

1.1 “生成一个样本”不等于“完成一次真实攻击”

在安全领域，“漏洞利用”有很具体的含义：它是一段用于触发并证实某个软件缺陷的输入、脚本或程序。它可以只是一个让程序崩溃的样本，也可以是一条完整的远程代码执行链，二者之间的差距非常大。

大模型在这类测试中输出的东西，往往更像“候选样本”：它看着像漏洞利用，可能能在某个本地靶场或者模拟环境里触发预期效果，但它不等于能在真实部署环境里稳定工作。真实攻击要处理的事项包括目标的具体版本、系统加固配置、网络隔离、账号权限、缓解措施，甚至还有日志告警和应急响应。这些外部条件没有验证之前，一个在实验里可用的样本，距离“能打穿某台真实的 Firefox 终端”还很远。

所以每次看到这种“250 次尝试里成功 245 次”的数字，我第一反应不是“它好强”，而是先问：这里的“成功”是怎么定义的？在什么版本、什么配置、什么模型参数、什么安全设置下得到的？有没有人工介入去修 bug？有没有过滤掉伪阳性？这些问题直接决定这个结论能不能外推。

1.2 关闭模型安全防护之后，我们看见的是“顺从度”，不是真实攻击能力

需要先说明一个前提：对普通用户而言，让模型“关闭安全防护”本身就是一件高风险且通常不被支持的事。正规模型服务商通常会保留安全过滤层，即便模型被要求改变行为，平台侧也还可以继续管控。因此这类实验通常发生在隔离研究环境中，和日常生产场景并不对应。

更重要的是，关闭内置防护后得到的表现，反映的是大模型在“尽量满足用户要求”这个偏好下的倾向，而不是它在正常工作状态下的综合能力。如果把模型比作一个受过安全训练的助手，你摘掉它的安全培训，当然可能更容易从它那里要到你想要的高风险内容。但这就像在实验室里拆掉安全气囊，然后测试司机的反应速度——它确实能说明汽车的某些极限，却不能说明你在正常公路上应该这样驾驶。

普通用户真正该从这种测试里得到的信息是：不要以任何理由尝试关闭模型防护去复现类似行为。你得到的可能不是真实的攻击验证能力，而是一堆你无法判断真伪的高危代码。更麻烦的是，如果你对着这些代码做调试，反而会逐步把“假设的攻击”变成“实际能运行的攻击”。这一步一旦迈出去，性质就变了。

1.3 真正值得警惕的，是 AI 生成的业务代码里也可能带着同类问题

这个实验给开发团队的第一层提醒，不应该是“模型能不能攻击 Firefox”，而是“如果模型在较少限制下很容易生成高危代码，那它写普通业务代码时，是否也可能引入相似的高危模式？”

答案几乎是肯定的。许多团队已经在用大模型写接口、写数据库操作、写前端事件处理，生成速度和数量都远超人肉编码。如果开发流程里没有对 AI 代码做额外审查，那么以下几类问题会快速累积：

• 外部输入直接拼接进 SQL、命令行、HTML，形成注入类风险；
• 错误选择不安全的加密或哈希方案，导致数据保护偏弱；
• 缺少权限校验，让普通用户可以调用管理接口；
• 异常处理不当，把堆栈信息或内部路径直接返回给用户；
• 复制了一段在上下文 A 里正确、在上下文 B 里不安全的代码；
• 依赖了存在已知漏洞的第三方库，却没有锁版本。

对照一下，这些风险点和“关闭防护后生成漏洞样本”本质上共享同一个底层问题：大模型更擅长生成“看起来吻合指令的代码”，而不是“在真实系统里一定安全的代码”。所以，比起研究 245 这个数字，我更建议开发者把目光放回自己的代码仓库和 CI 流程。

2. 模型自带的安全防护，是安全流程里的缓冲，不是保险箱

2.1 为什么模型会有“拒绝回答”的能力？

大模型在训练阶段会经过大量的安全对齐处理，目标是降低有害输出概率。于是你会看到模型在面对恶意代码请求时，经常给出“我不能帮助你完成这件事”的回应。这给人形成一种错觉：模型自带道德护栏，只要默认配置不关，它就应该能挡住恶意问题。

但模型的安全对齐并不是一个操作系统级的安全边界。它只是一个概率层面的过滤器，依赖的是训练时见过的数据分布和当前输入的措辞方式。使用者换一种表达方式、增加一层任务包装、或者调整系统设定，都可能让模型从“拒绝”变成“配合”。这类问题业界一直在做红队对抗，但对抗本身也在持续演进。我们不应该把一个概率过滤器当作最终防线。

2.2 真正的安全边界应该放在外部流程，而不是模型内部

从工程经验看，越重要的系统越不能依赖某一层单独防护。模型安全也是同样的逻辑：如果你打算把大模型接入业务或安全工具，团队应该提前设计好几层控制，而不是相信模型默认会拒绝危险请求。

可以按下面这个分层方式理解：

很多团队只做到第二层，甚至只是“相信模型会拒绝”。一旦模型被绕过或输出了意料之外的内容，下游系统缺少任何拦截能力，事故就会直接进入生产环境。这就像在房子里装了烟雾报警器，却没有灭火器、没有消防通道、没有疏散预案——报警器能提醒你，但它不能阻止火势蔓延。

2.3 “关闭防护”实验的风险为什么不可控

回到 Claude Mythos 5.1 的讨论，如果实验真的通过关闭模型内建安全策略来生成漏洞利用样本，那么它不仅改变了模型的“意愿”，还可能改变模型输出的“质量基线”。模型在减少安全约束后，可能会输出一些看起来头头是道，但实际存在逻辑硬伤的代码。这时候，如果使用者不具备独立的安全能力，很容易把这些代码当攻击武器去调试，结果陷入更危险的路径。

安全工作的核心不是“生成越多的漏洞利用越好”，而是“在可控范围内做有效验证，并快速形成修复”。所以，即便研究者有合理目的去评估模型的极端能力，也应该把结论用在防御和改进模型上，而不是把可复现的步骤扩散出去。

3. 把 AI 用在“防御侧”，才是高杠杆率的用法

3.1 大模型真正擅长的事情

大模型真正擅长的，其实不是“发明攻击方法”，而是在已知模式的基础上做归纳、对比、解释和改写。把它用在防御侧，效果通常更好。常见的有这么几类：

• 代码审计辅助：让模型阅读一段代码，指出可能存在的问题，并给出修复方向。
• 补丁分析：给模型看某个历史漏洞和对应补丁，让它总结缺点和修复思路。
• 威胁建模：描述系统的功能模块、数据流和信任边界，让模型列出潜在风险点。
• 告警解释：把安全运营中的日志或告警信息交给模型，让它解释可能发生了什么。
• 报告生成：根据扫描结果自动草拟漏洞描述和整改建议，减少安全工程师写报告的时间。

在这些场景里，模型不需要生成一条针对真实业务的可利用攻击链，它只需要帮助人“更快看懂问题”和“更快找到修复路径”。这条路的价值丝毫不低于攻防对抗，而且安全得多。

3.2 一套可执行的“AI 辅助审计流程”

如果你想把大模型接入代码安全审计，可以先按下面的流程跑一轮。这个流程的核心原则是：“可以让模型指出问题，但不要让它生成攻击载荷。”

第一步，拆出有边界的输入。不要一次性把几万行代码全部塞给模型，而是按模块、接口、函数拆开，并提供数据流向和运行环境等上下文。这样模型的分析才不会变成空泛的“可能存在风险”。

第二步，要求模型以“风险描述 + 修复建议”的格式输出。下面是一个安全的提问示例：

请审查下面这段函数，重点检查是否存在输入验证缺失、权限绕过、注入或信息泄漏问题。 先说明风险类别和可能影响，再给出修复建议。 不需要编写利用代码，也不需要使用真实场景中的文件路径和密钥。

这里的关键是要求修复建议，同时显式排除利用代码。如果模型输出的内容超出这个范围，说明当前配置或提示还不够严，不能直接采用。

第三步，用静态扫描工具交叉验证。大模型的判断是基于概率的，不一定比专用扫描工具准确。你可以把 SAST 工具的结果和大模型的输出做交集，把两边同时标记的问题列为优先处理项。

第四步，要求模型给出两种修复方案：一种是最小改动，一种是重构。最小改动适合快速止血，重构方案适合根治。但无论哪种，都需要开发者独立理解并确认。

第五步，回归测试。修复代码必须通过原有功能测试，并且再用扫描工具确认风险消失。只有“修复前有风险”、“修复后风险消失”、“功能没有回归”三个条件同时成立，这次修复才算数。

3.3 如何判断模型的安全分析结果是否合格

不是所有模型输出都值得进入工单。你可以用下面几个问题过滤：

• 它是否给出了具体的风险触发条件，而不是只说“可能有问题”？
• 它是否区分了“业务假设”“代码事实”和“推测场景”？
• 它是否提供了可执行的修复代码，而不是只给安全建议？
• 它是否在不确定的地方主动要求人工验证？
• 它是否避免了输出可直接用于攻击的代码？

如果模型输出只是泛泛而谈，那它的参考价值很低。如果模型输出非常具体的攻击步骤，那它的风险又太高。真正合适的输出，恰恰是介于两者之间：能说清问题，能指导修复，但不替你完成越界动作。

4. 即使做攻防研究，也要先回答五个问题

总有人会问：安全研究不就应该研究漏洞利用吗？不把攻击链打通，怎么证明危害？

这是合规攻防测试的合法性问题。答案是：可以研究攻击，但必须限制在授权范围内。商业漏洞众测平台、企业红队、CTF 靶场、本地离线环境，这些都是合规的测试场地。可一旦研究对象变成真实用户、未授权设备、公网服务，性质就完全不同。

如果你确实需要在攻防对抗中使用大模型，或者评估一个模型的安全边界，建议在动手前先回答下面五个问题：

如果五个问题里任何一个回答“否”，你都应该停下，或者重新设计实验边界。很多安全问题并不是技术能力不够，而是从第一步授权就越界了。越界之后，无论模型生成了多少攻击样本，这个研究的合理性都会受到影响。

回到“关闭模型防护后生成漏洞利用样本”这类实验。假如它是在隔离环境、自建靶机、有明确研究目标的前提下进行，并且不公开完整可复现步骤，那么可以看作模型安全能力的一类压力测试。但如果只是为了让结果好看，就关闭全部安全规则，再把成功样本尽可能展示出来，那它产生的是一种“外部性攻击”：它不直接入侵系统，却给后来者提供了模仿的模板。这对整个行业未必是好事，尤其是当模仿者没有实验者那样的隔离环境时。

5. 当 AI 生成代码进入生产线，研发团队如何守住底线

5.1 AI 会让漏洞的“数量和速度”同时增大

过去，一个初级开发写出的危险代码，通常还会经过同事和代码评审，有较多机会被拦截。现在，大量 AI 生成代码以极快速度进入 PR，评审者精力有限，很多风险可能被忽略。再加上 AI 生成的代码风格可能非常规范，阅读感受很流畅，容易让人降低防备。

这种局面下，安全底线不应该靠某个人的警惕性，而应该靠流程进行硬性约束。

第一个硬性约束：标注 AI 生成代码。凡是 AI 生成的代码，提交到 Git 仓库时都应该在 commit message 或注释里留下标记。目的是让后续评审者知道这段代码没有经过完整的人类编码推演，需要更多关注。

第二个硬性约束：CI/CD 中加入自动化安全扫描。现在很多团队已经有 SonarQube、Semgrep、CodeQL 或类似工具，应该把 AI 生成的代码也纳入扫描对象，而不是只扫描人工代码。如果扫描规则发现高危问题，AI 生成的 PR 应该被阻止合并，而不是留到事后再说。

第三个硬性约束：禁止 AI 直接生成和修改生产配置。像数据库连接、云平台密钥、防火墙规则、部署脚本这类内容，不应该让 AI 在没有人类确认的情况下直接产出。AI 可以用自然语言解释需求，但最终配置应该由负责人落地和审计。

5.2 一套“AI 生成代码安全评审清单”

可以把这个清单放在每次代码评审的开头：

1. 输入是否完全可信？有没有从用户、网络、文件系统等不可信来源进入的数据？
2. 输出是否经过正确的编码、校验、转义或格式化？
3. 接口是否存在越权？调用方是否具备应有的角色和权限？
4. 异常路径是否被处理？出错时会不会把内部信息泄漏给前端或日志？
5. 依赖项、库版本、基础镜像是否能追溯到可信来源？
6. 代码逻辑是否符合业务上下文？还是只是从某段教程里直接复制？

这套清单不需要很高深的安全背景，只需要评审者在合入前多问一句：这段代码如果放在公网上，会被怎样滥用？很多严重漏洞，就是在这一步被拦下来的。

6. 回到那场试验：真正的安全能力是什么

那位研究者选择 Firefox 环境做测试，可能意图是想展示一个大模型在特定攻击面下的表现。 这种尝试确实能加深我们对模型安全边界的理解，但它给出的应该是一个用于内部反思的信号，而不是让所有读者都去复现的操作手册。

真正能给系统和业务带来长期安全的，不是某个模型在关闭防护后能生成 245 个漏洞利用样本，而是下面这些东西：

• 一个足够清晰的授权边界；
• 一个能够拦住危险的运行环境；
• 一套能快速定位问题并验证修复的流程；
• 一群不迷信 AI 输出、愿意做人工复核的工程师。

大模型的能力会越来越强，无论是写代码、读日志，还是辅助做安全分析。但它始终是一个需要被约束、被验证、被审计的外部工具。安全防护不该被寄托于模型“拒绝帮助你”的那一瞬间，而应该被设计在进入生产系统的每一道关卡上。

如果你只从这场讨论里带走一条建议，我希望是这句：不要在真实环境里关闭安全措施去测试极限；先确权、先隔离、先想好边界，再让 AI 帮你变快。真正的安全能力不是生成攻击的速度，而是阻止攻击发生的体系。