利用智能体简化安全调查

Slack的安全工程团队负责保护Slack的核心基础设施和服务。我们的安全事件摄入管道每天处理来自各种数据源的数十亿个事件。审查我们的安全检测系统产生的警报是我们在值班期间的主要职责。

我们将向您展示我们如何利用AI智能体来优化工作效率并加强Slack的安全防御。这篇文章是一个系列的第一篇，将解析我们做出的一些设计选择以及在此过程中学到的许多东西。

开发过程

原型

在2025年5月底，我们有了一个后来发展成为我们服务的初步原型。最初，该服务基本上只是一个300字的提示词。

该提示词包含五个部分：

• 定位：“你是一名调查安全警报的安全分析师 […]”
• 清单：“你可以访问以下数据源： […]”
• 方法论：“你的调查应遵循以下步骤： […]”
• 格式：“生成调查的markdown报告： […]”
• 分类：“从以下选项中选择响应分类： […]”

我们实现了一个简单的“stdio”模式MCP服务器，通过工具调用界面安全地暴露我们数据源的一个子集。我们将一个编码智能体CLI重新用作我们原型的执行环境。

我们原型实现的性能非常不稳定：有时它会产生出色、有洞察力的结果，具有跨不同数据源交叉引用证据的惊人能力。然而，有时它会迅速跳到一个方便或虚假的结论，而没有充分质疑自己的方法。为了让工具有用，我们需要一致的性能。我们需要对调查过程有更大的控制力。

我们花了一些时间试图改进我们的提示词，强调需要质疑假设，从多个来源验证数据，并利用完整的数据源集。虽然这种方法确实取得了一些成功，但最终提示词只是指导方针；它们并不是实现细粒度控制的有效方法。

解决方案

我们的解决方案是将原型提示词中描述的复杂调查过程分解为一系列模型调用序列，每个调用都有一个单一、定义明确的目的和输出结构。这些简单的任务由我们的应用程序链接在一起。

每个任务都被赋予了一个结构化的输出格式。结构化输出是一个功能，可用于将模型限制在使用由JSON模式定义的特定输出格式。该模式应用于模型调用的最后一个输出。使用结构化输出并非“免费”；如果输出格式对模型来说太复杂，执行可能会失败。结构化输出也容易出现常见的“作弊”和“幻觉”问题。

在我们最初的原型中，我们包含了“质疑你的证据”的指导，但效果不一。采用结构化输出方法后，该指导已成为我们调查流程中一个独立的任务，行为更加可预测。

这种方法使我们在调查过程的每一步都获得了更精确的控制。

从原型到生产

在查阅文献时，有两篇论文尤其影响了我们的思考：

• Meta-Prompting: Enhancing Language Models with Task-Agnostic Scaffolding (斯坦福大学， OpenAI)
• Unleashing the Emergent Cognitive Synergy in Large Language Models: A Task-Solving Agent through Multi-Persona Self-Collaboration (微软研究院)

这些论文描述了在单一模型调用背景下引入多个角色的提示技术。使用定义的角色来模拟调查的想法很有趣，但为了保持控制，我们需要将我们的角色表示为独立的模型调用。安全桌面演练，以及我们如何将其约定适应到我们的应用程序中，也是设计过程中的一个主要灵感来源。

我们选择的设计围绕一组角色（智能体）以及它们在调查过程中可以执行的任务展开。每个智能体/任务对都用一个精心定义的结构化输出进行建模，我们的应用程序编排模型调用，在每个阶段只传播恰如其分的上下文。

调查循环

指挥智能体提出问题，领域专家智能体进行回应，生成发现。评审智能体审查发现的质量，并使用最可信的发现组装时间线。指挥员利用高质量的发现和时间线来决定如何推进调查。

我们的设计定义了三个角色类别：

• 指挥智能体：调查指挥员。指挥员的职责是从始至终推进调查。指挥员通过形成一个问题或一组问题来询问专家，这些问题成为专家的提示词。指挥员使用日志记录工具来规划和组织调查的进展。
• 专家智能体：领域专家。每个领域专家都拥有独特的领域知识和数据源。专家的职责是根据指挥员的问题，从他们的数据源中产生发现。我们目前团队中有四位专家：
  • 访问：身份验证、授权和边界服务。
  • 云：基础设施、计算、编排和网络。
  • 代码：源代码和配置管理的分析。
  • 威胁：威胁分析和情报数据源。
• 评审智能体：“元专家”。评审员的职责是使用我们定义的评估标准来评估和量化领域专家所作发现的质量。评审员用自己的分析和对每个发现的可信度评分来注释专家的发现。评审员的结论会传回给指挥员，形成闭环。评审员与专家组之间微弱的对抗关系有助于减轻幻觉和证据解释的变异性。

由于每个智能体/任务对都是一个独立的模型调用，我们可以改变所有输入，包括模型版本、输出格式、提示词、指令和工具。我们利用此能力的众多方式之一是创建一个“知识金字塔”。

知识金字塔

