8.0
热点
AI SCORE
编程提效2026-07-27 08:00
受规约团队必知：AI Agent 审计可追踪性设计
Sourcegraph Blog#Agent#合规审计
Editor brief · 编辑速览
讲解如何为 AI Agent 建立完整的上下文审计链，证明其访问过的代码文件。对金融、医疗等受规约行业的开发团队有高度实用价值。
讲解如何为 AI Agent 建立完整的上下文审计链，证明其访问过的代码文件。对金融、医疗等受规约行业的开发团队有高度实用价值。
受规管的工程团队必须证明一个 AI agent 在发布变更前读取了哪些文件。受限检索如何将 agent 上下文转变为审计线索。
对于 CISO 或 CTO 来说，阻碍企业 AI 采用的众多问题之一并不是 agent 是否能写代码。而是 agent 是否查看了正确的内容来做出正确的改变，以及你能否事后证明这一点。仅仅有一份干净的审计线索还不够：一个 agent 可以完美地记录其推理过程，但仍然可能只是修补症状而不是漏洞。重要的是它在行动之前拥有正确的上下文，以及你能够验证它确实拥有了。
这种区别正是许多管理层对话现在关注的地方。我们与银行、医疗和大型软件组织的工程和安全负责人交谈，对 agent 开发的犹豫很少归结为模型能力。我们被告知的是，一切都归结为证明。当审计员测试你的变更管理控制时，一个异常不是指某个文件看起来不对；而是指流程本身崩溃了，一项变更在没有承诺的审查、批准或测试的情况下发布了。
在审计中，两个基础管理陈述——准确性和完整性——决定了你是否能依赖证据，它们通过对背后流程的压力测试来验证。对于 AI agent，这个过程就是检索。一份透明的记录，明确说明 agent 读取了哪些文件以及为什么，让审计员可以对 agent 的逻辑进行逆向工程，并确认两个陈述：agent 基于完整的需求集合进行了操作，仅使用了相关且授权的代码上下文。
当人类工程师发布一项变更时，Pull Request（PR）记录通常就足够了：批准、审查意见、CI 检查。当之后有疑问时，可以有一位工程师解释他们修改了什么以及为什么。没有人期望看到一个人阅读的每个文件的列表。在 SOC 2 审查中，审计员可能会拉取单个 PR 来确认承诺的扫描和批准确实运行了，而更深入的文件级审查通常被保留用于高风险的工件，如应用于客户环境的 Terraform。
当"工程师"是一个 agent 时，差距就出现了。PR 仍然显示了 diff 和批准，但没有人可以解释为什么变更是这样做的。当 agent 修改身份验证流程、数据处理例程或具有已知 CVE 的依赖关系时，如果没有被捕获，告知变更的上下文会在会话结束的一刻消失。对于今天的大多数团队来说，重构它意味着大量的手工工作。这个缺失的记录就是 agent provenance：agent 在改变任何内容之前读取了哪些文件以及为什么的证据。这个差距，比任何模型限制都更能阻止 AI 在受规管环境中的扩展。
能力从来都不是难点
早期的代码助手是在你打开的文件顶部的自动完成。它们可以呈现可用的函数及其参数，填充样板代码，但它们的视图仅限于当前文件和一个较小的上下文窗口；其他一切都来自静态训练数据。它们对你更广泛的代码库没有感知，并且严格地与开发者并行工作。解决办法是给模型提供对存储库、工具和文档的实时访问，这正是 Model Context Protocol（MCP）和一波 agent 工具化所正式确立的。这使 agent 编码成为可能。它也使一件事非常清楚：让 agent 行动变得越来越容易。让它负责任地行动要困难得多。
一个广泛检索、拉入整个存储库、猜测上下文、当找不到所需内容时产生幻觉的 agent，产生的输出没有人能为其担保。当该输出是一个安全关键的变更时，"模型决定了"不是一个能通过合规审查的答案。能力是存在的；问题是工程师，最终是 CISO 和 CTO，仍然必须验证 agent 产生的输出的准确性和完整性，而他们在没有看到 agent 使用的上下文的情况下无法做到这一点。使其可见，两件事随之而来：审阅者可以根据查阅的确切来源检查输出，团队可以设置护栏，使 agent 始终遵循相同的检索模式。没有更多的意外在审计时首次出现。
受限检索是一种控制
工程社区一直在聚合到一个模式：首先确定问题的范围，然后推理。狭窄、有意的检索能保持 token 成本低廉，但对企业来说更重要的好处是它使 agent 的行为易于理解。
一个以精确、受限上下文为基础的 agent 会留下痕迹。你可以看到它问了什么、找到了什么、读了什么。这个痕迹是你能在审计员面前展示的 AI 工作流与你必须悄悄地将其从受规管系统中隐藏的工作流之间的区别。
当今一个审计就绪的 agent 工作流看起来什么样
Sourcegraph 的 Deep Search 在每个答案中返回一个明确的来源列表：它运行了哪些搜索以及它读了哪些文件以得出结论的记录。这个来源列表不仅仅是一个调试便利性；它是一个证据线索。当 agent 的推理受到质疑时，你可以指向它咨询的确切内容。
在这之下，Sourcegraph MCP 服务器暴露了离散的、命名的操作（读取文件、按关键字搜索、跳转到定义），而不是一个不透明的"做这件事"接口。agent 采取的每个行动都是一个易于理解、可以单独观察的事件。访问由存储库权限和受限 token 管理：agent 只能读取用户已经被允许查看的存储库。处理发生在你自己的实例内；唯一的外部调用是对模型本身的调用。综合起来，这不仅仅是检索。这是一份有权限的、可观察的记录，记录了你的 agent 接触了什么。
审计员想要一个带时间戳、可追溯的答案，它以真实的代码和配置变更为基础：不仅仅是什么改变了以及如何改变，还有为什么。这是"我们修改了这一行"和"我们在这个端点上添加了 JWT claim 执行，因为你的审计发现它缺失，这里是关闭差距的确切变更"之间的区别。
这就是 Deep Search 的价值。它引用提交历史、文件路径和代码上下文，然后将它们链接回每个变更背后的推理，而不是依赖于某人的记忆或陈旧的 Confluence 文档。而且记录是一个具体的工件：每个对话都可以导出为 PDF，你可以交给审计员，而不是要求他们接受 agent 的说法。这不仅满足了控制；它还缩短了审计。审计员不必在你的环境中四处查看，拼凑出什么信息了一个变更，因为来源和上下文已经以可追溯的方式排列出来了。
将 Deep Search 对话导出为 PDF
变更管理 / 访问控制
"显示上个审计期间触及身份验证服务的所有提交。"
Deep Search 按主题对触及身份验证服务的每个提交进行分组，每个提交都包含 SHA、日期和作者
数据隐私 / GDPR / CCPA
"我们何时实现了'被遗忘权'/ 用户数据删除端点？"
"PII 在静止状态下在哪里加密，何时添加了该加密？"
"我们是否有代码在没有同意检查的情况下记录或存储 IP 地址？"
Sourcegraph MCP 服务器：Claude Code 中的 Deep Search 工具，针对公共 gitlab-org/gitlab 存储库运行
安全控制（SOC 2 / ISO 27001）
"MFA 执行何时添加到管理员登录流程？"
"我们在哪里验证访问 token 过期，过期窗口是什么？"
"显示所有可能硬编码秘密 / API 密钥而不是从保险库中提取的地方。"
PCI-DSS（支付数据）
"支付处理模块的最后一次更改是什么时候，谁批准了？"
"信用卡数据在我们的代码库中的哪个地方被触及，存储前是否被标记化？"
Deep Search 在公共 gitlab-org/gitlab 存储库中追踪从入口点到存储的信用卡数据，命名文件和被哈希的字段
SOX（财务控制）
"收入确认逻辑在哪里实现，最后何时改变？"
"PHI 访问在哪里被记录，何时添加了审计日志？"
"我们是否有基于角色的访问控制来管控 PHI 字段，何时引入的？"
主要来源：SOC 2、ISO/IEC 27001、PCI-DSS、GDPR 第 17 条、HIPAA 45 CFR 164.312、SOX 第 404 条。
从生产力工具到记录系统
本能是将上下文引擎评估为开发者生产力工具：更快的搜索、更好的答案、更少的时间在 repo 中搜索。这是真实的，但它低估了对签署企业 AI 的人来说最重要的内容。
对于安全或平台负责人来说，上下文层也是 agent 开发的审计和合规层。它充当 agent provenance 的记录系统，回答监管机构和风险团队实际提出的问题：agent 读了什么，为什么它以这种方式行动。
一旦你的组织从试验 agent 转变为依赖它们，那个答案就不再是可选的了。能够产生它的团队是获得批准在最高风险地方使用 AI 的团队。这是同一个转变，将一个 repo 中的检测与实际的安全态势分离开：能力只值你能在整个代码库中演示的东西。
准备好证明你的 agent 读了什么？预订演示。
特别感谢 André Eleuterio、Dora Neumeier、Jamie Lindsay、Makenna Freauf、Matt Tanner 和 Stephanie Jarmak 对这篇博客文章的贡献。
解锁你的组织。更快发布。
使用 Sourcegraph，企业代码理解平台。