企业官网建设流程全解析

作者：来自 Elastic Marcus Jeffes

如何从架构层面为自主安全 agents 构建治理机制。

行业在能力方面发展迅速。如今，agents 可以对告警进行分流、调查终端、创建检测规则、丰富指标，甚至能够执行我们作为安全运营人员可以执行的大多数操作。架构模式正在逐渐成熟，模型也在不断发展，但治理并没有跟上。持续证明你的 agents 在压力环境下、大规模运行时始终做正确事情的能力，目前仍然基本没有得到解决。

如今，大多数将 agents 部署到生产环境的团队，默认采用分级自主模式：低风险操作自动运行，中风险操作需要监督，高风险操作需要人工批准。这告诉你 agent 可以做什么，但完全没有告诉你它是否做得好。一个将每个告警都分类为误报的分流 agent 永远不会触发治理控制，因为它的运行仍然处于被批准的权限等级内。

与此同时，法规并没有等待。ISO 42001、DORA、NIS2 和欧盟 AI 法案都逐渐形成一个共同要求：你必须证明你的 AI 系统按照预期工作，人类保持有意义的监督，并且你能够解释决策是如何产生的。目前，针对自主安全 agents 的具体评估标准还不存在，但方向已经非常明确。现在构建治理基础设施的组织，将会是在标准到来时做好准备的组织。

将推理作为基础设施

目前，agent 如何对安全调查进行推理，通常被封装在驱动它的大型语言模型（LLM）中。除此之外，概率模型往往无法保证每次都产生一致的输出。更换模型，甚至只是发生相同的安全事件，推理模式都会发生变化。相同的告警，在相同上下文下，可能产生不同的升级决策。围绕某个模型特性建立的治理框架，在模型发生变化时，或者模型由于我们无法控制的权重变化而偏离时，可能会变得不再可靠。

推理是决定 agent 行为的核心因素。它决定告警是否应该升级或关闭，是否需要调查横向移动，或者是否应该隔离主机。当这种推理被封装在模型中时，你实际上依赖模型的通用智能来弥补缺少明确方法论的问题。我们需要将推理提取出来，形成调查工作流中的显式层。

这本身也具有多个适用层级。它可能表现为一组指令或知识库。我们可以在运行时调用一个内置升级逻辑的工作流。我们可以根据证据评估标准和/或假设生成模式改变决策。当我们在多个层面定义推理后，模型的角色就会降低为执行任务。

一个定义良好的方法论，由更小、更便宜的模型执行，会超过一个针对特定环境、依靠猜测方法论的前沿模型，因为这种推理建立在运营上下文之上，而不是模型训练数据之上，从而让事件处理更快、更便宜。

这对于治理来说有三个重要原因。

1）治理需要可预测性

渐进式信任假设今天被测量的系统与明天运行的系统是同一个系统。如果更换模型会改变推理模式，那么在旧模型下积累的信任证据无法迁移，而每次模型变化都会让系统重新回到最高监督状态。供应商集中风险会进一步放大这个问题。如果你因为价格、弃用政策或监管要求需要切换供应商，你会同时失去模型和信任证据。

2）评估需要一致性

如果方法论的一致性仅仅来自当前运行的模型，那么你无法真正评估自己的运营能力，因为你实际上只能评估当前模型。你的消融研究、基准测试套件和质量指标都会变成模型相关，而不是系统相关，每次模型变化都需要从头重新评估。

3）合规需要可解释性

当监管机构询问“你的 agent 如何决定升级一次调查？”时，答案必须建立在有文档记录的流程之上。如果答案最终变成“询问模型提供商”，你就无法证明自己拥有控制能力。监管机构关心的是你是否能够向他们展示决策是如何产生的。

4 层分离

解决这个问题的架构可以分为四层。

1）Skills

Skills 定义 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 Response（ADR）系统。该团队目前已经将这一系统部署到 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 Schema（ECS）为这些遥测数据提供了模式基础，并且可以扩展以结构化 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