在知识金字塔的底部，领域专家通过查询复杂的数据源生成调查发现，这需要进行多次工具调用。分析返回的数据可能需要非常多的令牌。接下来，评审员的审查从该集合中识别出最有趣的发现。在审查过程中，评审员检查专家的主张以及用于支持这些主张的工具调用和工具结果，这也会产生大量的令牌开销。评审员完成审查后，它会组装一个最新的调查时间线，将正在进行的调查时间线和新收集的发现整合成一个连贯的叙述。然后，这个仅包含最可信发现的浓缩时间线被传回给指挥员。这种设计使我们能够战略性地为专家、评审员和指挥员功能分别使用低成本、中等成本和高成本的模型。

调查流程

调查过程被分成几个阶段。阶段允许我们随着调查的进行来改变调查循环的结构。目前，我们有三个阶段，但可以很容易地添加更多阶段。指挥角色负责推进阶段。

调查从发现阶段开始。每轮调查后，指挥员决定是停留在当前阶段还是进入新阶段。

• 发现：每次调查的第一阶段。发现阶段的目标是确保检查每个可用的数据源。指挥员审查调查状态，并生成一个广播给整个专家团队的问题。
• 指挥决策：一个“元阶段”，指挥员决定是进入下一个调查阶段还是继续当前阶段。该任务的提示词包含何时推进到每个阶段的建议。
• 追踪：一旦发现阶段明确了哪些专家能够产生相关的发现，指挥员就将调查过渡到追踪阶段。在追踪阶段，指挥员选择特定的专家进行询问。我们还可以灵活地按阶段改变模型调用参数，允许我们使用不同的模型或增加的令牌预算。
• 总结：当收集到足够的信息来生成最终报告时，指挥员将调查过渡到总结阶段。

服务架构

我们的原型使用编码智能体CLI作为执行框架，但这并不适合实际实现。我们需要一个界面，让我们能够实时观察正在进行的调查、查看和分享过去的调查，以及启动临时调查。至关重要的是，我们需要一种将系统集成到我们现有技术栈中的方法，允许我们现有的检测工具触发调查。我们创建的服务架构完成了所有这些事情，并且相当简单。

• 中心：中心提供服务API和持久存储的接口。除了通常的类CRUD API外，中心还提供一个指标端点，以便我们可以可视化系统活动、令牌使用情况和管理成本。
• 工作器：调查工作器从API获取排队的调查任务。调查产生一个事件流，该事件流通过API流回中心。可以根据需要扩展工作器以提高吞吐量。
• 仪表板：仪表板供员工与服务交互。可以实时观察正在进行的调查，消费来自中心的事件流。此外，仪表板提供了管理工具，让我们可以查看每个模型调用的详细信息。此功能在调试系统时非常宝贵。

示例报告

我们包含了一份经过编辑的调查报告，展示了智能体表现出新颖涌现行为的潜力。在这种情况下，原始警报是针对一个特定的命令序列而触发的，我们对其进行分析是因为它可能是入侵的指标。在调查警报的过程中，智能体独立地发现在进程祖先链中的其他地方存在单独的凭据暴露。

高亮的叶子进程触发了调查，但智能体追踪了进程层次结构，并在一个祖先进程中发现了不同的问题。

以下文本是此调查报告摘要的略微编辑版本。

调查报告：监控工作流中的凭据暴露 [需升级处理]

摘要：在调查[命令序列]时，调查发现了进程祖先链中其他地方的凭据暴露。

分析 调查确认，在[时间戳]执行的命令是使用[诊断工具]的合法监控工作流的一部分。进程祖先显示了预期的执行链。然而，识别出了关键的安全问题：

• 凭据暴露：一个凭据在祖先链中的进程命令行参数中暴露，造成了重大的安全风险。
• 专家与评审员的矛盾：专家错误地评估凭据处理是安全的，而评审员正确地识别了暴露的凭据，这表明分析中存在需要注意的盲点。

这个结果值得注意的是，专家在其发现中没有提出凭据暴露；评审员在对其工作进行元分析时注意到了这一点。然后指挥员选择将调查重点转向此问题。在报告中，指挥员强调了既需要缓解此安全问题，也需要跟进专家未能正确识别风险的情况。我们将凭据暴露问题转交给拥有该服务的团队来解决。

结论

我们使用AI智能体简化安全调查的旅程仍处于早期阶段，但我们已开始看到切实的收益。我们基于网络的仪表板允许我们实时启动和观察调查，调查产生交互式、可验证的报告，显示证据是如何收集、解释和判断的。在值班期间，我们正在转向监督调查团队，而不是做收集证据的繁琐工作。与静态检测规则不同，我们的智能体经常进行自发且非提示的发现，正如我们在示例报告中所展示的那样。我们已经多次看到这种情况发生，从突出显示IAM策略中的弱点，到识别有问题的代码等等。

还有很多内容要谈。我们期待在未来的博客文章中分享更多关于我们系统如何工作的细节。作为本系列未来内容的一些预览：

• 在多角色调查中保持方向和定位
• 使用工件作为调查参与者之间的沟通渠道
• 人在环路中：安全调查中的人/智能体协作

致谢

我们想向所有为这段旅程做出贡献的人们表示衷心的感谢：

• Chris Smith
• Abhi Rathod
• Dave Russell
• Nate Reeves