本周早些时候，我们发现并应对了一起针对部分生产基础设施的入侵。它在一个关键方面不同于我们此前处理过的任何事件：从头到尾都由一套自主 AI 智能体系统驱动，而我们也主要借助自己的 AI 发现并剖析了它。
我们确认，有人未经授权访问了数量有限的内部数据集，以及服务所使用的若干凭据。我们仍在完成对合作伙伴或客户数据是否受到影响的评估；如有影响，将按要求直接联系相关方。我们没有发现公开、面向用户的模型、数据集或 Spaces 被篡改的证据，软件供应链（容器镜像和已发布的软件包）也已验证为干净。
发生了什么
这次入侵始于 AI 平台特有的暴露面：数据处理流水线。一个恶意数据集滥用了我们数据集处理中的两条代码执行路径（远程代码数据集加载器，以及数据集配置中的模板注入），从而在处理工作节点上执行代码。攻击者随后将权限提升到节点级别，窃取云和集群凭据，并在一个周末横向移动到多个内部集群。
这场行动由一个自主智能体框架执行（看起来建立在某个面向安全研究的智能体框架之上，所使用的 LLM 尚未确定）。它在一群短生命周期沙箱中执行了数以千计的独立操作，并将可自行迁移的命令与控制基础设施部署在公共服务上。这与业界一直预期的“智能体攻击者”情景相符。
我们采取了哪些措施
- 修复了根本漏洞：用于初始访问的数据集代码执行路径已经关闭。
- 清除了攻击者在受影响集群中的立足点，并重建了被攻陷的节点。
- 撤销并轮换了受影响的凭据和令牌，同时启动了更广范围的预防性密钥轮换。
- 在集群中部署了额外的安全护栏和更严格的准入控制。
- 改进了检测和告警机制，确保无论星期几，高严重性信号都会在数分钟内呼叫到响应人员。
我们正与外部网络安全取证专家合作，调查此事并审查安全政策和流程。最后，我们也已将该事件报告给执法机构。
致社区
作为预防措施，我们建议轮换所有访问令牌，并检查账户近期活动。如果你认为自己受到了影响，或希望报告安全问题，请通过 security@huggingface.co 联系我们。
我们感谢 Hugging Face 各团队的全天候响应，也对由此造成的任何干扰深表歉意。安全工作永无止境；我们会持续提高标准。
分析一次 AI 驱动的入侵
这次攻击最初是通过 AI 辅助检测发现的。我们的异常检测流水线会使用基于 LLM 的安全遥测分诊，将真实信号从日常噪声中分离出来；正是这些信号之间的关联揭示了这次入侵。
为了理解这群自动化操作所做的事情，我们对包含超过 17,000 条记录事件的完整攻击者操作日志运行了由 LLM 驱动的分析智能体。这让我们得以重建时间线、提取入侵指标、梳理被触及的凭据，并区分实际影响与诱饵活动。借助这种方法，我们在数小时内完成了通常需要数天的工作，追上了对手的速度。
我们能用于这项分析的模型，受到了一个此前未曾预料的限制；下文会说明。
不对称问题
开始日志分析时，我们首先使用了通过商业 API 提供的前沿模型，但这没有奏效：分析需要提交大量真实攻击指令、漏洞利用载荷和 C2 工件，而这些请求被模型提供方的安全护栏拦截。它们无法区分事件响应人员和攻击者。于是，我们改在自有基础设施上使用开放权重模型 GLM 5.2 进行取证分析。这还有第二个好处：攻击者数据及其提及的凭据都没有离开我们的环境。
这段经历指出了一个值得预先规划的缺口。我们不知道攻击者的智能体由什么模型驱动——是越狱后的托管模型，还是不受限制的开放权重模型；无论是哪一种，攻击者都不受任何使用政策约束，而我们最初的取证工作却被托管模型的安全护栏阻断。对防御者的实际启示是：应在事件发生之前，审查并准备好能够在自有基础设施上运行的强大模型，既避免被安全护栏锁死，也防止攻击者数据和凭据离开环境。这并非反对托管模型采取安全措施；我们也正在与相关提供方分享这一反馈。
这意味着什么
自主、AI 驱动的进攻工具已不再只是理论。它降低了开展大范围、耐心而多阶段行动的成本，并以机器速度运转。如今，防御在线平台意味着必须将数据和模型表面视为一等攻击面，并利用 AI 防御来跟上节奏。我们会继续投入这一方向，并持续分享所学。