Hugging Face 自主 AI 智能体入侵事件让 AI 反制 AI

Hugging Face 表示，一个自主 AI 智能体入侵了其生产基础设施，执行了超过 17,000 次有记录的操作，并迫使防御方采用同等程度的自动化手段进行应对。

Hugging Face 自主 AI 智能体入侵事件始于一个恶意数据集，而非某种新型人工智能漏洞利用手段。两条代码执行路径使攻击者得以进入一个处理工作节点。随后，该智能体提升了访问权限、收集凭据，并在一个周末内横向移动至多个内部集群。

调查期间，更深层的冲突浮出水面。据报道，托管的前沿模型拒绝处理响应人员需要分析的恶意命令和漏洞利用构件。Hugging Face 转而在自己的基础设施上运行 GLM 5.2，并在数小时内重建了攻击过程。

这一过程将一起安全事件转化为对依赖性的警告。攻击者可以移除其系统的使用限制，而防御方却可能恰恰在最需要高级分析时遭遇限制。这起入侵事件让托管 AI 的安全控制与自托管环境的运维控制形成了直接冲突。

入侵始于恶意数据集内部

重要的变化并非出现了新的黑客技术，而是智能体组合运用常见技术时展现出的速度和持续性。

Hugging Face 于 2026 年 7 月 16 日披露了这起事件。其安全披露称，公司于当周早些时候检测到其部分生产基础设施遭到未经授权的访问。

公司确认，一小部分内部数据集和若干服务凭据遭到访问。截至发布时，其对于合作伙伴或客户数据可能遭到泄露的评估仍未完成。

Hugging Face 表示，没有发现攻击者修改公开模型、数据集或 Spaces 的证据。该公司还表示，其容器镜像和已发布的软件包均已接受检查，未发现问题。

这些声明至关重要，因为 Hugging Face 运营着供开发者分发模型、数据集、应用程序和配套代码的基础设施。篡改公开构件可能引发范围更广的软件供应链问题。

公司尚未报告此类篡改行为。然而，由于调查仍在进行，读者应区分当前证据与最终结论。

最初的访问路径十分明确。攻击者上传了一个恶意数据集，利用了远程代码数据集加载器以及数据集配置中的模板注入漏洞。

远程代码执行使攻击者能够让目标系统运行未经授权的指令。模板注入则会操纵应用程序作为可执行模板逻辑处理的字段。

载荷运行后，攻击者访问了底层节点。该攻击行动先收集云和集群凭据，随后横向移动至多个内部集群。

横向移动是指利用一个已遭入侵的系统访问更多系统。在云环境中，被盗凭据往往是连接这些阶段的桥梁。

据报道，该攻击行动通过一个自主智能体框架运行。Hugging Face 描述了短期存续的沙箱，以及在公共服务之间迁移的命令与控制基础设施。

沙箱是用于运行任务的隔离计算环境。由临时沙箱组成的集群可以分散任务，并使单个持续运行的进程更难被追踪。

命令与控制通常简称为 C2，是用于操控受感染系统的通信通道。迁移该通道可能增加拦截和归因的难度。

Hugging Face 尚未确认该智能体框架背后的模型。该公司不确定攻击者使用的是经过越狱的托管模型，还是不受限制的开放权重模型。

现有证据也无法证明某个 AI 系统自主选择了 Hugging Face 作为攻击目标。很可能是操作人员提供了目标、基础设施或初始设置。

因此，“自主”描述的是攻击链中的执行方式，不应被理解为该系统产生了自身犯罪意图的证据。

独立报道印证了已披露的攻击路径。入侵事件报道同样提到了恶意数据集、凭据窃取以及在内部集群之间的移动。

然而，将攻击归因于自主框架的结论，目前主要仍以 Hugging Face 的遥测数据和分析为依据。据该公司称，外部数字取证专家正在审查此事件。

Hugging Face 已关闭两条存在漏洞的代码执行路径。该公司还清除了攻击者的立足点、重建了受感染节点，并吊销了受影响的凭据和令牌。

公司开始采取更广泛的预防性密钥轮换措施。它增加了更严格的集群准入控制，并调整了告警机制，使严重信号能够在数分钟内呼叫响应人员。

该公司还向执法部门报告了此次入侵。这些遏制措施解决了当前事件，但尚未回应其更广泛的影响。

