Dropbox has introduced a new engineering approach that connects security design artifacts directly with code review workflows using Model Context Protocol (MCP) and its internal knowledge system, Dash. The initiative aims to address a persistent gap in large engineering organizations: security requirements are typically defined during design reviews, but enforcement and verification occur much later, during code reviews, often without full context.

In many teams, threat models, design documents, and security requirements are created as standalone artifacts and stored separately from the codebase. As systems evolve, these documents often become stale or disconnected from implementation details. This leads to a recurring problem where engineers and reviewers must manually trace security intent back to code changes, increasing the likelihood of missed requirements or inconsistent enforcement.

Dropbox’s approach uses Dash as a centralized indexing and retrieval layer across internal documentation systems. Dash preserves existing access control policies while making organizational knowledge queryable. MCP provides a standardized protocol layer that enables AI systems to retrieve and use this context in developer workflows, such as code review.

MCP + Dash Architecture Overview (Source: Dropbox Blog Post)

When a pull request is created, the system identifies relevant code changes and uses MCP enabled retrieval to surface associated threat models and security requirements from Dash. Security context is presented directly within the code review interface, eliminating the need for engineers to search across separate documentation systems. Rather than automating security decisions, the goal is to reduce context switching and keep security intent visible at the point of implementation, turning security documentation from a passive artifact into an active input for engineering workflows..

The solution builds on Dash's enterprise security foundation, including permission-aware retrieval, encryption, and audit logging, ensuring sensitive documentation remains accessible only within existing organizational access boundaries. While initially focused on security reviews, Dropbox said the same MCP and Dash integration pattern could also support compliance validation, design reviews, and other governance-focused engineering workflows.

InfoQ interviewed Ishan Misha, Engineering Lead at Dropbox, to understand the architectural decisions behind the system, the role of MCP, and the challenges of operationalizing security-aware AI in production engineering workflows.

InfoQ: How did you evolve the integration between Dash and MCP from a retrieval system into something that actively influences security decision-making during code review?

Ishan Mishra:

The key shift was moving from simply retrieving context to reasoning about how that context relates to a code change. Retrieval by itself only gets you the document.

The motivation came from the need to scale code review effectively while maintaining a high bar for confidence and relevance. The next step was having the agent compare the retrieved context against the pull request itself. Rather than simply attaching a relevant document, it identifies the applicable requirement and flags potential gaps between the original design intent and the implementation.

It does not replace the security reviewer, but it changes the review from a generic code-quality exercise into one that's grounded in the original design intent.

InfoQ: Why did you choose MCP as the orchestration layer instead of integrating retrieval logic directly into CI or code review systems?

Ishan Mishra:

We wanted to avoid building a one-off integration for a single workflow. MCP gave us a standardized way to expose Dash as a context provider, while also allowing us to build a proof of concept and iterate very quickly early in the process. That means the code review agent doesn't need to know where information lives or how it's retrieved. It simply asks for the relevant context, while Dash handles retrieval and access controls behind the scenes.

That makes the architecture more reusable. Security review is the first use case, but the same pattern can apply to privacy, compliance, API governance, or design review.

InfoQ: How do you ensure this system does not create a false sense of security correctness?

Ishan Mishra:

This is an important design principle for us. We do not treat the system as a source of truth. We treat it as a way to surface evidence and reduce manual cross-referencing.

First, findings should be traceable. A reviewer should be able to see the requirement, its source, and the relevant code. If the system cannot ground a finding in both the requirement and the implementation, we don't want developers relying on it.

Second, the system is designed to assist reviewers, not replace their judgment. The goal is not to make developers believe the AI has certified the code. The goal is to make it harder for previously agreed requirements to disappear from the workflow.

Third, developer feedback is a critical part of continuously improving the system. Feedback on whether findings are accurate, relevant, and actionable helps us identify where retrieval or reasoning needs to improve and raise the quality of future reviews.

InfoQ: What were the hardest scaling or reliability challenges in making this work in real code review workflows?

Ishan Mishra:

The hardest part was not simply retrieving documents. The harder problem was retrieving the right context. In a large engineering organization, design documents and code aren't always directly connected, so keyword search alone isn't enough.

Semantic retrieval helps bridge that gap, but only if the results are relevant and specific. The system has to be conservative about what it turns into a review finding.

Developers already see a lot of automated feedback during code review, so we have a low tolerance for false positives. Even technically plausible findings can erode trust if they are not relevant to the change. Reliability is not just about uptime or latency; it is about whether the output is relevant, specific, actionable, and grounded in the code being reviewed. Maintaining that level of quality requires mechanisms to continuously evaluate findings, incorporate developer feedback, and optimize the system’s retrieval and reasoning over time.

InfoQ: How did you balance latency, retrieval depth, and developer trust when embedding MCP-based context into real-time code review workflows?

Ishan Mishra:

Developers do not want an exhaustive research report in the middle of code review. They want the few pieces of context that matter, presented when they're needed. Our approach is to retrieve enough context to understand the likely design intent, then surface concise, grounded findings rather than broad commentary.

Latency matters because code review is interactive. Trust comes from relevance, traceability, and restraint. We were also careful not to surface every weak signal. If the system can't clearly connect a requirement to the code being reviewed, it's better to be conservative than generate noise.

InfoQ: What lesson from this work would you apply to other AI-assisted engineering workflows?

Ishan Mishra:

The biggest lesson is that enterprise AI agents become much more useful when they are grounded in the organization's existing decisions, not just the current task.

Many AI coding workflows focus on generating or reviewing code in isolation. That is useful, but it misses the broader context behind why the code exists.

The same pattern applies well beyond security. Whether it's privacy requirements, API contracts, or architectural decisions, AI becomes much more valuable when it can connect implementation back to the organization's existing knowledge.

For us, the general lesson is that AI assistance should not just make engineers faster. It should help preserve institutional knowledge at the point where decisions are made.

About the Author

Leela Kumili