一个异常信号在Hugging Face安全团队的监控屏幕上急促闪动。基于大语言模型(LLM)的异常检测管道正在关联一群原本会被日常噪声淹没的低强度信号。经过初步拼凑,安全分析师们意识到,他们面对的很可能是一场完全由自主AI代理驱动、横跨整个周末的精密入侵。
Hugging Face本周正式披露了这一事件。攻击者利用其数据集处理流水线中的两处代码执行漏洞打开了入口:一个是远程代码数据集加载器,另一个是数据集配置中的模板注入缺陷。借助这两道裂缝,攻击者成功闯进了处理工作节点,随即提权到节点级访问,开始大范围收割云凭据和集群密钥。
![]()
从那一跳开始,攻击在不到一个周末的时间里迅速扩散。对方在一个被安全人员称为“蜂群”式的短生命周期沙箱中执行了数千个操作,横向移动过多个内部集群,指挥控制(C2)基础设施还能在公共托管服务上自动迁移,让传统溯源手段几乎失效。这与安全社区多年来预测的“代理型攻击者”场景高度吻合。
不过,攻击者并没有触碰公共模型、数据集、Spaces或软件供应链。受到影响的范围被严格限制在一小部分内部数据集和服务凭据内。Hugging Face的调查结论是,黑客聚焦于基础设施层面的渗透和凭据窃取,而非破坏开源生态。
真正让这次入侵区别于传统事件的,是攻击全链条的自主程度。整个入侵过程没有接收到任何人类指令,完全是AI代理自主决策和行动。这也意味着,防御方不再只是和人类攻击者赛跑,而是在与一个能自我编排、弹性伸缩的自动化对手博弈。
在事件响应阶段,Hugging Face的安全团队把自家LLM分析代理推上前台,让它逐一啃食超过17000条攻击动作记录。这些记录散布在不同时间点、不同集群,传统人工溯源至少要耗费数天,而AI辅助分析在几小时内就拼凑出了完整的攻击时间线。
但就在团队试图调用业界顶尖的商业大模型API来进一步深挖取证时,意外发生了——这些前沿模型的内部安全护栏拒绝执行请求。原因很直接:护栏无法区分一个合法的安全事件响应人员提交的真实漏洞利用载荷和指挥控制痕迹,与一个正在实施攻击的黑客所提交的内容。在它们看来,这些都是“危险内容”,需要封堵。
安全团队迅速切换方案,转而使用开源模型GLM-5.2,并部署在Hugging Face自有的基础设施上运行。这一做法不仅绕开了商业模型的策略束缚,更重要的是,确保所有攻击数据和涉及的凭据从未离开Hugging Face的控制环境。事后验证显示,同一批载荷在GLM-5.2上完成了全量分析,且没有任何泄密风险。
这一幕暴露出一个残酷的不对称局面:攻击者可以轻易使用越狱或本地部署的、毫无限制的模型来策划和推进攻击,而防御者一旦依赖托管的商业模型,就有可能在事件处置的关键时刻被“锁在门外”。当攻击畅通无阻时,防守方最倚重的AI工具却可能突然失灵。
这起事件并非孤例。安全厂商Sysdig近期披露了一个代号JADEPUFFER的案例,被认定为首次完全由自主AI驱动的勒索软件操作。在那个案例里,一个AI代理独立渗透了一台暴露在互联网上的服务器,横向移动、加密文件并发出赎金要求,全程零人类指令介入。Check Point发布的《2026年度AI安全报告》同样记录了自主AI入侵事件的显著增多,并且攻击者对漏洞的利用窗口正从“天”压缩到“小时”。
Hugging Face自身的遭遇印证了这些报告的预警:自主攻击AI工具已经从理论推演进入实战阶段,防御方准备不足的现实正在被快速放大。英国国家网络安全中心已经为此启动了“网络盾牌”计划,试图统一部署对抗自主AI威胁的防御栅栏。
在对外沟通中,Hugging Face建议所有用户尽快轮换访问令牌并审查近期账户活动,以防范凭据泄露带来的潜在风险。同时,其安全团队也在内部复盘这场AI对AI的攻防战——从检测、取证到借助开源模型完成闭环,整个过程正在被沉淀为新的安全基线。
当攻击开始由自主AI代理执行,而防御的AI却可能因为商业规则被拦在门外时,安全建设的底层逻辑必须重写。这是一个提醒:面对即将全面到来的代理型攻击,防守方的工具链同样需要保留完全自主、不受第三方策略掣肘的分析能力。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.