矛盾首先源于规模。一个由人工组成的调查团队必须在凭据被用于其他地方之前，从临时环境中重建数千次由机器生成的操作。

这一工作量促成了故事的后半部分。Hugging Face 需要使用智能体，不仅仅是为了检测恶意软件，更是为了理解另一个智能体的行为。

Hugging Face 使用 AI 分析了超过 17,000 起事件

Hugging Face 最具影响力的说法是，AI 将数天的取证分析压缩到了数小时，而且无须将敏感证据发送到其环境之外。

公司表示，入侵最初由 AI 辅助检测发现。其异常检测管道利用语言模型对安全遥测数据进行初步分类，帮助从常规运维噪声中识别有意义的关联。

安全遥测数据包括日志、告警、网络事件和系统活动。每条记录单独来看可能并无异常，但一系列记录却可能揭示权限提升或凭据滥用。

检测只是开始。响应人员面对的是一份包含超过 17,000 起记录事件的攻击者操作日志。

Hugging Face 表示，其在完整日志上运行了由 LLM 驱动的分析智能体。这些智能体重建了时间线、提取失陷指标，并确定攻击者接触过哪些凭据。

失陷指标是与恶意活动有关的可观察痕迹。它们可能包括地址、文件哈希值、命令、域名、账户行为和异常访问模式。

分析还区分了实际影响与诱饵活动。这一点很重要，因为自动化攻击行动除了真正改变系统的步骤外，还可能产生大量失败或用于干扰判断的操作。

传统取证工作通常要求分析人员对多个来源的记录进行标准化处理。随后，他们需要排列事件顺序、关联身份、移除重复项，并检验相互竞争的解释。

智能体可以通过读取大段日志、提出关联关系并分配后续任务来加快这项工作。它还可以在不同沙箱中搜索重复出现的命令。

Hugging Face 表示，这种方法将通常需要数天完成的工作缩短到了数小时。公司尚未发布基准测试、人员配置对比或完整的方法说明。

因此，这一时间缩减是公司报告的结果，而不是经过独立复现的性能指标。基础事件数量同样来自 Hugging Face 自己的日志。

尽管如此，这一运维用例仍然可信。数字取证涉及大量结构化和非结构化证据，而语言模型可以对其进行分类和总结。

核心要求是可追溯性。响应人员必须能够将每个重要结论关联到原始证据，而不是直接相信智能体给出的叙述。

看似合理的重建不一定准确。模型可能遗漏关键事件、合并不同身份，或根据时间接近但并无因果关系的事件推断因果关系。

因此，取证智能体最适合作为人类调查人员的加速工具。它们可以缩小搜索范围，而由合格的响应人员验证影响并作出遏制决策。

Hugging Face 自主 AI 智能体入侵事件还展现了编排的另一项优势。多个智能体可以将大型调查拆分成范围明确的任务，而不必要求一个模型消化全部内容。

一个进程可以构建时间线，另一个可以追踪凭据，第三个可以识别 C2 基础设施，第四个则可以对比成功操作与失败尝试。

随后，协调进程可以整合这些输出。这种结构类似于由人工组成的事件响应团队，但能够同时处理更多记录。

这种设计也会带来风险。智能体可能将一个错误假设传播到多个子任务中，从而生成彼此一致但结论错误的调查结果。

谨慎的证据管理因此变得不可或缺。团队需要保存原始日志、使用稳定的时间戳、记录提示词和模型版本，并保留每一次智能体操作的记录。

可搜索的内部知识系统可以帮助响应人员将历史架构决策与当前证据关联起来。这正是复杂技术工作中AI 知识库更广泛的价值。

然而，普通的知识助手并不会自动成为取证系统。事件分析需要访问控制、不可变证据、可复现查询，以及对观察和解释进行严格区分。

Hugging Face 的说明没有披露足够的细节，无法全面评估这些控制措施。它也没有公布 AI 辅助检测的误报率。

这些信息缺失并不会使报告的结果失效，而是界定了外部观察者目前无法衡量的内容。

真正值得关注的说法更为具体。AI 似乎帮助 Hugging Face 以大致跟得上自动化攻击者的节奏完成了调查。

这种能力非常重要，因为攻击速度会改变响应工作的成本效益。一个需要数天才能理解周末攻击行动的团队，即使完成初步遏制，仍会长期处于风险之中。

