Dropbox 推出了一套新的工程实践，通过 Model Context Protocol（MCP，模型上下文协议） 和内部知识系统 Dash，将安全设计产物直接连接到代码审查工作流中。这一方案旨在解决大型工程组织中长期存在的一个问题：安全要求通常会在设计评审阶段确敲定，但直到更后期的代码审查阶段才会真正得到验证和落实，而此时参与审查的工程师往往已经缺少完整的设计上下文。
在很多团队中，威胁模型、设计文档和安全要求都是独立产物，与代码库分开存储。随着系统不断演进，这些文档很容易过时，或者逐渐与实际实现脱节。于是，一个反复出现的问题是，工程师和代码审查人员必须手动追溯代码变更背后的安全意图。这不仅增加了工作量，也提高了遗漏安全要求或执行不一致的风险。
Dropbox 的方案将 Dash 作为内部文档系统之间的集中式索引和检索层。Dash 在保留现有访问控制策略的同时，让组织内部知识变得可查询。MCP 则提供了一层标准化协议，使 AI 系统能够在代码审查等开发者工作流中获取并使用这些上下文信息。
MCP + Dash 架构概览（来源：Dropbox 博客）
在创建 Pull Request 后，系统会识别其中涉及的代码变更，并通过支持 MCP 的检索机制，从 Dash 中找出相关的威胁模型和安全要求。这些安全上下文会直接呈现在代码审查界面中，工程师无需再到不同的文档系统中手动搜索。这一方案并不是为了自动化安全决策，而是减少开发者在不同系统之间切换的次数，让安全意图在实际实现阶段始终可见，从而将原本被动存在的安全文档转变为工程工作流中的主动输入。
该方案建立在 Dash 原有的企业级安全能力之上，包括基于权限的检索、加密和审计日志，确保敏感文档仍然遵循组织现有的访问边界。Dropbox 表示，虽然目前主要应用于安全评审，但同样的 MCP + Dash 集成模式也可以用于合规验证、设计评审，以及其他以治理为重点的工程工作流。
InfoQ 就这一系统背后的架构设计、MCP 的作用，以及如何在生产环境工程工作流中落地具备安全意识的 AI，与 Dropbox 工程负责人 Ishan Mishra 进行了交流。
InfoQ：你们是如何让 Dash 与 MCP 的集成从一个简单的检索系统，进一步发展为能够在代码审查过程中实际参与安全判断的？
Ishan Mishra：关键变化在于，我们不再只是检索上下文，而是进一步分析这些上下文与具体代码变更之间的关系。单纯的检索只能帮你找到一份文档。
我们最初是希望在维持较高准确性和相关性要求的同时，让代码审查能够规模化。下一步就是让 Agent 将检索到的上下文与 Pull Request 本身进行比较。它不只是简单地附上一份相关文档，而是会识别其中适用的安全要求，并找出最初设计意图与实际实现之间可能存在的差距。
它不会取代安全审查人员，但会让代码审查不再只是泛泛的代码质量检查，而是建立在最初设计意图的基础之上。
InfoQ：为什么选择 MCP 作为编排层，而不是直接将检索逻辑集成到 CI 或代码审查系统中？
Mishra：我们希望避免针对某一个工作流开发一次性的集成方案。MCP 为我们提供了一种标准化方式，可以将 Dash 作为上下文提供方，同时也让我们能够在早期快速完成概念验证并持续迭代。这意味着代码审查 Agent 不需要知道信息存在哪里，也不需要了解具体的检索方式。它只需要请求相关上下文，而 Dash 会在后台负责检索和访问控制。
这样一来，整个架构也更容易复用。安全审查只是第一个应用场景，同样的模式还可以用于隐私、合规、API 治理或设计评审。
InfoQ：你们如何确保这个系统不会让开发者产生一种“代码已经经过安全验证”的错觉？
Mishra：这是我们非常重视的一项设计原则。我们不会把这个系统视为事实来源（Source of Truth），而是把它看作一种帮助开发者获取证据、减少人工交叉核对的工具。
首先，所有发现都应该能够被追溯。审查人员应该能够看到具体的安全要求、要求的来源，以及对应的代码。如果系统无法同时从要求和实现两方面为某项发现提供依据，我们就不希望开发者依赖这个结果。
其次，这个系统的定位是辅助审查人员，而不是取代他们的判断。我们的目标不是让开发者认为 AI 已经为代码进行了认证，而是让此前已经达成共识的安全要求更难在工程流程中被遗漏。
第三，开发者反馈是持续改进系统的关键。通过收集开发者对结果准确性、相关性和可操作性的反馈，我们可以发现检索或推理环节需要改进的地方，并持续提升后续代码审查的质量。
InfoQ：在将这一方案真正应用到代码审查工作流时，最困难的扩展性或可靠性问题是什么？
Mishra：最困难的并不是简单地把文档检索出来，而是找到正确的上下文。在大型工程组织中，设计文档和代码并不总是存在直接关联，因此单纯依赖关键词搜索是不够的。
语义检索能够帮助弥合这一差距，但前提是检索结果必须真正相关且足够具体。系统必须对哪些内容可以被转化为代码审查发现保持谨慎。
开发者在代码审查过程中本来就会收到大量自动化反馈，因此我们对误报的容忍度很低。即使一项发现从技术上看似合理，只要与当前代码变更无关，就可能损害开发者对系统的信任。所以，可靠性不仅仅意味着系统正常运行、延迟足够低，还意味着输出必须与当前代码相关、足够具体、可执行，并且能够在代码本身中找到依据。要长期维持这样的质量，就需要持续评估审查结果、吸收开发者反馈，并不断优化系统的检索和推理能力。
InfoQ：在将基于 MCP 的上下文嵌入实时代码审查工作流时，你们如何平衡延迟、检索深度和开发者信任？
Mishra：开发者并不希望在代码审查过程中看到一份详尽的研究报告。他们需要的是少数真正重要的上下文，并且要在需要的时候呈现出来。我们的做法是检索足够的上下文，以理解可能的设计意图，然后提供简洁且有依据的审查结果，而不是泛泛而谈。
延迟很重要，因为代码审查本身是一个交互式过程。信任则来自相关性、可追溯性以及克制。我们也会避免把每一个微弱信号都呈现给开发者。如果系统无法明确建立某项要求与当前代码之间的联系，那么保持谨慎、避免制造噪声会是更好的选择。
InfoQ：这项工作带给你的最大经验是什么？如果应用到其他 AI 辅助工程工作流中，你会怎么做？
Mishra：最大的经验是，当企业 AI Agent 能够建立在组织过去已经做出的决策之上，而不仅仅关注当前任务时，它的价值会大幅提升。很多 AI 编程工作流都专注于独立生成或审查代码。这当然很有用，但它忽略了一个更大的问题：为什么要编写这些代码。
同样的模式也适用于安全之外的其他领域。无论是隐私要求、API 格式约定还是架构决策，当 AI 能够将具体实现与组织已有的知识连接起来时，它的价值都会更大。
对我们来说，更普遍的经验是，AI 辅助不应该只是让工程师写代码更快，还应该帮助组织在做出决策的关键节点保留和利用那些已经积累的知识。
查看英文原文：Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review
