AI驱动的攻击同比增长89%。Hugging Face的泄露事件表明，当商业AI API在事件中期拒绝提供帮助时，应急响应计划需要备用方案。
https://t.co/XsbFtlSmrg

AI护栏阻碍了Hugging Face的防御者 | VentureBeat

来源：https://venturebeat.com/ai/safety-guardrails-blocked-hugging-faces-defenders-not-the-attacker-when-an-ai-agent-breached-its-systems
Hugging Face的事件响应团队最初尝试借助前沿AI模型分析公司生产基础设施的入侵事件，但模型拒绝提供帮助。商业安全护栏旨在阻止攻击者，却对所有取证查询进行了拦截，因为它们将响应团队的真实利用数据与实时攻击等同对待。

攻击者是一个自主AI代理系统，整个周末在Hugging Face基础设施内横向移动，未被检测或阻止。

安全领导者迅速识别出这一模式并诊断问题所在。“我在红队演练和内部安全测试中见过类似情况，但这是首批高调案例之一，它实质性地影响了真实的事件响应，“Merritt Baer说，她是Andesite、G2I和AppOmni的高级顾问，曾任AWS副首席信息安全官。

Baer表示，这并非Hugging Face独有的问题。“商业前沿模型优化以防止滥用。它们通常没有加密或组织层面的方式来判断询问’分析这段恶意软件’的人是事件响应者还是恶意软件作者。”

恶意数据集打开了两个代码执行路径

7月16日，Hugging Face披露（https://huggingface.co/blog/security-incident-july-2026），一个自主AI代理系统攻破了其生产基础设施，未经授权访问了有限数量的内部数据集和若干服务凭证。公司验证了软件供应链是干净的，未发现公开模型、数据集或Spaces被篡改的证据。

Hugging Face仍在评估入侵是否触及合作伙伴或客户数据，并表示将按要求直接联系受影响方。但很少有企业的威胁模型曾考虑到Hugging Face所面临的攻击者：一个自主代理从初始访问到凭证窃取全程运行整个攻击链，没有人类引导。

入口点是一个恶意数据集。当数据处理流水线接收该数据集时，它通过两种方式触发代码执行：一个远程代码加载器，以及数据集配置文件中的模板注入漏洞。没有准入关卡在文件到达处理工作节点（分配给每个数据集的计算任务）前进行筛查。初始访问正是通过数据流水线本身实现的，这一路径之所以有效，是因为大多数企业安全团队将输入流水线的数据视为可信输入而非攻击面。

工作节点隔离未能奏效。从最初的立足点开始，代理突破到运行工作负载的节点，然后窃取范围足够广泛的云和集群凭证，使其能够访问多个内部集群——这一切仅在一个周末内完成。Hugging Face描述该代理框架通过一系列短期沙盒执行了数千次独立操作，并利用公共服务托管自迁移的命令与控制。披露还指出，该框架似乎是基于一个代理型安全研究工具包构建的，这意味着用于红队演练的工具被用于实时入侵。

为什么防御者的查询看起来像攻击

调查人员使用自己的AI驱动分析代理重建了超过17,000条记录事件。

首次日志分析尝试使用了商业API背后的前沿模型。防御者的步骤包括提交真实的攻击命令、利用载荷和命令与控制工件进行分类，但安全护栏直接拒绝了这些请求。

Baer将拦截追溯到提示本身。“在主动入侵过程中最有价值的相同提示——shell命令、利用链、凭证转储、持久化机制、横向移动——正是最可能触发安全系统的提示，“她告诉VentureBeat。“随着AI嵌入安全运营，这变成了一个操作韧性问题，而不仅仅是模型策略问题。”

取证分析在GLM 5.2上完成

GLM 5.2，一个部署在Hugging Face自身基础设施上的开放权重模型，接手了商业API拒绝的工作。没有攻击者数据离开公司环境。“这次经历指出了值得规划的差距，“公司在披露中写道。Hugging Face不知道驱动这些代理的是哪个模型。它可能是一个被越狱的托管模型，或一个没有限制运行的开放权重模型。无论如何，披露继续写道，“攻击者不受任何使用政策约束，而我们自己的取证工作却因首次尝试的托管模型的护栏而受阻。“Hugging Face自己划清了界限，写道这次经历并非反对托管模型的安全措施，并将相关反馈分享给了涉及的提供商。

经过身份验证的信任会带来什么变化

Baer认为，行业需要超越将AI安全视为内容审核问题的思维。“安全运营需要不同的东西：经过身份验证的信任。“问题不再是是否应该给任何人答案，而是是否应该给予经过身份验证的安全团队（在企业控制下运行）这份答案。“模型不仅应该理解被问的是什么，还应该理解谁在询问、为什么以及处于何种治理之下。”

“企业已经为云中断、身份提供者故障或EDR故障制定了应急计划，“Baer写道。“AI助手正在成为另一个依赖项。”

