ExtraHop 的 Agentic SOC Alliance 寻求为 AI 网络防御建立共同规则

ExtraHop 联合 15 家创始成员推出 Agentic SOC Alliance，试图推动一套通用的 AI 防御架构进入 Google News，但围绕自主响应的问题仍未解决。该联盟希望安全代理能够共享上下文、遵循统一控制措施，并在不同 AI 模型之间切换。更艰巨的任务在于证明，相互竞争的供应商能够将这些理念转化为可靠的运营能力。

该联盟成立之际，安全团队正测试能够调查告警、查询系统并建议遏制措施的代理。ExtraHop 认为，传统安全运营中心仍依赖为人工分析师设计的队列式流程。其提出的替代方案是在 AI 模型周围部署持续更新的证据与策略控制机制，使其能够以更快的速度工作。

这一承诺也带来了核心矛盾。供应商希望机器能以机器速度进行调查和响应，而安全负责人仍须在机器出错时承担责任。NIST、MITRE 和 OWASP 的现有工作已描述了重要的 AI 风险。该联盟必须说明，为何另一份行业蓝图能够提升互操作性，而不是增加又一个相互重叠的框架。

Agentic SOC Alliance 提出了一套三层蓝图

这一公告之所以重要，是因为 ExtraHop 试图标准化的是安全代理周边的运行环境，而非某个单一模型或产品。

ExtraHop 于 2026 年 7 月 22 日宣布成立 Agentic SOC Alliance。该倡议由 15 家公司发起，覆盖网络检测、端点安全、调查、自动化和代理开发等领域。

创始成员包括 AuthMind、Armadin、Command Zero、CrowdStrike、Dropzone AI、Exaforce、ExtraHop、Fig、Intezer、Kindo、LangChain、Prophet Security、ReversingLabs、TENEX.AI 和 Torq。与两款深度集成产品之间的合作相比，这些公司的共同参与让该项目覆盖了更广泛的领域。

该联盟的三层提案将自主安全运营中心划分为 Context、Harness 和 Model 三层。每一层都对应代理式网络防御背后的一种不同依赖关系。

Context 是代理用于理解组织情况的证据。ExtraHop 将其描述为一个持续更新的运营知识图谱，涵盖设备、身份、工作负载、连接和行为。

知识图谱是对实体及其关系的结构化表示。在这一设计中，它应帮助代理找到相关证据，而无需从彼此孤立的日志条目中重新拼凑事件。

Harness 负责管理代理的工作方式。它管理编排、状态、记忆、工具访问、权限、审批节点和审计记录。

这一层承担了很大一部分安全责任。模型或许会建议隔离某个端点，但是否能自动执行该操作，则由 Harness 决定。

Model 负责执行分诊、调查和响应所需的推理。该联盟将这一组件视为可替换的，使组织能够在不重建周边控制措施和数据连接的前提下更换模型。

这种分离具有重要的战略意义。模型性能变化很快，而安全集成、访问策略和审计要求通常会持续更久。

因此，ExtraHop 表示 Context 和 Harness 层应保持长期稳定。买方可以采用更新的模型，或使用多个专业化模型，同时保留既有的证据和治理机制。

这是一项架构提案，而非已经完成的标准。创始公告并未提出独立认证计划、已发布的一致性测试，或成员产品在生产环境中的量化成果。

ExtraHop CEO Greg Clark 将该倡议称为起点，并邀请更广泛的行业参与。这一限定很重要，因为该联盟仍需将由供应商主导的设计转化为共享的技术成果。

在简短的 Google News 摘要中，这一区别可能会消失。该联盟已就方向达成一致，但尚未建立获得普遍认可的自主网络防御规则。

Google News 的关注并不意味着它已成为标准

曝光度可以吸引贡献者和企业买方，但在新闻信息流中反复出现并不能验证架构、安全性或互操作性。

最初的 Forbes 文章通过 Google News 的 AI 监管与安全信息流触达读者。这种分发为该提案赋予了政策导向的框架，尽管该联盟仍是一项私营行业倡议。

一项标准通常不止需要一张共享图示。实施者需要精确的接口、统一术语、测试用例、故障定义、版本规则，以及解决分歧的治理流程。

该联盟当前的表述强调需求、最佳实践和实施蓝图。这些成果可能会变得有用，但其价值取决于成员以多大程度公开发布并测试它们。

该项目也与成熟的公共框架并存。NIST 的AI 风险框架围绕衡量、映射、管理和治理风险来组织 AI 治理。

