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