自动化可以缩短这一差距。然而，调查显示，当证据包含真实的恶意材料时，能否获得一个能力足够强的模型并无保障。

防御方使用的托管模型拒绝处理证据

核心反转十分鲜明：攻击者似乎不受任何使用政策约束，而防御方却表示，安全控制阻碍了正当的取证工作。

Hugging Face 最初尝试使用通过商业 API 提供的前沿模型。据该公司称，由于安全系统拒绝处理真实命令、漏洞利用载荷和 C2 构件，这些尝试均告失败。

过滤器无法可靠地区分正在检查恶意证据的响应人员与寻求实操帮助的攻击者。两类用户可能会提交几乎完全相同的命令和代码。

这是一个困难的分类问题。意图往往取决于组织背景、授权情况、周边证据，以及用户之后能够采取的行动。

托管服务提供商通常只能看到提示词和账户上下文。它可能没有足够的信息验证某人是否控制受影响的环境，或者是否负责该环境的调查。

保守的过滤机制降低了模型协助有害活动的可能性。当安全团队需要详细分析时，同样的策略也可能阻碍获授权的工作。

Hugging Face 将其称为不对称问题。攻击者的系统不受那些限制防御者最初模型选择的约束。

该公司并未主张托管模型应放弃安全控制。它表示，正在与相关提供商分享反馈。

这一区别至关重要。在全局范围内移除安全防护，会让恶意用户更容易获得同样的分析和操作能力。

尚未解决的挑战是选择性授权。提供商需要找到一种既能支持经过验证的防御者，又不会为攻击者制造便利例外的方式。

可行方案包括经过审核的安全计划、受控工作区、更严格的身份检查，以及对专用网络安全模型的受监控访问。每种方案都会引发隐私和治理方面的问题。

提供商可能会要求客户提交敏感证据以供审核。然而，事件记录通常包含凭据、内部地址、专有代码和个人信息。

这带来了拒绝之外的第二个问题。将完整日志发送到外部 API，可能会增加处理泄露证据的系统和组织数量。

Hugging Face 使用其所称的开放权重模型 GLM 5.2，避开了这两项限制。开放权重模型会根据适用的许可条款提供其训练后的参数，以供本地部署。

该公司在自己的基础设施上运行了该模型。它表示，在分析期间，没有任何攻击者数据或被引用的凭据离开其环境。

本地部署让运营方能够更好地控制模型配置、数据保留、网络访问和安全策略。同时，它也让运营方承担更多责任。

自托管模型默认并不具备可信的取证流程。团队必须保护其运行时、验证输出、管理补丁，并防止已遭篡改的证据控制已连接的工具。

不应仅仅因为模型在本地运行，就赋予它广泛的生产环境权限。分析和修复需要不同的权限级别。

分析代理可以读取隔离环境中复制的日志。而能够轮换密钥或更改集群的修复代理，会带来大得多的运营风险。

在执行后果重大的操作前，仍然应该经过人工批准。如果速度最快的模型意外销毁证据或中断未受影响的服务，它也毫无用处。

因此，这一事件并不能证明开放模型普遍比托管模型更安全。它表明，在一次特定调查期间，本地控制可以保障可用性和数据保管权。

托管服务也有自身优势。提供商可以快速更新模型、监控跨客户的滥用行为，并维护小型团队无力运营的专用基础设施。

本地系统减少了对提供商的依赖，却增加了内部维护成本。组织必须针对每项工作负载，决定哪种故障模式更值得重视。

对于事件响应而言，在面对恶意输入时保持可用性尤为重要。安全模型必须处理与其安全系统被训练为拒绝的内容相似的材料。

这一要求应在危机发生前进行测试。一个能处理脱敏演练数据的模型，在日志包含真实利用链或凭据窃取命令时，可能会失效。

这一教训不仅适用于网络安全。组织越来越多地使用 AI 搜索机密记录、整合内部来源并支持时间敏感型决策。

将敏感上下文保留在本地可以降低信息泄露风险。精心设计的知识工作流还可以保留生成结论与底层材料之间的关联。

取证用途仍然比常规知识工作要求更高。模型必须将所有由攻击者控制的内容都视为证据，而绝不能视为可信指令。

这种隔离引出了更广泛的安全问题。AI 可以协助调查攻击，也可能引入恶意数据影响自动化系统的新途径。