NIST 并未规定一种安全运营架构。相反，它提供了组织可根据自身系统、职责和对伤害的容忍度加以应用的结果导向。

MITRE ATLAS 的用途不同。其代理威胁目录记录针对 AI 赋能系统的对抗性战术与技术，所依据的是演练和真实事件中的观察结果。

OWASP 也关注围绕模型、工具、记忆和外部数据构建的应用风险。这些资源尤其着重于 AI 系统本身可能如何遭受操纵。

Agentic SOC Alliance 则瞄准了另一层问题。它探讨多个安全产品和代理在保卫企业时应如何协作。

这一重点可以补充公共框架。Context、Harness 和 Model 描述系统结构，而 NIST 和 MITRE 则帮助团队识别治理结果和威胁模式。

不过，重叠也带来了实际负担。安全负责人已需要在监管义务、NIST 指导、MITRE ATT&CK、MITRE ATLAS 和供应商专属平台之间映射控制措施。

只有在减少集成工作量时，另一个框架才值得关注。如果成员使用相同标签，却实施了不兼容的权限或证据格式，那么该架构最终只会成为一套营销词汇。

因此，供应商多样性既是该联盟的优势，也是其考验。CrowdStrike 通过端点和云遥测切入 SOC，而 ExtraHop 则强调从网络中提取的上下文。

原生 AI 调查公司对记忆、推理和自动化工作流也带来了不同假设。编排供应商在如何表示审批、操作和回滚方面同样存在差异。

一份可信的蓝图必须在保留这些差异的同时，为它们之间定义边界。它应说明哪些数据跨越各边界流动、谁授权这种流动，以及另一款产品如何验证这些数据。

公开发布的信息尚未在协议层面回答这些问题。买方应将其在 Google News 上的可见度视为关注相关工作的邀请，而非工作已经完成的证明。

真正的较量是自主速度与可追责控制之间的平衡

该联盟必须在不让代理行动脱离人工权威、证据和组织责任的前提下，提高代理速度。

ExtraHop 认为，人们熟悉的“排队—丰富信息—分诊—调查—升级”工作流，是为以人类速度演变的威胁而设计的。该公司表示，攻击者如今可在数分钟内实现侦察、漏洞利用开发和横向移动的自动化。

这些说法反映了真实的运营压力，但仍是该公司为其架构提出的论据之一。该联盟尚未发布对比测量结果，证明其模型优于既有 SOC 工作流。

速度依然重要。响应延迟会给攻击者更多时间窃取凭证、进入更多系统或破坏数据。

安全团队还面临大量告警。代理可能会在分析师打开案件之前，收集相关证据、剔除明显误报、总结攻击路径并提出行动建议。

设想一名受侵害员工的身份连接到一个不熟悉的工作负载。代理可能会将身份事件、端点活动、网络会话、资产归属和威胁情报整合为一项调查。

Context 层将以结构化形式提供这些证据。Model 将对可能的解释进行推理，而 Harness 则控制代理可以调用哪些工具。

这一流程体现了该设计的吸引力。它也说明了，当每个组件都信任前一个组件时，错误决策为何会迅速扩散。

上下文中可能包含过时的资产归属信息或不完整的身份数据。攻击者也可能操纵代理检索到的内容，导致模型遵循误导性指令。

模型可能会对一个薄弱指标赋予过高置信度。Harness 随后可能允许执行遏制措施，因为该操作低于错误配置的审批阈值。

人工分析师也可能犯下类似错误，但自主系统改变了错误发生的速度和规模。一条存在缺陷的规则，可能在审查人员发现这一模式前影响大量调查。

这使受治理的自主性比不受限制的自主性更有用。低影响操作可以自动进行，而具有破坏性或业务关键性的步骤则需要更强的授权。

代理可以无需审批地搜索遥测数据、关联证据并起草案件。禁用身份、隔离生产服务器或删除云资源，则应面临更严格的控制。

该联盟的 Harness 层似乎旨在支持这种区分。然而，一份有用的蓝图必须定义产品如何表达操作风险、身份、范围和审批状态。

它还必须说明代理意见不一致时会发生什么。一种模型可能将某种行为归类为恶意，另一种模型则可能发现这是经授权维护的证据。

组织需要解决这种冲突的策略。它们也需要持久记录，展示每项观察、推断、工具调用、审批和最终操作。

