TL;DR: Cursor’s Privacy Mode supports zero data retention and prevents training on code in Business and Enterprise plans, but the practical risk remains what an AI coding agent can pull into prompts from repos, terminals, fixtures, and MCP-connected systems, according to Strac. The governance issue is not retention after transmission, but blocking secrets and sensitive data before the model ever sees them.
At a glance
What this is: Strac argues that Cursor’s privacy posture is strong on retention, but the real risk is agent reach into files, terminals, fixtures, and connected systems that can expose secrets before any model call is made.
Why it matters: This matters because IAM and security teams have to govern what AI coding agents can access, not just whether a provider stores prompts, especially when secrets and sensitive data sit in developer workflows and MCP-connected sources.
Context
Cursor’s privacy issue is not simply a model-retention question. The operational gap is that an AI coding agent can see far more than the developer intended, including repository contents, terminal output, and connected systems, so sensitive material can be pulled into prompts before any privacy setting matters. That makes prompt-time control a governance problem, not just a vendor-policy question.
For identity and access teams, the relevant boundary is not only who can use the tool but what the agent can reach. When coding assistants connect to SaaS apps, databases, and local files through MCP, they start to behave like privileged software actors that need scoped access, redaction controls, and auditability rather than trust in a privacy toggle.
Key questions
Q: What breaks when an AI coding agent can see more than the developer intended?
A: The failure is prompt-time exposure. If the agent can read repository files, terminals, fixtures, or connected systems, it can assemble sensitive context before any privacy setting or retention policy matters. The right control is to stop secrets, PII, and credentials from entering the prompt in the first place, not to rely on deletion after transmission.
Q: Why do coding agents increase risk even when zero data retention is enabled?
A: Zero data retention reduces provider storage risk, but it does not stop the agent from collecting sensitive material and transmitting it upstream. If the model sees a secret in the first place, the exposure has already happened. That is why data-loss prevention, redaction, and retrieval control matter more than storage promises alone.
Q: What are the signs that an AI coding environment is becoming overexposed?
A: Look for unsanctioned MCP servers, auto-execution enabled by default, extension packages with broad file or network reach, and prompt traffic that includes secrets or source code. Those are indicators that the editor has become a runtime trust surface rather than a bounded developer tool.
Q: Should teams trust privacy mode or central data controls for AI coding assistants?
A: Central data controls should take priority. Privacy mode matters for retention, but it does not govern what the agent can see or collect. Managed enforcement, connector scoping, and pre-prompt redaction reduce exposure at the point of access, which is where the real risk sits for regulated code and sensitive repositories.
Technical breakdown
Why zero data retention does not stop prompt leakage
Zero data retention addresses what happens after a prompt reaches the provider. It does not prevent the agent from collecting secrets, customer data, or source code from the local environment and packaging them into the request. In practice, the dangerous step is context assembly, where file retrieval, terminal logs, and pasted snippets are merged into one prompt. That means privacy policy and data minimisation solve different problems: one limits storage, the other limits exposure. For security teams, the control point is upstream of the model, where sensitive content is detected, redacted, or blocked before transmission.
Practical implication: treat prompt construction as the control boundary and inspect what the agent can ingest before any model call.
How MCP connectors expand the AI coding agent attack surface
MCP changes the risk profile because it lets the coding agent pull data from external tools and repositories, not just the code editor. Once connectors are in play, the agent can retrieve Jira tickets, Slack messages, databases, or internal documentation, which expands the set of data classes that can end up in prompts. That creates a new governance problem: access is no longer limited to the developer's visible workspace, and the agent can become a conduit for overexposed context. The architectural issue is not the protocol itself, but the absence of policy at the point where external data is exposed to the model.
Practical implication: inventory every MCP-connected source and apply allowlists, data-class rules, and redaction before retrieval.
Why developer privacy settings are not enough for enterprise governance
A privacy checkbox is a weak control for enterprise use because it depends on individual behaviour and does not govern the full lifecycle of access. Business and Enterprise plans can enforce stronger defaults, but even then the issue remains what the agent sees inside the repo and adjacent systems. This is the same pattern seen in other identity-bound workflows: policy has to be enforced centrally where access is granted and data is selected, not left to user discretion. The result is that AI coding governance looks more like privileged access management than a conventional app privacy setting.
Practical implication: enforce fleet-wide settings and pair them with central policy over agent reach and data handling.
Threat narrative
Attacker objective: The objective is to get secrets or sensitive data into the model context and out of the developer’s controlled boundary, creating exposure even without long-term provider storage.
- Entry occurs when a developer asks the coding agent to inspect code, fix an error, or retrieve relevant context from the repository or connected systems.
- Credential and data exposure happen when the agent pulls in .env files, API keys, terminal output, fixtures, or MCP-connected records that contain secrets or customer information.
- Impact follows when those secrets or sensitive records are transmitted in prompts, even if the provider later deletes them under a zero-retention policy.
Breaches seen in the wild
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Prompt-time exposure is the real control problem: privacy retention settings matter less than the moment an agent assembles context from code, terminals, fixtures, and connected tools. If sensitive data reaches the prompt, the control has already failed, even if the provider later deletes it. The practical lesson is that data-loss prevention has to sit in front of the model, not behind it.
MCP turns coding assistants into policy-bearing data movers: once the agent can reach Slack, Jira, databases, and internal docs, it stops being a simple editor companion and starts operating as a governed software actor. That means connector scope, data-class rules, and logging belong in the same conversation as identity and access governance. Security teams should treat MCP reach as a controllable trust boundary, not a convenience feature.
Privilege is now defined by retrieval, not only by login: the agent may be authenticated correctly and still be overexposed if it can read files or systems that contain secrets and PII. This is a named governance gap we would call agent reach overshoot: the agent can legitimately authenticate but illegitimately collect more context than the task requires. Practitioners should narrow reach before they try to perfect retention policy.
Central enforcement beats individual discretion: on personal plans, privacy posture depends on a developer finding and enabling a setting; on managed plans, enforcement is structural. That distinction matters because security governance fails when high-risk behaviour is left to user memory. For teams running code with regulated data, the decisive question is not whether an assistant is private, but whether access and redaction are enforced across the fleet.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Agent reach overshoot: the new risk is not just model retention, but the way coding assistants assemble context from places developers did not explicitly approve. Once the agent can read repos, terminals, and MCP-connected systems, teams need to govern retrieval scope with the same seriousness they apply to privileged access.
For programmes handling source code with embedded secrets or customer data, the practical question is whether redaction occurs before data leaves the machine. If the answer is no, privacy mode is only a downstream safeguard, not a real prevention control.
Strac’s analysis also points to the speed at which MCP-related exposure is growing: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That scale suggests connector governance is now a mainstream exposure problem, not an edge case.
For practitioners
- Enforce fleet-wide privacy defaults Require managed plans and central policy so privacy mode is not left to individual developers to enable or forget.
- Block secrets before prompt submission Detect API keys, tokens, .env values, and credentials at the point of context assembly, then redact or block them before they leave the machine.
- Restrict what agents can retrieve Apply allowlists and data-class controls to files, terminals, chat systems, and databases that MCP-connected tools can query.
- Log redaction events for audit evidence Keep records of detections, redactions, and blocks so security and compliance teams can show how sensitive data was prevented from entering prompts.
Key takeaways
- Cursor’s privacy settings address storage and training exposure, but they do not stop an agent from pulling sensitive data into a prompt.
- The main governance gap is context assembly, where files, terminals, fixtures, and connectors can surface secrets before any model interaction.
- Security teams need upstream controls that limit agent reach and redact sensitive content at the point of submission.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on secrets and credentials entering AI prompts through code and connected tools. |
| NHI-10 — Human Use of NHI | Developers and their assistants are using machine credentials and connected systems in ways that widen exposure. | |
| Recommendation — Deploy controls that detect and block secret leakage before AI prompts leave the developer machine. Limit human-adjacent use of NHI credentials and monitor how coding agents reach sensitive systems. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | The article describes collection of secrets and sensitive data before transmission to the model. |
| Recommendation — Map prompt leakage to credential access and collection tactics, then harden detection at those stages. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Is Protected | The article highlights protection gaps before sensitive data is submitted to an external service. |
| Recommendation — Treat pre-submission data protection as a core PR.DS control and enforce redaction where data is collected. | ||
| CIS Controls v8 | CIS-5 — Account Management | Managed access and fleet-wide enforcement are central to removing user-dependent privacy settings. |
| Recommendation — Use account management controls to enforce approved AI tooling settings across the developer fleet. | ||
Key terms
- Push-Time Exposure: Push-time exposure is the period beginning when a commit reaches a remote repository and ending when a later control inspects it. That window matters because automated scrapers can find and exploit secrets before pull request scanning or manual review ever happens.
- MCP connector: An MCP connector is the integration component that lets an AI agent or application use the Model Context Protocol to reach external tools, data sources, or services. It translates protocol requests into tool-specific actions, handles authentication and context exchange, and helps govern what the agent can access, invoke, or retrieve.
- Data Redaction: Data redaction is the removal or masking of sensitive information before it is shared outside a trusted boundary. In DLP programmes, redaction is used to limit exposure in documents, messages, and workflows while preserving the useful parts of the content for legitimate business use.
- Agent Reach: The total set of files, systems, and connectors an AI agent can inspect or query during a task. In practice, reach defines the real exposure boundary, because broader reach increases the chance that secrets, source code, or regulated data will enter model context.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps identity and security teams align control boundaries for machine-driven access across modern development workflows.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org