Dropbox 在 2026 年 6 月 12 日发布的工程文章中介绍了一套连接安全设计与代码审查的内部系统。该系统结合 Model Context Protocol（MCP）、Dash 以及基础大模型，在代码变更进入 Pull Request 审查流程后，自动检索相关威胁模型和安全设计文档，并将文档中的要求与待审查代码进行比较。
Dropbox 表示，安全评审通常会在功能开发早期完成，威胁模型中也会记录潜在风险和约定的防护措施。但在实际开发中，这些文档往往存放在 Wiki 或其他文档系统中，代码则通过 Pull Request 提交，两者之间缺少持续、明确的关联。Dropbox 对过去一年半的 150 份安全设计评审进行分析后发现，只有 12% 的实现代码变更明确引用了原始设计评审；通过 Dash 的语义检索，系统能够将 80% 的设计评审与对应代码变更建立关联，其中 69% 的关联无法仅靠人工引用发现。
在这套架构中，Dash 负责索引和连接 Dropbox 及其他接入应用中的组织知识，并通过 MCP 服务器向 AI 工具提供检索和读取能力。安全审查 Agent 可以通过 MCP 获取威胁模型及相关文档，再结合基础大模型分析安全要求与代码实现之间的关系。例如，系统可以检查威胁模型要求某个接口必须具备身份验证时，相关代码是否确实执行了这一控制。
这与传统静态分析的侧重点不同。静态分析主要检查代码中是否存在已知模式或安全控制，而 Dropbox 的方案试图回答代码是否符合此前安全设计阶段已经确定的要求。Dropbox 称，在测试中，加入威胁模型上下文后，系统发现了仅依靠代码检查难以识别的问题，包括缺失的安全控制、与已批准设计相矛盾的实现，以及针对已知风险的回归。
Dropbox 强调，该系统不会取代安全审查人员，也不应被视为代码已经通过安全认证的依据。系统输出需要能够追溯到具体安全要求、来源文档和对应代码，人工审查人员仍负责最终判断。为控制误报和噪声，大多数发现预计以建议形式呈现，只有经过确认的设计要求与实现之间的差距才适合升级为阻断性问题。
Dropbox 认为，MCP 的价值在于提供标准化的上下文访问方式，使代码审查 Agent 不必针对每个文档系统开发定制集成。除安全评审外，这一模式也可以扩展到隐私、合规、API 治理和设计评审等场景：组织先前形成的要求由 Dash 等系统提供检索能力，再通过 MCP 进入开发工作流，最后由模型比较设计意图与实际实现。