NIST 的框架指出，组织应明确人工与 AI 配置的责任。这一指导支持该联盟的治理目标，但也提高了问责门槛。

机器速度的防御不能成为无法追溯决策的借口。如果响应人员无法解释为何系统中断了一项合法服务，那么最快的系统也并不更安全。

可替换模型依赖可信的上下文

将模型视为可替换组件是合理的，但前提是推理引擎更换后，上下文和控制措施仍能保持一致。

该联盟最具影响力的选择，是将长期价值置于模型之外。这挑战了将安全工作流与单一专有模型紧密绑定的策略。

不同模型在工具使用、指令遵循、上下文处理、延迟和错误模式上存在差异。因此，更新一个组件可能会改变代理对相同证据的解读。

Harness 需要吸收这些差异。它必须以一致的方式呈现工具、约束参数、验证输出，并阻止超出策略范围的操作。

Context 层面临同样艰巨的任务。安全证据来自具有不同模式、时间戳、标识符、保留策略和置信度的产品。

终端工具可能通过一条设备记录识别一台笔记本电脑。网络平台则可能通过不断变化的地址观察到同一台机器，而身份系统会单独跟踪其用户。

知识图谱必须在不掩盖不确定性的前提下协调这些记录。如果它错误地合并了两项资产，智能体可能会围绕错误设备构建一份看似可信的调查。

因此，溯源至关重要。每一项重要事实都应保留其来源、观察时间，以及其映射到某个实体的置信程度等信息。

时效性同样重要。上月记录的设备所有者可能并非当前用户，尤其是在共享环境或频繁重装系统的环境中。

语义细节可以帮助智能体推理，但也可能制造虚假的信心。即使上游连接器提供的数据并不完整，结构化信息依然会显得很有权威性。

联盟成员应定义系统如何表示缺失、有争议和已过期的证据。空白值绝不能被悄然视为否定性发现。

模型层又增加了一层复杂性。安全团队可能会因测试收益、策略变化、许可顾虑或新发现的漏洞而更换模型。

替代模型不应自动继承信任。它需要针对组织的工具、数据、攻击模式和禁止操作进行评估。

Harness 可以保留权限，但仅有权限并不能确保行为等效。两个模型即使在完全相同的访问边界内运行，也可能对模糊指令作出不同解读。

这正是为什么一致性测试必须衡量结果，而不只是连接情况。测试应涵盖提示注入、受污染的上下文、相互冲突的证据、不可用的工具和不完整的遥测数据。

测试还应衡量系统是否能安全停止。无法确认资产身份的智能体应上报不确定性，而不是临时编造一个隔离目标。

MITRE 已扩大 ATLAS 对智能体 AI 和大语言模型威胁的覆盖范围。这些场景为针对联盟三个层面的对抗性测试提供了有用基础。

NIST 还就 agent security inquiry 单独征求意见。该调查特别指出，智能体能够规划并执行影响现实环境的操作。

联盟可以通过将这些风险转化为 SOC 专用的互操作性测试来创造价值。这项工作会比泛泛宣称“机器速度的防御”更有说服力。

供应商合作并不消除供应商激励

供应商联盟可以形成有用的惯例，但买方需要能够防止任何创始成员围绕自身产品优势定义开放性的治理机制。

ExtraHop 提供网络情报，并将结构化实时上下文视为该架构的基础。这一定位自然使蓝图与 ExtraHop 的商业优势相契合。

CrowdStrike 带来终端和云端上下文。其他成员则贡献调查智能体、编排、身份分析、恶意软件情报或开发框架。

如果共享架构将其所属类别视为不可或缺，每个参与方都会从中受益。这并不否定这项工作的价值，但确实形成了买方应当认识到的激励因素。

真正开放的设计应允许非成员实施每一个必需接口。它不应将关键上下文、策略或测试机制保留给联盟控制的产品。

文档也需要一套可访问的变更流程。如果只有创始供应商能够批准定义，该项目仍是一份合作伙伴规范，而不是行业标准。

联盟应公开决策方式、争议记录方式以及组织加入方式。它还应明确技术产物的所有权和许可安排。

独立实施是另一个重要信号。非成员应能够在无需私下工程支持的情况下连接兼容的 Context 提供方、Harness 或 Model。

这将检验联盟对可互换组件的承诺，也会暴露创始供应商共同构建集成时容易被掩盖的隐性假设。

