利用代理简化安全调查 | Slack工程博客

在安全事件调查中，获取的知识在逐渐更先进的模型间向上流动。

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

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

开发过程

原型

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

该提示词包含五个部分：

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

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

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

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

解决方案

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

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

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

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

从原型到生产

在查阅文献时，有两篇论文特别影响了我们的思路：

元提示：通过任务无关的脚手架增强语言模型（斯坦福大学，OpenAI）
释放大型语言模型中的涌现认知协同：通过多角色自我协作的任务解决代理（微软研究院）

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

我们选择的设计围绕一个角色（代理）团队以及他们在调查过程中可以执行的任务构建。每个代理/任务对都用一个精确定义的结构化输出建模，我们的应用程序编排模型调用，在每一阶段仅传播恰当的上下文。

调查循环

导演代理提出问题，领域专家代理响应，生成调查结果。评论家代理审查调查结果的质量，并使用最可信的调查结果组装时间线。导演利用高质量的调查结果和时间线来决定如何推进调查。

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

导演代理：调查导演。导演的职责是从头到尾推进调查。导演通过形成一个问题或一组问题来质询专家，这些问题成为专家的提示词。导演使用日志记录工具在调查过程中进行规划和整理。
专家代理：领域专家。每个领域专家都拥有独特的领域知识和数据源。专家的职责是根据导演的问题，从其数据源中生成调查结果。我们团队目前有四名专家：
- 访问：认证、授权和边界服务。
- 云：基础设施、计算、编排和网络。
- 代码：源代码和配置管理分析。
- 威胁：威胁分析和情报数据源。
评论家代理：评论家是一个“元专家”。评论家的职责是使用我们定义的评估标准来评估和量化领域专家所做调查结果的质量。评论家用其自己的分析和每个调查结果的可信度评分来注释专家的发现。评论家的结论会传回给导演，从而形成闭环。评论家与专家组之间这种弱对抗关系有助于减轻幻觉和证据解释的变异性。

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

知识金字塔

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

调查流程

调查过程分为几个阶段。阶段允许我们随着调查的进行改变调查循环的结构。目前，我们有三个阶段，但增加更多阶段很简单。导演角色负责推进阶段。

调查从发现阶段开始。在每一轮调查之后，导演决定是停留在当前阶段还是进入新阶段。

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

服务架构

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

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

示例报告

我们包含了一份经过编辑的调查报告，展示了代理展现新颖涌现行为的潜力。在本案例中，原始警报是针对一个特定命令序列而触发的，我们对其进行分析是因为它可能表明存在入侵迹象。在调查警报的过程中，代理独立地发现了进程祖先链中其他地方一个独立的凭据暴露。

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

下面的文本是该次调查报告摘要的轻微编辑版本。

调查报告：监控工作流中的凭据暴露 [需升级] 摘要：在调查 [命令序列] 时，调查发现了进程祖先链中其他地方的凭据暴露。

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

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

这一结果值得注意的地方在于，专家并未在其发现中提出凭据暴露问题；评论家是在对专家工作进行元分析时注意到了这一点。随后，导演选择将调查重点转向这个问题。在报告中，导演强调了需要缓解这个安全问题，并跟进专家未能正确识别风险的问题。我们将凭据暴露问题提交给了所属服务团队进行解决。

结论

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

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

在多角色调查期间保持对齐和定位
使用制品作为调查参与者之间的沟通渠道
人在回路：安全调查中的人/代理协作

致谢

我们想对所有为这段旅程做出贡献的人们表示衷心的感谢：Chris Smith、Abhi Rathod、Dave Russell、Nate Reeves。