全球最大的AI开源平台Hugging Face，遭遇了一次由自主AI智能体发动的网络攻击。这次攻击不仅展示了AI攻击的自主性与破坏力，更在取证阶段暴露了一个深刻的困境：商业大模型的安全护栏，在关键时刻把防御者关在了门外。

一、攻击：一个周末，AI自主完成入侵

这场入侵始于一个看似平常的数据集。攻击者上传了一个恶意数据集，利用了Hugging Face数据处理流水线中的两个代码执行漏洞——一个远程代码数据集加载器，以及数据集配置中的模板注入漏洞。

恶意代码在一个数据处理工作节点上被执行。攻击者随后将权限提升至节点级别，窃取了云平台和集群的凭证。在一个周末的时间里，攻击者在多个内部集群间横向移动。

整个攻击流程完全由自主AI智能体框架完成。该智能体在大量生命周期极短的沙盒环境中执行了数万次独立操作，并利用公共服务搭建了能够自主迁移的命令与控制（C2）基础设施。这正是安全行业长期预警的“智能体攻击者”场景。

此次入侵导致少量内部数据集及部分服务凭证遭到未经授权访问。Hugging Face强调，没有发现任何公开模型、数据集或Spaces遭到篡改。

二、防御：AI检测，AI分析，AI反击

Hugging Face的防御同样由AI驱动。

检测阶段，其异常检测流水线利用LLM对安全遥测数据进行分诊，通过关联那些容易被忽略的信号，最先标记出了入侵。

取证阶段，安全团队让LLM驱动的分析智能体读取了超过1.7万条攻击者行为日志。通过分析，团队得以重建攻击时间线、提取威胁指标、映射被接触的凭证，并将真实影响与干扰活动区分开来。原本可能需要数天的取证工作，被压缩至数小时。

三、不对称困境：商业模型拒绝协助

取证分析需要向模型提交大量真实的攻击命令、漏洞利用载荷和C2工件。当安全团队最初尝试使用美国某商业前沿大模型的API时，请求被彻底拒绝。

原因在于，这些商业模型的安全护栏无法区分提交攻击载荷的事件响应人员和真正的攻击者。模型对输入内容进行“一刀切”的拦截，导致防御者在最需要AI帮助的时刻，被自己依赖的工具拒之门外。

攻击者使用的智能体，可能是越狱的托管模型或不受限制的开放权重模型，不受任何使用政策的约束。而防御者使用的商业模型，却被护栏死死拦住。

四、GLM 5.2：在自有基础设施上完成取证

面对商业模型的拒绝，Hugging Face团队转而在自有基础设施上部署了中国的开源模型GLM 5.2。

GLM 5.2是智谱AI（Z.ai）发布的开放权重模型。在本地部署后，团队顺利完成了对海量安全日志的取证分析。本地部署还带来了额外的安全收益：所有攻击者数据和被引用的凭证，都没有离开Hugging Face自己的环境。

五、核心教训：备好一个能自托管的模型

Hugging Face在事后分析中坦言：“我们不知道攻击者的智能体使用了哪个模型，无论是越狱的托管模型还是不受限制的开放权重模型；无论哪种方式，攻击者都不受任何使用政策的约束，而我们自己的取证工作却被我们首先尝试的托管模型的护栏所阻止。 ”

此次事件的核心教训是：

避免护栏封锁：在事件发生前，就准备好一个经过验证的自托管AI模型，以防在取证分析时被商业API的安全策略拦截。

保护数据安全：本地部署能确保敏感的攻防数据不离开自己的环境。

随着AI智能体逐渐参与网络攻击，安全分析对大模型的理解能力、推理能力以及部署方式提出了更高要求。Hugging Face建议所有用户更换账户访问令牌，并检查近期账户活动是否异常。