缺少若干主要平台提供商值得注意，尽管这并不自动构成否决理由。企业 SOC 往往依赖 Microsoft、Google Cloud、Palo Alto Networks、Splunk 以及其他大型平台。

这些产品已在塑造遥测格式、身份控制、案件管理和响应工作流。共享架构只有能跨越这些既有环境运行，才会获得影响力。

联盟的治理中也需要安全买方、事件响应人员、审计师和保险机构。供应商并不独自承担错误自主操作所带来的运营后果。

客户参与可以让风险阈值更贴近现实。即便观察到相同的技术指标，金融机构和软件开发商可能会允许不同的操作。

受监管组织必须为审计和调查保留证据。它们的要求能够揭示 Harness 是否记录了足够细节以支持问责。

Fiserv CISO Jason Dewez 在发布公告中支持对实时网络和终端遥测的需求。他的参与为该提案带来了企业实践者的视角。

不过，一位支持该提案的客户声音无法替代广泛验证。联盟需要在拥有不同系统、风险承受能力和法律义务的组织中实施部署。

独立研究人员也应测试该架构的失效模式。公开研究结果将帮助买方区分文档中描述的控制措施与真正能够承受对抗性压力的控制措施。

Forbes 围绕 AI 网络防御规则的表述概括了联盟的雄心。眼前的现实更为有限：供应商提出了一个共同运营模型，并同意对其进行验证。

雄心与证据之间的差距才是故事的核心。这也是评判该倡议应采用的标准。

三个信号将表明蓝图是否有效

公开规范、对抗性互操作测试和由客户控制的部署，将决定该联盟是成为基础设施，还是停留在供应商营销活动层面。

第一个信号是一份详细的公开规范。它应定义 Context、Harness 和 Model 组件之间的接口，包括身份、授权、溯源和错误处理。

该规范应说明工具如何声明能力和风险，还应描述审批状态、审计事件、模型变更和策略执行。

版本管理将很重要。安全团队需要知道，当其他供应商更新软件或数据表示方式后，某个组件是否仍然兼容。

开放文档会强化联盟的主张。仅在合作伙伴之间共享的私有实施指南则会削弱这一主张。

第二个信号是跨多个成员产品的对抗性测试。联盟应公开可重复的评估，覆盖受损上下文、提示注入、过度权限和相互冲突的智能体结论。

测试也应包括日常运营故障。缺失的遥测数据、过期凭据、延迟的连接器和重复的资产记录，即使没有活跃攻击者，也可能使调查偏离正轨。

结果需要可衡量的指标。检测速度很重要，但错误隔离率、缺乏支持的结论、升级质量以及从失败操作中的恢复能力同样重要。

一项有价值的评估应在相同的 Context 和 Harness 条件下比较多种模型选择。这将检验 Model 层是否真正可互换。

它还应替换一个 Context 提供方或编排组件。如果该架构只能与偏好的组合配合使用，其模块化主张就会变得更弱。

第三个信号是由客户控制的生产环境采用。组织应能够设置自己的自主级别、操作策略、证据要求和审批链。

早期部署应明确哪些操作仍仅提供建议，哪些可以自动执行。如果没有这些边界，关于自主运营的泛泛表述几乎说明不了什么。

买方应询问，智能体是否能够隔离终端、禁用身份、修改防火墙、撤销令牌或更改云配置。每项权限都会改变错误的潜在影响。

他们还应询问系统如何处理回滚。阻止一项操作很重要，但在错误操作进入生产环境后，恢复就变得至关重要。

在这些问题得到完整答案之前，Google News 的新闻周期就会转向下一个话题。安全领导者不应将媒体热度视为采购截止期限。

相反，团队可以将该提案映射到当前架构中。他们可以识别证据仍然碎片化的地方、审批造成延迟的地方，以及智能体已拥有实质性权限的地方。

评估智能体系统的组织还需要可搜索的内部政策、事件和技术决策记录。维护良好的工程知识库可以支持审查，但不能替代 SOC 遥测或访问控制。

Agentic SOC Alliance 选择了正确的问题类别。安全智能体需要共享证据、受约束的工具、可互换的推理能力以及可审计的决策。

其下一阶段必须以可验证的产物取代架构性语言。如果成员公开规范、经受住敌对测试并支持独立实施，该倡议将强化其开放性的主张。

如果这些信号始终未能出现，这三个层面将仍是一张有用的示意图，而非可执行的规则。因此，最重要的问题是务实的：安全买方是否会在授予智能体对真实系统的权限之前要求看到证据？