Cursor DLP: Four Paths Send Your Codebase to a Model, and Autocomplete Is the Loudest
A developer using Cursor produces model requests from four distinct paths: codebase indexing, tab completion, chat with context, and agent mode. Tab completion alone fires on a keystroke cadence and sends surrounding file content thousands of times a day, which is a volume profile no chat-oriented AI DLP programme was built for. This piece separates the four paths, explains why endpoint DLP and network allowlisting both miss them, and sets out where classification and per-decision records belong.
A backend engineer types for six hours. Tab completion fires roughly every time they pause, and each firing sends the current file's surrounding lines plus related open files to a model. Call it two thousand requests in a working day, from one developer, with no button pressed and no dialog shown.
Their manager's AI usage report shows 14 chat conversations.
That ratio is the reason Cursor DLP is a different problem from ChatGPT DLP. The volume sits in a path nobody thinks of as a path, because it feels like an editor feature rather than a network call.
I want to separate the four paths and say what each one actually sends.
The four paths
Codebase indexing runs when a repository is opened and re-runs as files change. Cursor chunks the repository and computes embeddings so that later requests can retrieve relevant context. The unit is the whole repository, including files nobody opened, test fixtures with real data in them, and configuration committed years ago. A repository that contains a .env.example with a real value in it, or a fixture file built from a production export, gets indexed along with the application code.
Tab completion fires continuously during editing. It sends the cursor's surrounding context and, depending on configuration, content from other open or recently-viewed files. The cadence follows the developer's keystrokes. Nobody reviews an individual completion request, and there are thousands of them per developer per day.
Chat with context carries whatever the developer attached: a file, a folder, a symbol reference, or a retrieval over the index. This is the path that looks like AI usage and gets logged as such.
Agent mode carries the most per request, because the agent reads files, runs commands, and feeds terminal output back into the model as observation text. A failing test run pasted into context brings the stack trace, the assertion values, and whatever data the test was operating on.
Sorting a Cursor deployment by request count gives one ordering, and sorting it by content volume gives another. Rank the same four paths by unreviewed content volume and indexing comes first with tab completion second, which are the two paths with no human in the loop at all.
Why the existing controls miss it
Endpoint DLP watches file operations, clipboard events and removable media. Cursor reads a file the developer already has open, using ordinary file access from an approved application, and sends content over TLS. There is no clipboard event and no file written. The agent has nothing to fire on.
Network allowlisting governs hostnames rather than content. Cursor's traffic goes to Cursor's endpoints, and those get allowlisted early because the tool is approved. Allowlisting a hostname authorizes the destination and says nothing about the content.
TLS inspection, where a team runs it, produces the request bodies and then produces a volume problem. Two thousand completion requests per developer per day across 200 developers is 400,000 requests a day, and a DLP engine tuned for email and file transfers turns that into an alert queue nobody reads.
The gap is that none of these evaluate the content of an AI request against the identity making it, at the moment it is made. That is the general shape covered in AI DLP versus traditional DLP.
Privacy mode changes what is retained, not what is sent
Cursor offers a privacy mode that governs retention and training use. Teams read that setting and conclude the content question is settled.
Retention policy is a contractual and operational control over what the vendor keeps. The content still leaves your boundary to be processed, it still passes through whatever model providers sit behind the product, and your obligations under a regulation that cares about where regulated data is processed are unchanged by a retention setting.
Both things are worth having. Treating one as the other is where audits go badly.
What Cursor DLP has to classify
The classes are the same ones the organization already defined, applied to source code and its neighbours.
Secrets are the first-order finding. Hardcoded credentials, API keys in configuration, connection strings in test fixtures, and private keys committed to a repository all get indexed and all get sent as completion context. A pre-commit secret scanner covers the commit path and covers none of the four paths above, because indexing reads the working tree.
Regulated data in fixtures is the second. Test files built from production exports are common, they are rarely classified, and they sit in the same repository as the code.
Proprietary algorithms are the third, and this one is a judgment call the organization has to make explicitly rather than discover after the fact.
For tab completion specifically, the practical policy is a repository-level and path-level decision rather than a per-request one. Excluding a directory from indexing and completion is a control that scales; reviewing two thousand daily completions is not.
The record
For a keystroke-paced path, per-request alerting is the wrong output. The useful record is per-decision storage with aggregation on top.
decision_id: d-77e3a1, recorded at 2026-08-14T10:03:44Zoriginating_identity: j.hallberg@example.comworkspace: repo:payments-core, the repository the request came frompath_type: tab_completion, one of indexing, tab_completion, chat or agentfile_path: src/billing/refund_handler.pyclassifications: credential on 1 spanpolicy: source-egress-v4,outcome: blockedreason: credential pattern in completion context
The daily rollup is what a security team acts on: 41,208 completion requests across 23 developers, of which 17 were blocked for credential patterns, all 17 from two files in one repository. That is a two-file remediation task rather than an alert queue.
The workspace field matters more than it looks. A developer with three repositories open produces requests from all three, and attributing egress to the right repository is what makes the finding assignable to a team.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits as a stateless proxy on the HTTP path between your developers' tooling and the model endpoints it calls, which covers all four paths on the same terms rather than only the conversational one. Content is classified before the request is forwarded, policy is evaluated against the authenticated developer identity, and a per-decision record is written into storage you control.
Because the decision happens inline, a completion request carrying a credential pattern is blocked before it leaves, rather than reported after. The per-decision records aggregate into the repository-level and path-level view that makes a source-code egress problem fixable.
DeepInspect does not manage your repositories, run your secret scanning at commit time, or configure your editor.
If your developers are sending thousands of completion requests a day and your AI usage report shows chat conversations, the space between those two numbers is unmonitored source code. Book a demo today.