代理式速度不能成为基础设施失效的借口

代理加快了攻击活动的节奏，但真正使入侵成为可能的，是常规的代码执行漏洞和可访问的凭据。

最具戏剧性的解读聚焦于一个 AI 代理攻破了一个 AI 平台。这种叙事可能会让人忽视那些本应限制入侵的控制措施。

初始载荷利用了两条代码执行路径。一旦运行，攻击者便可获取支持其横向移动至其他集群的凭据。

这些都是常见的安全失误。不可信处理、权限过大、密钥可访问以及隔离薄弱等问题，在现代语言模型出现之前就已存在。

代理可以更快、更持续地利用这些条件。但这并不会让基础设施的根本性控制措施过时。

安全团队仍应尽可能降低工作节点的权限、隔离处理任务并限制元数据端点。团队还应缩短凭据有效期，并监控异常的令牌使用行为。

数据集处理尤其值得关注，因为用户会有意提交复杂且不可信的材料。某些格式会调用加载器、模板、解析器或外部代码。

每一项可执行功能都会扩大攻击面。沙箱机制必须假定上传内容会尝试逃逸。

Hugging Face 表示，它已关闭这些易受攻击的路径，并实施了更严格的集群准入控制。重建节点和轮换凭据可以降低残留立足点的风险。

更深层的问题在于，为什么处理工作节点能够获取可用于其他位置的凭据。公开披露的信息很少能提供足够的架构细节，以安全地回答这个问题。

外部审查或许能澄清横向移动究竟源于一个权限宽泛的凭据、多个暴露的密钥，还是跨服务的链式访问。每种可能性都意味着不同的整改工作。

这种不确定性正是本文质疑的核心。Hugging Face 对 AI 的归因不应取代对权限边界和密钥管理的审视。

该公司表示，这场攻击活动类似于一种代理式安全研究工具链。它尚未识别出具体模型、框架、操作者或完整的决策过程。

记录到的 17,000 多起事件表明自动化已达到相当规模。仅凭事件数量，并不能证明每一步都涉及模型的独立推理。

脚本、扫描器、重试循环、编排代码和语言模型都可能参与自动化攻击活动。它们各自扮演的角色会影响防御者的应对方式。

主要依赖脚本的攻击，需要采用针对大规模自动化的常规控制措施。能够适应失败的推理代理，则要求对行为序列进行更深入的监控。

相关事件说明了这种区别为何重要。研究 JadePuffer 攻击活动的人员描述了一个代理，它在 31 秒内使用修正后的参数重试了失败的步骤。

代理式勒索软件分析中引用的专家表示，底层技术并无多少新意。代理的价值在于将这些技术连接起来并加速执行。

这一模式符合更广泛的风险趋势。AI 无需发明未知漏洞，也能扩大破坏。

它可以扫描更多目标、在多个步骤间保留上下文、修订命令，并不知疲倦地持续工作。它还可以在机器生成的笔记中记录自己的推理过程。

如果这些笔记被获取，就能帮助调查人员。它们可以揭示攻击重点、失败的尝试，以及代理预期遵循的执行顺序。

自动化同样会产生错误。代理可能追逐诱饵、臆造资源、暴露自身基础设施，或采取破坏性措施，从而妨碍攻击者实现目标。

防御者不应将每场 AI 辅助的攻击活动都视为由无懈可击的机器对手发起。系统会继承其模型、工具、数据和编排机制的弱点。

近期学术研究还提出了另一个问题。2026 年 7 月一篇关于代理数据注入的论文发现，恶意数据可能在代理上下文中被误解为可信元数据。

研究人员展示了针对 Web 代理和编码代理的攻击。他们认为，许多防御措施虽然将指令与数据分开，却没有在工具结果中区分可信数据和攻击者控制的数据。

这项研究描述的并不是 Hugging Face 入侵事件。但它揭示了用于调查该事件的防御代理所面临的风险。

攻击日志包含命令、文件名、URL、结构化字段，以及由对手刻意创建的文本。代理绝不能将这些内容解释为供自身工具执行的指令。

因此，应在多个层面实施隔离。模型应在受限环境中分析复制的证据，并且不具备任何不必要的生产环境访问权限。

工具结果应带有来源标签。系统应区分可信元数据和攻击者能够操纵的字段。

