Dropbox Dash DLP: Connectors Turn Twelve Separate Permission Models Into One Prompt
Dropbox Dash indexes content across connected sources and answers questions over the combined result. The security property that matters is the fan-in: content from a dozen systems, each with its own permission model and its own history of over-sharing, converges into a single retrieval corpus and a single prompt. This piece walks the connector paths, explains why inherited over-permissioning surfaces at retrieval time, and sets out where classification and per-decision records belong.
An employee asks a universal search assistant what the company decided about a pricing change. The answer comes back with four citations: a Google Doc, a Slack thread, a Notion page and a PDF in a shared folder.
Each of those four lived under a different permission model, set by a different team, at a different time. Three of them were shared with "anyone in the company with the link" by someone who needed to unblock a meeting in 2023. Nobody has looked at those grants since.
Dropbox Dash did nothing wrong in that scenario. It read four things the employee was permitted to read and put them in one place. The finding is that permission decisions made independently across a dozen systems produce a combined disclosure surface that nobody ever approved as a whole.
That fan-in is the substance of Dropbox Dash DLP.
Where the content moves
Connector indexing is the first path. Dash connects to sources such as Google Workspace, Microsoft 365, Slack, Notion, Salesforce, Jira, Confluence and Dropbox itself, and builds a searchable index over them. The indexing job processes everything the connector's credentials can reach, on a schedule, with no per-document review. This is the bulk path, and it has the same profile as every other embedding pipeline: highest volume, least oversight, lowest chance of appearing on an AI inventory.
Retrieval and answer generation is the second. A question triggers retrieval across the index, and the retrieved chunks are assembled into a prompt sent to a model. The content of a dozen source systems arrives at the model boundary in one request.
Connector-side reads at query time are the third, where a connector fetches live rather than serving from an index. The content is fresher and the movement is the same.
The distinction between these three matters for control placement. Indexing needs classification across the whole corpus, and retrieval needs policy evaluated on each request. Teams tend to build one of those and assume it covers the other.
Permission mirroring is correct and insufficient
Enterprise search products mirror source permissions, so a user retrieves only what they could already open. Dash does this and it is the right design.
Two properties survive that design.
The first property is aggregation. A user permitted to read 40,000 documents individually, one at a time, when they know which one they want, is a different exposure from a user who can ask a question and receive a synthesized answer drawn from all 40,000. Nobody was ever going to read 40,000 documents. Retrieval makes the whole corpus effectively reachable through a question, and it does so without violating a single grant.
The second is inherited over-permissioning. Permission mirroring faithfully reproduces whatever access sprawl already existed. A folder shared organization-wide five years ago is now retrievable content for everyone, surfaced in answers rather than sitting unread in a directory nobody opens. Search is what makes latent over-sharing operational.
The honest framing is that a universal search deployment is an access review with a deadline. The permissions were always wrong; retrieval is what makes them visible.
What surfaces first when teams look
Three categories account for most early findings.
Compensation and HR content in shared drives, usually a spreadsheet that was shared for a review cycle and never unshared. It is retrievable by name, and it answers questions about salary bands accurately.
Credentials in wiki pages and Slack threads. A runbook with a service password in it, pasted in 2022, indexed in 2026, retrievable by anyone who asks how to restart the service.
Customer data in ticket systems and CRM notes, which is legitimately there and legitimately readable by the support team, and which now flows into prompts as retrieval context alongside everything else.
None of these require an attacker. They require a question.
What Dropbox Dash DLP has to classify
Two interventions, two output shapes.
At index time, classification runs per chunk and produces a corpus report. The useful artifact says how many chunks in which sources carry which classes, broken down by the sharing scope of the source document. A report saying 3,412 chunks carrying compensation data sit in documents shared organization-wide is a remediation task with a clear owner. A queue of per-document alerts gets ignored by the third day.
At retrieval time, classification runs on the assembled prompt before it goes to the model, and the policy question is what may be sent given who is asking. The class definitions come from the work in AI data classification, and the request-side practice is prompt-level DLP.
The control worth adding early is a sharing-scope dimension on the classification. Sensitive content in a document restricted to six people is a normal state. The same content in a document shared with the entire organization is the finding.
The record
decision_id: d-e6c208, recorded at 2026-08-14T09:47:19Zoriginating_identity: p.svensson@example.com, the person who askedquery_id: q-2026-08-14-4471retrieved_sources: google-drive doc-8812 at org-wide scope, slack msg-C04-9931 in a public channel, notion page-3310 at team scopeclassifications: compensation on 6 spans, credential on 1policy: retrieval-egress-v2,outcome: redactedreason: credential span removed from retrieval context
The share_scope field on each retrieved source is what turns a per-request record into an access-governance signal. Aggregate a month of these and the output is a ranked list of over-shared documents by how often they surface in answers, which is a far better remediation queue than a permissions report sorted by nothing.
The originating_identity field is what makes each retrieval attributable to a person rather than to the search service's own credentials.
DeepInspect
This is the gap DeepInspect closes on the request path. DeepInspect sits as a stateless proxy between your applications and the model endpoints they call, so the assembled retrieval prompt is inspected before it is forwarded, whatever mix of connectors produced it. Content is classified at that point, policy is evaluated against the identity that asked the question, and a per-decision record is written into storage you control.
That gives you the one thing a connector-level permission model cannot produce on its own: a record of what content from which sources actually reached a model, for whom, and under which policy. Enforcement is inline and fails closed.
DeepInspect does not manage your Google Drive sharing settings, run your connector syncs, or fix the grants that made a document org-wide.
If your universal search deployment is answering questions from a corpus nobody has classified, classification at the request path is the practical place to start. Book a demo today.