最近在安全社区里一则关于 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 靶场、本地离线环境这些都是合规的测试场地。可一旦研究对象变成真实用户、未授权设备、公网服务性质就完全不同。如果你确实需要在攻防对抗中使用大模型或者评估一个模型的安全边界建议在动手前先回答下面五个问题问题检查要点1我对当前测试目标是否有明确授权2我的测试环境是否隔离了真实用户和真实业务3我是否最小化收集和留存数据并避免下载无关敏感数据4我的输出物是否可能被直接用于侵害真实对象5我在披露结果时是否给目标方留了合理修复周期如果五个问题里任何一个回答“否”你都应该停下或者重新设计实验边界。很多安全问题并不是技术能力不够而是从第一步授权就越界了。越界之后无论模型生成了多少攻击样本这个研究的合理性都会受到影响。回到“关闭模型防护后生成漏洞利用样本”这类实验。假如它是在隔离环境、自建靶机、有明确研究目标的前提下进行并且不公开完整可复现步骤那么可以看作模型安全能力的一类压力测试。但如果只是为了让结果好看就关闭全部安全规则再把成功样本尽可能展示出来那它产生的是一种“外部性攻击”它不直接入侵系统却给后来者提供了模仿的模板。这对整个行业未必是好事尤其是当模仿者没有实验者那样的隔离环境时。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 生成代码安全评审清单”可以把这个清单放在每次代码评审的开头输入是否完全可信有没有从用户、网络、文件系统等不可信来源进入的数据输出是否经过正确的编码、校验、转义或格式化接口是否存在越权调用方是否具备应有的角色和权限异常路径是否被处理出错时会不会把内部信息泄漏给前端或日志依赖项、库版本、基础镜像是否能追溯到可信来源代码逻辑是否符合业务上下文还是只是从某段教程里直接复制这套清单不需要很高深的安全背景只需要评审者在合入前多问一句这段代码如果放在公网上会被怎样滥用很多严重漏洞就是在这一步被拦下来的。6. 回到那场试验真正的安全能力是什么那位研究者选择 Firefox 环境做测试可能意图是想展示一个大模型在特定攻击面下的表现。 这种尝试确实能加深我们对模型安全边界的理解但它给出的应该是一个用于内部反思的信号而不是让所有读者都去复现的操作手册。真正能给系统和业务带来长期安全的不是某个模型在关闭防护后能生成 245 个漏洞利用样本而是下面这些东西一个足够清晰的授权边界一个能够拦住危险的运行环境一套能快速定位问题并验证修复的流程一群不迷信 AI 输出、愿意做人工复核的工程师。大模型的能力会越来越强无论是写代码、读日志还是辅助做安全分析。但它始终是一个需要被约束、被验证、被审计的外部工具。安全防护不该被寄托于模型“拒绝帮助你”的那一瞬间而应该被设计在进入生产系统的每一道关卡上。如果你只从这场讨论里带走一条建议我希望是这句不要在真实环境里关闭安全措施去测试极限先确权、先隔离、先想好边界再让 AI 帮你变快。真正的安全能力不是生成攻击的速度而是阻止攻击发生的体系。