她对应急响应预案的建议直白而明确。“一个成熟的事件响应计划应假设，在严重事件期间，商业AI API可能拒绝请求，API速率限制可能不可用，互联网连接可能受损，数据治理规则可能禁止外部上传取证证据。“她在邮件回复中写道，“教训不是’不要使用商业模型’，而是’不要让它们成为单点故障’。”

AI驱动的攻击同比增长89%

自主AI驱动的攻击不仅限于AI平台。CrowdStrike的2026年全球威胁报告（https://www.crowdstrike.com/en-us/global-threat-report/）记录了AI驱动的对手操作同比增长89%，平均突破时间降至29分钟。运行AI工作负载、且代理对流水线具有访问权限的企业面临同等暴露。

在Hugging Face案例中，六个控制域决定了影响范围和恢复速度。每个域对应安全领导者在下次自主代理入侵到来前可以采取的具体行动。

AI流水线入侵响应手册

控制域
问题所在
周一行动

数据集准入控制
两个代码执行路径被利用。没有准入关卡在数据集到达处理工作节点前进行验证。数据流水线成为初始访问基础设施。
要求所有数据集在到达工作节点前在沙盒中执行并进行静态分析。默认阻止远程代码加载器和模板注入路径。审计任何允许对非可信内容进行代码执行的路径。向董事会报告为供应链风险。

工作节点到节点的权限边界
工作节点隔离未能阻止向节点升级。代理获得集群凭证，因为工作负载与基础设施之间的边界从未在容器运行时强制执行。
在工作节点和节点之间实施严格的权限边界。部署容器运行时安全以防止工作负载逃逸。审计工作节点是否能访问节点级API或凭证存储。纳入下一次渗透测试范围。

凭证暴露
云和集群凭证在获得节点访问后被盗取。范围足够广泛，可以在一个周末内跨多个集群横向移动。
按计划轮换凭证，并在任何异常警报后立即轮换。限定最小范围的服务和集群权限。部署监控，以机器速度标记从意外节点发起的访问。为董事会报告绘制影响范围。

机器速度检测
通过短期沙盒执行数千次操作，配合自迁移C2。AI辅助异常检测在周末横向移动后才发现攻击活动，根据披露内容。
校准检测以匹配机器速度模式。确保高严重性警报在几分钟内无论时间如何都召唤响应者。审计SIEM规则，检测在一小时内出现的数千次短期执行。

私有AI取证能力
商业API阻止了取证分析。护栏筛选查询内容，从不分析分析师身份。调查在GLM 5.2上私下完成。
在事件发生前，在私有基础设施上部署具备能力的开放权重模型。针对真实取证工作流测试。确保响应预案包含商业API拒绝时的备用方案。记录差距用于网络保险申请。

自主代理威胁建模
攻击活动与预测的代理型攻击场景匹配，但没有任何威胁模型将其操作化。驱动代理的LLM仍然未知。
将自主AI代理作为具有机器速度决策周期的独立对手类别添加。以代理速度运行桌面推演。向董事会展示结果，证明时间线需要重新校准。纳入网络保险申请。

董事会问题是运营韧性

“对董事来说，问题很简单：如果我们的关键安全工具在我们最需要它的那一刻变得不可用，会发生什么？“Baer将此定位为运营韧性，而非AI政策。

她希望董事会将这一框架直接传递给管理层，并要求具体细节。“我们是否曾在桌面推演中实际演练过那个备用方案？在事件期间我们能多快切换？“采购也需要与治理同步改变，从买家提出的问题开始。评估AI供应商的安全团队应询问：他们对经过身份验证的事件响应者是否有流程？企业客户在验证的事件期间是否会得到不同的处理？模型是否可以私有化部署？“这些问题应与正常运行时间、隐私和合规性并列，“Baer说。

“最大的收获不是安全护栏’不好’。它们正在做它们设计要做的事情，“她辩称。

她更广泛的观点是，威胁模型本身已经改变。“几十年来，防御者拥有比攻击者更好的工具，因为他们操作在受信任的企业环境中。有了基础模型，双方越来越多地使用相同的功能，但一方受企业治理、政策、合规性和安全控制的约束，而攻击者只需下载一个未经审查的开放权重模型就能继续。这是一种新型的不对称性，“她补充道。“处理得最好的组织不一定拥有最强大的AI，而是那些将AI架构为韧性安全能力而非单一云服务的组织。”

Hugging Face已遏制入侵、重建受感染节点、轮换凭证并向执法部门报告事件。公司建议所有用户轮换访问令牌并审查最近账户活动。在事件中期，Hugging Face验证了自己的AI工具是否可用——第一个答案是否定的。运行着AI生产环境的安全领导者应该在事件响应规划中找到答案，而不是等到自主代理来强制测试。