How Dropbox uses MCP and Dash to close the design-to-code security gap

Security Context Gets Lost Between Design and Code Review

At most organizations, a feature’s security posture is decided long before the code exists. Engineers meet, discuss how the feature could be attacked, agree on mitigations, and write those decisions into a threat model. Weeks later — often months — the code lands as a pull request (PR). By then, the threat model sits in a wiki or docs system, disconnected from the review process. Reviewers looking at the implementation have no automatic way to see what was actually agreed upon.

Dropbox wanted to quantify that disconnect. Examining the relationship between threat models and the PRs that implemented them, the company found that only 12% of implementing PRs carried an explicit link back to the original design review. The time gap made things worse: measuring 79 verified design-review-to-PR pairs showed 54% of implementing PRs were opened more than a month after the review was filed. The median delay was roughly five weeks, with a tail beyond 11 months. Just 29% of implementing PRs arrived within the first two weeks of the security review.

The data also revealed that security review isn't always happening early. About 15% of design reviews were filed retroactively — after code was already built, often ahead of a broader launch. In those cases, security-sensitive work wasn't identified as needing review during implementation.

Why Existing Security Tooling Misses the Point

Static analysis tools inspect code for known vulnerable patterns. They can confirm a control is present, but they can't confirm it matches what was approved during design review. Those tools analyze code in isolation, without the context or intent behind it.

Organizations often try to bridge the gap with process — requiring engineers to link PRs to design reviews or deploying bots to enforce the procedure. Those approaches depend on engineers remembering extra steps, and compliance erodes over time. The real problem isn't a lack of security knowledge; most organizations have plenty of documented risk assessments. The problem is making that knowledge available at the moment code is being reviewed.

Dropping the Threat Model into the Review Workflow

Dropbox's solution combines three pieces: the Dash content platform, Model Context Protocol (MCP), and a foundational large language model. Dash indexes content across Dropbox and connected applications, making years of threat models and engineering documentation searchable without manual cross-linking. Dash's MCP server exposes that indexed content to external AI tools. The security review agent uses that MCP server to search and read threat models and related documents on demand, avoiding custom integrations for each source system.

When a code change is opened for review, the agent pulls relevant threat models and supporting context through MCP. The foundational model examines the documented requirements and the proposed code together — recognizing, for instance, that a threat model mandates authentication on an endpoint and determining whether the new code actually enforces it. This is a key difference from static analysis: the system isn't inspecting code alone; it's comparing implementation against previously documented security decisions.

The results are surfaced inside the existing code review process, not in a separate security workflow. That placement matters. Developers already know which security alerts to ignore. A finding tied directly to the code under review is far more useful than a generic warning on every change. And while retrieving a threat model helps, a human still can't be expected to read both documents and cross-reference them on every PR. The foundational model performs that comparison automatically, flagging potential gaps. Human reviewers keep final judgment, but the manual cross-referencing is done.

Testing the Traceability of 150 Design Reviews

To validate the approach, Dropbox analyzed all 150 of its security design reviews from the preceding 18 months, mapping each to its implementing code. Dash's semantic search — the same retrieval that powers its user-facing search — proved essential:

• 80% of design reviews were linked to their implementing code changes via semantic search.
• Only 12% of those code changes explicitly referenced the design review.
• 69% of connections were recoverable only through semantic search — meaning most of the relationship between design and implementation would be invisible through manual references alone.

Surfacing threat model context during review consistently exposed findings that were invisible without it: missing controls, contradictions with approved designs, and regressions against known risks. The code was functionally correct in every case; gaps showed up only when the implementation was compared against the original requirements.

Examining past security incidents, Dropbox found root causes that were documented security requirements — straightforward ones, not edge cases — that never made it into the implementing code. The connection existed, but it wasn't visible at the right moment.

Reviewing code catches bugs. Reviewing implementation against design catches security gaps. The latter requires the ability to reason about the relationship between two documents — the threat model and the pull request — rather than analyzing either one in isolation. The same pattern applies beyond security, to any design or compliance review process where decisions are made long before the code that implements them.

Building on the design principles

The rollout is guided by a few core engineering principles. Findings must be checked against the actual code before they reach a developer; false positives corrode trust faster than true positives build it. Every finding needs to be traceable back to a specific requirement and source document so reviewers can verify the reasoning. Most findings should be advisory rather than blocking, with escalation saved for confirmed mismatches between approved designs and the implementation. And since requirements evolve, the system must account for stale context instead of blindly applying outdated rules.

Although security is the first use case, the architecture is deliberately general-purpose. Any team that produces design documents and needs to verify their implementation can use the same pattern. Privacy teams can surface data classification requirements when code touches user data flows — for instance, a review specifying that a field must never be logged can be checked against future changes handling that field. Platform teams can raise API contracts and compatibility requirements at interface changes, and compliance teams can surface regulatory obligations when code processes data in regulated jurisdictions.

The underlying pattern is straightforward: organizations already have documented requirements, but those documents are disconnected from the workflows where implementation decisions happen. Combining searchable organizational knowledge, MCP-based retrieval, and foundational models capable of reasoning across multiple context sources makes it possible to automatically compare implementation against intent.

Connecting what already exists

The scanning tools and threat models existed before this work. What was missing was a way to connect them at the right moment. MCP makes that connection technically feasible, Dash makes it practical, and foundational models make it useful — turning “here’s a relevant document” into “here’s a specific gap between what was required and what was implemented.” While security is where Dropbox started, the same approach can help any team ensure that decisions made during planning and review actually show up in the systems they build.