后果重大的操作应经过确定性检查或人工批准。团队还应记录提出每项操作的原因，以及支持该操作的证据。

这些控制措施可以降低防御代理变成另一条攻击路径的风险，也能让其结论更易于审计。

同样的原则也适用于使用公共模型、数据集、插件和代理技能的开发者。在经过验证之前，应将可下载的 AI 制品视为不可信软件。

Hugging Face 的平台此前也曾被用于传播恶意活动。这段历史说明，代码仓库安全是一个持续存在的运营问题，而非仅持续一周的异常事件。

7 月的入侵事件提高了紧迫性，因为代理式自动化缩短了响应窗口。但它并未削弱修补漏洞、网络分段、最小权限和谨慎设计凭据的价值。

此次入侵给 AI 提供商和安全团队带来压力

这一事件迫使托管模型提供商和企业防御者在下一次紧急事件发生前，明确获授权的 AI 辅助安全工作应采取何种形式。

托管服务提供商面临着最明确的产品挑战。其网络安全防护措施必须阻止有害协助，同时又不能让合法响应人员无法处理高风险证据。

简单的允许列表无法解决这个问题。攻击者可以冒充防御者、攻破已获批准的账户，或通过获授权的组织转发请求。

提供商需要将身份、组织控制、监控和明确范围相结合的分层授权机制。当自动过滤器中断正在进行的调查时，他们还需要提供快速申诉渠道。

这项服务必须以事件响应所需的速度运作。如果审核流程以工作日计算，那么在凭据被盗和横向移动期间，它几乎毫无价值。

透明度同样重要。安全客户应了解哪些内容类别可能触发拒绝、提供商会保留哪些数据，以及紧急例外机制如何运作。

Hugging Face 并未透露最初尝试的商业模型名称。读者不应假定所有托管模型都会作出相同响应。

模型行为可能因提供商、账户、系统提示词、策略版本和网络风险分类而异。报告中的失败代表一类运营问题，而非普遍适用的测试结果。

开放权重模型的开发者面临着不同的压力。该事件印证了市场对高能力本地模型的需求，但不受限制的可用性也可能帮助攻击者。

让 Hugging Face 得以分析恶意证据的同一种可控性，也可能让对手移除安全防护。这种双重用途问题无法仅靠模型许可来解决。

企业安全团队现在面临一个采购问题。他们不仅需要根据基准测试质量评估 AI 系统，还要评估其在真实事件条件下的可用性。

一项实用的就绪度测试应在隔离演练中包含真实的漏洞利用语法。团队应衡量拒绝行为、证据准确性、延迟和数据处理边界。

他们还应测试智能体是否会保留指向原始事件的引用链接。在遏制事件期间，没有证据链接却语气笃定的摘要可能会浪费时间。

对于没有基础设施运行大型本地模型的组织而言，选择更为艰难。他们可以使用较小的模型、协商获取专门的托管访问权限，或聘请具备受控能力的事件响应合作伙伴。

每种选择都需要提前准备。在入侵正在发生时下载一个不熟悉的模型，会在最糟糕的时刻引入软件、供应链和配置风险。

预先批准的本地模型应提前存储、修补并完成测试。除非响应人员授予严格限定的访问权限，否则其环境应与生产环境保持隔离。

团队还需要整理完善的参考资料。架构图、凭证归属记录、部署历史和升级处置流程都应能在调查期间被检索。

这正是常规知识管理支持安全就绪度的方式。它能缩短理解被攻陷身份可以访问哪些系统所需的时间。

Hugging Face 自主 AI 智能体入侵事件也给云和平台团队带来了压力。他们必须假定攻击者能够持续进行侦察并反复尝试操作。

仅靠速率限制无法阻止一个分布在临时环境中、耐心行动的智能体群。检测需要跨身份、服务和时间窗口关联行为。

Hugging Face 表示，其基于 LLM 的分诊机制关联了暴露此次入侵的信号。其他组织在采用相同设计之前，会希望看到更多证据。

关键问题包括误报、运营成本、遗漏的信号，以及遭受遥测数据投毒的可能性。了解检测器的攻击者可能会生成误导性模式。

AI 辅助检测应作为既有控制措施的补充。终端遥测、云审计日志、网络数据、身份监控和不可变存储仍然至关重要。

