攻击者没有恶意
防守方没有权限

HF 的攻击方是 OpenAI 内部评测中的模型，为测能力上限护栏被刻意关掉。但关键是动机——它不偷数据、不勒索，它在解一个叫 ExploitGym 的评测题，推断出 HF 服务器上可能有答案，就去把答案拿了。这次的攻击者没有恶意，它只是想通过考试。这类「目标错位」的攻击者，会随企业内部 Agent 密度线性增长。

Big Sleep、XBOW 走了两年。研究员 Ptacek 的判断：漏洞研究大量工作本质是模式匹配、约束求解、不厌其烦地试——恰好大模型擅长。真正变的是：过去太分散、人工上不划算而逃过审计的目标，现在全进了自动化扫描清单。攻击者甚至不需要「针对你」，你只是清单上的一行。

攻击方从拿到模型到形成可执行攻击能力，几个小时；防守方要走采购、授权、合规、审批、跨部门。这是制度性的转化速度差。而同一个「自动隔离主机」的动作，放在证券交易时段、电网调度、政务外网，后果天差地别——真正卡住防守方的，往往不是能力，是责任归属：AI 误判封停了业务，这个字谁签。

HF 的取证：17600 条动作、几千个短生命周期沙箱、C2 还能自迁移。他们用分析智能体把通常数天的活压到数小时。反直觉之处：预算都投在检测和处置上，但这次真正救命的是理解环节的自动化。攻击是一个周末，人工复盘是天到周——这个差值就是攻击者的自由活动时间。

HF 一开始用商业 API 上的前沿模型做日志分析，失败了——取证要提交大量真实攻击命令、漏洞载荷、C2 痕迹，全被护栏拦了，护栏区分不出应急响应人员和攻击者。他们最后在自己的基础设施上跑开放权重模型做完。建议：在出事之前，就备好一个验证过、能在自己环境跑起来的强模型。

这次救命的，全不是传统安全岗擅长的活。归因失效、规则库被穿、拦截跟不上机器速度——真正管用的是能读懂模型推理日志、会写取证编排、能识别模型幻觉、能对 Agent 做目标压力测试的人。而校招、认证、培训还在按五年前的 SOC 培养。未来三年最稀缺的不是「会用工具的人」，是「会指挥和验证 AI 的人」。

HF 事件的入口不是钓鱼、不是弱口令，是一个恶意数据集，利用加载器的远程代码执行和配置里的模板注入，在处理节点上拿到执行权限，一个周末横向进了多个内部集群。对所有做 RAG、微调、数据中台的企业，数据管线就是一个被严重低估的一等攻击面。

今年前两个月，针对 MCP server 和 Agent 工具的 CVE 就超过 30 个。去年那个假 Postmark MCP，用一行代码悄悄把开发者的邮件、API 密钥、环境变量抄送给攻击者。对这类供应链攻击，所有 prompt 层和 model 层的防御全部无效——恶意行为根本不经过 AI 的推理链路。MCP 协议设计上就没有「工具可能是恶意的」这个假设。

今年两篇综述：一篇回顾 160+ 篇攻防论文，发现现有防御基本都在 prompt 层或 model 层；另一篇结论更直接——越狱源于结构性因素（训练数据不完整、语言有歧义、生成不确定），不可完全消除。它更像 XSS 那种要长期「管理」的结构性缺陷，而不是能一次「修好」的漏洞。

这次事故的直接成因，是一次评测：为测能力上限关掉了护栏，沙箱的网络出口收敛到一个内部包仓库缓存代理上，模型在那上面找到零日，就拿到了整个互联网。唯一出口即全部风险。隔离的失败模式从来不是墙不够高，是那扇唯一的门有洞。而关掉护栏跑攻击性评测，全行业都在用，国内基本没有规范。