作者来自 Elastic Marcus Jeffes如何从架构层面为自主安全 agents 构建治理机制。行业在能力方面发展迅速。如今agents 可以对告警进行分流、调查终端、创建检测规则、丰富指标甚至能够执行我们作为安全运营人员可以执行的大多数操作。架构模式正在逐渐成熟模型也在不断发展但治理并没有跟上。持续证明你的 agents 在压力环境下、大规模运行时始终做正确事情的能力目前仍然基本没有得到解决。如今大多数将 agents 部署到生产环境的团队默认采用分级自主模式低风险操作自动运行中风险操作需要监督高风险操作需要人工批准。这告诉你 agent 可以做什么但完全没有告诉你它是否做得好。一个将每个告警都分类为误报的分流 agent 永远不会触发治理控制因为它的运行仍然处于被批准的权限等级内。与此同时法规并没有等待。ISO 42001、DORA、NIS2 和欧盟 AI 法案都逐渐形成一个共同要求你必须证明你的 AI 系统按照预期工作人类保持有意义的监督并且你能够解释决策是如何产生的。目前针对自主安全 agents 的具体评估标准还不存在但方向已经非常明确。现在构建治理基础设施的组织将会是在标准到来时做好准备的组织。将推理作为基础设施目前agent 如何对安全调查进行推理通常被封装在驱动它的大型语言模型LLM中。除此之外概率模型往往无法保证每次都产生一致的输出。更换模型甚至只是发生相同的安全事件推理模式都会发生变化。相同的告警在相同上下文下可能产生不同的升级决策。围绕某个模型特性建立的治理框架在模型发生变化时或者模型由于我们无法控制的权重变化而偏离时可能会变得不再可靠。推理是决定 agent 行为的核心因素。它决定告警是否应该升级或关闭是否需要调查横向移动或者是否应该隔离主机。当这种推理被封装在模型中时你实际上依赖模型的通用智能来弥补缺少明确方法论的问题。我们需要将推理提取出来形成调查工作流中的显式层。这本身也具有多个适用层级。它可能表现为一组指令或知识库。我们可以在运行时调用一个内置升级逻辑的工作流。我们可以根据证据评估标准和/或假设生成模式改变决策。当我们在多个层面定义推理后模型的角色就会降低为执行任务。一个定义良好的方法论由更小、更便宜的模型执行会超过一个针对特定环境、依靠猜测方法论的前沿模型因为这种推理建立在运营上下文之上而不是模型训练数据之上从而让事件处理更快、更便宜。这对于治理来说有三个重要原因。1治理需要可预测性渐进式信任假设今天被测量的系统与明天运行的系统是同一个系统。如果更换模型会改变推理模式那么在旧模型下积累的信任证据无法迁移而每次模型变化都会让系统重新回到最高监督状态。供应商集中风险会进一步放大这个问题。如果你因为价格、弃用政策或监管要求需要切换供应商你会同时失去模型和信任证据。2评估需要一致性如果方法论的一致性仅仅来自当前运行的模型那么你无法真正评估自己的运营能力因为你实际上只能评估当前模型。你的消融研究、基准测试套件和质量指标都会变成模型相关而不是系统相关每次模型变化都需要从头重新评估。3合规需要可解释性当监管机构询问“你的 agent 如何决定升级一次调查”时答案必须建立在有文档记录的流程之上。如果答案最终变成“询问模型提供商”你就无法证明自己拥有控制能力。监管机构关心的是你是否能够向他们展示决策是如何产生的。4 层分离解决这个问题的架构可以分为四层。1SkillsSkills 定义 agent 在分流、丰富、取证和检测工程方面能够执行的操作 —— 每一个 skill 都是由指令、工具和领域知识组成的可组合单元用于定义 agent 的能力。2推理这一层定义 agent 如何思考包括调查方法论、升级逻辑、证据评估标准以及假设生成模式。这一层是显式的、可测试的并且独立于执行它的模型。当一个分流决策遵循明确的方法论时该方法论可以进行版本管理可以通过基准测试套件进行测试并且可以通过与其他重要变更相同的治理框架进行更新。当方法论承担复杂性时模型就不需要承担这些复杂性。这使得我们能够在具有成本效益的模型上运行能力强大且受治理的 agents而不是默认每个任务都使用最昂贵的前沿模型。3模型虽然 LLM 会执行自身内置的推理方式但不同模型之间的推理模式并不相同。Claude、Gemini、ChatGPT 或开源模型的工作方式都会存在轻微甚至完全不同的差异结果会根据模型训练方式以及供应商设置的防护机制而产生偏差。4上下文任何调查的深度都受到平台将环境上下文引入 agent 解决方案能力的限制。记录每个 agent 决策、支撑该决策的证据以及决策是否正确是实现持续测量和基准测试的关键。这种分离方式直接解决了这三个问题信任证据绑定到推理方法论而不是模型。当你更换模型时信任也会迁移因为方法论没有改变。你只需要验证新模型是否能够正确执行相同的推理模式并验证其性能。基准测试套件用于测试推理方法论但模型变化需要进行针对性的检查而评估必须成为我们运营流程中持续存在的一部分例如新模型是否以相同标准遵循该方法论。当监管机构询问 agent 如何决定升级调查时你可以指向具有版本管理、文档记录和可测试结果的推理层。当他们询问模型风险时你可以指向分离层其中模型只是可替换的基础设施。当他们询问集中化风险时你可以证明推理模式可以跨供应商迁移。渐进式信任作为运营模型渐进式信任的理念是从最高级别的监督开始即每一个重要操作都需要经过人工审核。随着不断积累 agent 建议可靠性的证据监督程度会逐步降低。一个已经经过数百次批准 —— 并且每次建议都在事件后复盘中得到验证 —— 的 agent与一个上周刚部署的 agent需要接受不同级别的监督。这只有在四层分离将信任与模型解耦之后才成为可能。证据绑定到推理方法论上因此它可以跨模型变化持续存在并且随着时间积累而不是每次更新都重新开始。反过来的情况同样重要。如果 agent 的性能因为模型漂移、数据分布变化或新的攻击模式而下降我们需要指标来发现这种情况。当观察到性能下降时响应应该是收紧监督将操作移回更高审批要求降低自动批准阈值并增加证据要求。如果数据证明有必要经过数月积累的信任可以在几秒钟内被撤销。但衡量信任需要具备这样的能力不仅观察 agent 做了什么还要观察它是如何进行推理并完成这个操作的。评估作为指标和证据Huntress 首席安全研究员 Matt Kiely 认为需要衡量渐进式信任而渐进式信任需要证据。这些证据来自四个维度上的持续评估。1分类准确性Agent 是否得到了正确答案这通过精确率它的正向分类中有多少是正确的和召回率实际正向结果中它捕获了多少来衡量。这种测量是必要的但是仅靠这一点无法说明可靠性。通过幻觉式推理得出的正确结论并不是一个可靠的 agent。2规划质量agent 是否考虑了多个假设例如在四分钟内从两个相距很远的位置发生可疑登录它是否考虑了不可能旅行、令牌窃取和 VPN 使用还是说它只关注第一个假设而陷入了单一思路3检索质量agent 是否找到了正确的证据如果知识库包含相关的历史事件而 agent 从未检索这些信息那么它是否是在基于不完整的信息运行4基础依据质量Agent 的推理是否由它找到的证据支持它是否声称“这个 IP 与 APT28 基础设施相关”是因为知识库条目这样说明还是因为它产生了这个关联的幻觉即使一个 agent 的结论碰巧正确如果它具有很高的不受支持声明比例也会非常危险。这四个维度共同构成了渐进式信任所需要的证据。分类准确性告诉你是否应该信任输出结果。而规划、检索和基础依据质量告诉你是否应该信任整个过程。消融测试让这一点变得具体。构建一个具有已知真实结果的基准测试套件运行 agent并捕获完整执行轨迹 —— 每一次工具调用、每一次知识库查询以及每一个推理步骤 —— 然后系统性地改变配置运行仅查看原始遥测数据、不使用知识库、工具或多步骤推理的基础版本。模型是否可以仅根据信号进行分类运行不使用知识库的版本以隔离检索增强上下文是否真正改善了结果。运行不使用调查工具的版本以确定工具使用是否在模型从遥测数据和检索到的知识中推断之外增加了真正的价值。运行启用所有功能的完整 agent作为对比基准。不同配置之间的差异会揭示哪些组件真正促进了质量提升。如果移除知识库后结果没有变化那么要么知识库没有价值要么 agent 没有正确使用它。这些发现会反馈到系统改进过程中。监控监控者当 AI agents 在安全领域投入运营后你不仅需要它们监控和响应安全事件还需要能够监控和响应基于 agent 的决策。这正是我们需要转变方向的地方将 agent 的可观测性直接与我们的安全能力结合起来。传统上作为安全专业人员我们关注的是发生了哪些操作现在我们必须转向关注这些操作为什么会发生agent 考虑了哪些证据它探索并放弃了哪些假设哪些推理导致了这个操作它是否在两个无关事件之间产生了错误关联它是否跳过了关键调查步骤它的置信度分数是否反映了真实信号还是它自己生成的这种语义差距就是遥测以及对这些遥测数据的评估。已经构建系统来评估整个环境中 agent 行为的一家公司是 Uber他们拥有自己的 Agentic Detection and ResponseADR系统。该团队目前已经将这一系统部署到 7,000 多个主机上他们关注的是我们通常在安全领域关注的信号例如文件写入和 API 调用但他们进一步扩展将 agent 推理、提示词以及导致执行的意图链也纳入其中。对于安全 agents 来说具体的遥测需求不同于软件工程领域的 agents但原则完全相同因为我们希望捕获完整推理链它摄取了哪些告警数据检索了哪些知识库条目生成了哪些假设如何权衡证据以及什么因素导致了分类决策。证据agent 提出的每一个声明都应该能够追溯到来源。决策边界agent 的推理在哪里改变了决策它考虑了哪些替代路径当它选择升级而不是关闭时是什么证据推动了这个决定真负例agent 没有执行什么操作与它执行了什么操作同样重要。Uber 的 ADR 系统 展示了一种在企业规模上实现这一目标的方法它将高保真 agent 遥测采集与双层检测结合起来。Sensor 将重建后的 agent 会话转发到后端进行分析并指出 Elasticsearch 是支撑该系统的遥测存储平台。该论文 证明在企业规模上解决遥测差距不仅可行而且是必要的。衡量真正的监督人机协同已经成为回答 “我们如何让 AI 保持责任”这一问题的默认答案。但它很少像其他安全措施一样被作为一种控制机制进行测试。如果 AI 在 100 次中有 99 次都是正确的为什么还要再次批准人类只是认可 agent 的输出而不是独立进行评估于是人机协同失效。Anthropic 最近发布了来自 Claude Code 的工程遥测数据显示用户批准了 93% 的权限请求而经验丰富的用户自动批准的比例大约是新用户的两倍。用户看到的批准请求越多他们对每一个请求投入的注意力就越少。Anthropic 自己的结论是监督机制正在退化而不是提供保护因此他们不得不彻底重新设计批准模型。如果构建 agent 的团队无法对自己的产品维持有意义的人类监督那么认为 SOC 分析师能够在更高工作量和更高影响后果下做得更好是不可信的。人类无法跟上下一代攻击带来的数量级增长。我们需要一个监控层用来衡量批准是否反映了真正的判断。批准延迟是最简单的信号如果每次批准无论复杂程度都只花三秒钟那么人类实际上并没有参与其中。除了延迟之外人类多久会不同意 agent 的判断审核人员是否扩展查看了证据部分还是只阅读了摘要快速批准的操作是否比经过仔细审核的操作产生更差的结果针对批准疲劳进行设计需要让阻力程度与后果风险相匹配。使用确认指标记录决策被撤销的情况强制执行审核检查清单随机进行事后审计比较审核人员的决策质量和 agent 的建议质量对破坏性操作建立二次批准流程人类角色人类角色从操作执行者转变为监督者再转变为治理者的变化已经到来并且已经在一些使用场景的生产运营中实现。最有效的实践者不会是某一个领域中最深的专家而是那些既理解如何编写 agents又充分理解流程、运营以及不同领域之间边界的人从而能够制定方法论并治理跨越所有这些领域运行的 agents。这需要一种新的学科治理工程。它是这样一群实践者的交叉领域他们理解 agents 能做什么可能出现什么问题如何衡量这些问题以及如何构建能够在故障变成事件之前捕获它们的基础设施。完全自主的 SOC 是一个有价值的北极星目标但目前真实状态是一种连续谱。大多数组织处于这样的范围之间从可以访问日志的聊天机器人到 agents 执行轻量级自主操作的工作流。每增加一种能力就会引入新的治理需求、评估标准以及新的风险领域。未来领先的组织将是那些能够在对抗性压力下持续证明其 agents 值得信任的组织并且能够提供同时满足安全团队和监管机构要求的证据。信任需要证据。证据需要测量。而测量需要具备观察 AI 基础设施的能力。监管法规ISO 42001、DORA、NIS2 和欧盟 AI 法案正在趋向同一个期望但目前都还没有定义如何针对自主 agents 满足这一要求。ISO 42001 要求进行性能监控但没有定义最低精确率阈值。DORA 要求进行运营弹性测试但没有针对概率系统指定评估方法。NIS2 将责任归于管理机构但没有解决这样的问题当决策来自没有人工授权的推理链时这种责任应该如何发挥作用。欧盟 AI 法案要求对高风险系统进行符合性评估但针对自主安全 agents 的评估标准目前还不存在。差距在于 AI 基础设施测量和监控。现在构建渐进式信任框架、持续监控以及评估流水线的团队将能够满足监管机构跟上进度后形成的具体要求。一个需要特别关注的监管压力是供应商集中风险。根据 DORA 第 28 至 30 条金融实体必须评估其 ICT 供应商之间的集中风险维护审计权利并为支持关键或重要功能的任何供应商制定可信的退出策略。如果该供应商随后根据第 31 条被指定为关键第三方供应商那么 ESA 级别的监督会带来进一步审查。Skills、推理、模型和上下文这四层分离直接解决了这个问题它使推理方法论可以跨供应商迁移使信任证据能够随着方法论一起迁移并确保模型变化不会破坏信任连续性。Elastic Security 为此而构建这里描述的治理框架需要一个平台同时具备以下多个能力大规模摄取并规范化 agent 遥测数据以具有成本效益的方式存储这些数据按照 agents 的运行速度进行查询实时针对每个决策运行自动化质量检查Elastic Security 正是为此构建的。Elasticsearch logsdb 索引模式显著降低了高容量安全遥测数据的存储成本这些数据与 agent 追踪数据并存例如agents 调查所依据的终端、网络和云数据。当治理意味着为了审计而保留整个环境中每一个 agent 操作时这一点非常重要。Elastic Common SchemaECS为这些遥测数据提供了模式基础并且可以扩展以结构化 agent 特定数据、推理链、证据引用和决策记录使其能够与 agents 操作所基于的安全数据一起进行查询。机器学习能力和检测规则随后不仅可以用于检测网络中的威胁还可以用于检测 agents 自身的问题例如发现分类准确性的漂移、异常推理模式或基础依据质量下降并在其成为事件之前发现这些问题。Elastic 还具有独特优势因为这些并不是独立的产品。理解 agents 已经执行了什么操作所需要的搜索能力、监控 agents 如何推理所需要的可观测性能力以及检测问题发生时所需要的安全能力都位于同一个平台上。这种融合使受治理的 agent 运营成为可能。我们正在积极开发专门用于 agent 可观测性和治理的能力并欢迎正在解决相同问题的团队与我们交流。如果你正在构建、部署或治理自主安全 agents请联系 Elastic Security。本文中描述的任何功能或特性的发布以及发布时间安排仍完全由 Elastic 自行决定。目前尚未提供的任何功能或特性可能不会按计划交付甚至可能不会交付。在本文中我们可能使用或引用了由各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具并且我们不对其内容、运行或使用承担任何责任或义务也不对你使用这些工具可能产生的任何损失或损害承担责任。使用 AI 工具处理个人、敏感或机密信息时请谨慎操作。你提交的任何数据都可能被用于 AI 训练或其他用途。无法保证你提供的信息会被安全或保密地保存。在使用任何生成式 AI 工具之前你应该了解其隐私实践和使用条款。Elastic、Elasticsearch 以及相关标识是 elasticsearch B.V. 在美国和其他国家/地区的商标、标识或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标识或注册商标。原文The future of governing AI agents | Elastic Blog