该公司的响应也促使业界要求制定更清晰的信息披露标准。“AI 驱动的攻击”可以描述模型、脚本和人类操作者的多种组合。

有用的报告应明确哪些阶段涉及模型决策、哪些阶段属于确定性操作，以及调查人员如何区分二者。报告还应说明置信度。

这些细节有助于防御者建立相关控制措施。缺少这些细节时，“智能体式”标签可能更像一种营销分类，而非技术描述。

Hugging Face 提供的技术信息比许多入侵通告更加丰富。然而，在外部专家继续评估期间，仍有一些重要问题悬而未决。

这些问题包括被访问数据的完整范围，以及处理工作节点与内部集群之间的确切攻击链。还包括如何确定智能体归因。

这些问题的答案将决定此事件能否成为一个具有持久价值的安全案例研究。在此之前，最好将这份披露视为一份可信但仍在持续调查中的公司陈述。

Hugging Face 自主 AI 智能体入侵事件后值得关注的事项

三个信号将表明，此事件究竟会改变安全实践，还是仍只是一个与某个平台架构相关的特殊案例。

第一个信号是 Hugging Face 的最终影响范围评估。该公司发布披露信息时，仍在确定合作伙伴或客户数据是否受到影响。

如果最终认定没有外部数据被访问，此事件的影响范围将会缩小。这也将证明内部系统遭到访问后的遏制措施是有效的。

如果确认客户或合作伙伴数据遭到泄露，事件的严重性将会上升。这将要求更仔细地审查哪些凭证被收集，以及访问持续了多长时间。

用户应关注直接通知、更新后的事件说明和更多令牌指导。Hugging Face 目前建议轮换访问令牌并检查近期账户活动。

即使尚未确认公共制品遭到篡改，这项预防措施也是合理的。轮换令牌可以缩短任何被复制密钥的有效使用期限。

第二个信号是独立的技术验证。Hugging Face 表示，外部取证专家正在调查此次入侵及其安全流程。

有价值的后续报告应在不暴露防御细节的情况下，阐明支持智能体式执行这一判断的证据。报告可以描述行为标记、编排模式和置信度。

独立分析可能会强化自主框架驱动了整个攻击活动的结论，也可能会发现人类或脚本发挥了更大的作用。

无论结果如何，都将增进业界的理解。防御者需要的是准确的攻击者行为模型，而不是最具戏剧性的标签。

更完整的报告还应解释恶意数据集如何进入可执行路径。报告应说明哪些权限边界使节点访问和凭证收集成为可能。

第三个信号是托管模型提供商的响应。Hugging Face 表示，它正在分享有关阻碍取证分析的安全控制措施的反馈。

提供商可能会推出经过验证的事件响应访问机制、专用网络安全工作区或更清晰的升级处置流程。这些变化将削弱其所称的护栏不对称问题。

如果提供商没有作出任何实际改变，更多安全团队可能会为紧急情况准备本地模型。这将进一步印证 Hugging Face 的运营建议。

本地就绪不应意味着将一个不受限制的模型直接连接到生产环境。它意味着在一个隔离、留有日志且实施访问控制的响应环境中部署经过审查的模型。

组织应先使用真实的证据测试该环境，再依赖它。他们还应将模型结论与已知的事件时间线进行比较。

此次入侵提供了一个具体的演练场景。一个恶意文件进入处理管道，到达工作节点，获取凭证，并横向移动至多个云系统。

团队可以评估现有控制措施是否能够阻止每一次跳转。随后，他们可以测试 AI 工具能否检测、解释并记录由此产生的证据。

最有价值的问题不是 AI 能否实施攻击或进行防御。这两种结果都取决于周边系统、权限、政策和人为决策。

Hugging Face 自主 AI 智能体入侵事件表明，自动化可以同时压缩事件攻防双方的时间。攻击者可以生成数千次操作，而防御者也可以用相近的速度分析这些操作。

这种平衡仍不稳定。攻击者只需找到一条可行路径，而防御者必须保全证据、保护数据、遵守政策，并避免破坏生产环境。

安全负责人现在应审查一个实际问题：他们批准使用的 AI 工具能否处理真实的恶意证据，同时不会拒绝处理、泄露证据或服从其中的指令？

如果答案未知，下一步就是开展受控演练。测试托管和本地方案，记录它们的局限，并在下一次警报到来前建立人工检查节点。