Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Cursor's Privacy Mode Keep API Keys Out of the Model?
No. What an account keeps after a request and what the model receives during it are separate questions, and Cursor's security page describes no step that removes a value from the context, so check what the agent can open before you rely on the setting.
A developer keeps an API key and a database URL in a project's .env file, turns on Privacy Mode, and assumes the key is out of reach. The assumption treats two events as one. What an account keeps after a run is a storage question. What a model receives during a run is a context question, and the context is fixed before any storage rule applies. The difference has consequences: a value in the model's context can be repeated in a summary, written into a commit message, pasted into a configuration file, or used by an instruction hidden in a file the agent opens. Cursor's own pages describe approvals for terminal commands and MCP connections and an ignore list for paths, and they leave open what a model receives from a file its tools can read, which is the part that decides the title. A storage commitment can be honest and still leave the request unchanged, which is why the two questions need separate answers. Settling which question the setting in the title answers changes what a team does next: an ignore rule, a scoped token, or an environment where the value is never in the workspace at all.
Key findings
- For an API key in a project file to stay out of the model, the value would have to be replaced with a consistent token before the agent reads the file, and the real key released only at the destination a named person approved (What Is Render-Layer Tokenization?).
- It would also require a named person approving each use of the key and a record of what the model received, both properties of the run rather than of what is kept after it (Can a Coding Agent Use a Credential It Cannot Read?).
- Cursor's security page sets approval defaults for terminal commands and MCP connections and does not state that values in a file are replaced before the model reads them, so the page leaves the model's context to the application (Cursor, Security, 2026).
- Cursor's documentation states that "By default, terminal commands need your approval" and that "All MCP connections need your approval"; each is a gate on an action, not on what a file read returns to the model (Cursor, Security, 2026).
- Mireshghallah et al. found that GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases, the exposure a value faces in the context (Mireshghallah et al., 2024).
- OpenBSD's manual page describes ssh-agent as "a program to hold private keys used for public key authentication," the long-standing pattern for using a key without reading it (OpenBSD, 2026).
What does the model receive when Cursor's agent opens an .env file?
A project's .env file holds a database URL and an API key. The app fails with a connection error, and the agent is asked to find the cause, so it opens the file and reads the values. The model now holds both strings and the variable names that identify them. In the ten-product review, all 6 coding agents, Cursor included, place a credential in an environment variable the agent can read, while 2 of the 4 sandboxes keep it out by default, so a retention setting does not change what the run reads (Can AI Coding Agents Read Your API Keys?).
A governed browser environment covers what an agent reads and does on a rendered page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An .env file is a file in the project, read through the editor's tools, so the control that applies to it is a project rule rather than a page control. Cursor says files in .gitignore and a default list that includes .env* are "automatically ignored," without saying which features that covers (Cursor, Ignore files, 2026). It documents .cursorignore as the block on "Code accessible by Agent, Tab, and Inline Edit" and warns that "complete protection isn't guaranteed due to LLM unpredictability" (Cursor, Ignore files, 2026). Whether the default list alone keeps .env out of the agent's own reads is not described in the pages reviewed, so list the path explicitly.
The page that mints the key is where a page control applies, and a live key shown there is displayed "one time," so the screen that displays it is where the exposure happens (Can an AI Agent Manage My Stripe Keys Safely?). The page an agent opens to check which keys exist exposes the same value, and What Happens When an AI Agent Can See API Keys in a Console or Settings Page? sets out what such a page shows. A .env file and a key page carry the same credential, and only one can be governed at the point it renders.
Why does a retention setting not answer what the model reads?
The answer starts with what a setting can govern. A retention or training commitment describes what happens to data after Cursor has it: whether a request is stored, for how long, and whether code trains a model. Those terms are worth reading. They do not describe what is assembled and sent when the agent runs, and cannot remove a value from a request that has already carried it.
The IETF's OAuth guidance makes the same distinction on the server side. It tells a resource server to "treat access tokens like other sensitive secrets and not store or transfer them in plaintext," a storage rule for the server while the token still travels in the request (IETF, 2025). OWASP separates the two paths as well: personal data "may be disclosed during interactions with the LLM," which is the live request and not the training set (OWASP, LLM02, 2025).
For a coding agent the request is the working set: the file it opened, the command output it read, the diff it is about to write, and anything else the tools returned (Does My AI Vendor See the API Keys My Coding Agent Reads?). Cursor's security page describes approvals around terminal commands and MCP connections and says the AI "can behave unexpectedly due to prompt injection, hallucinations, and other issues," and it does not describe a step that inspects that working set for credentials (Cursor, Security, 2026).
What do the vendors themselves say?
Cursor's pages speak to two controls, and both are written for an action rather than for a reading. The security page sets the defaults plainly: "By default, terminal commands need your approval" and "All MCP connections need your approval," and it calls the run modes "best-effort guardrails rather than a hard security boundary" (Cursor, Security, 2026). An approval that a person clicks governs whether a command runs, not what the command's output or an open file puts in the context.
The ignore page governs paths. A .cursorignore entry means "Cursor blocks access to files listed in .cursorignore from: Code accessible by Agent, Tab, and Inline Edit" (Cursor, Ignore files, 2026). The same page says the terminal and MCP server tools "cannot block access to code governed by .cursorignore" and that blocking "isn't guaranteed due to LLM unpredictability" (Cursor, Ignore files, 2026). One control narrows what the agent can open, the other narrows what it can run, and neither changes what the model is given from a file that is open.
Neither page describes a filter on the context itself. The security page does not say how credentials are stored or protected. What the model receives from the file the agent just opened is the question to put to each control.
| Dimension | Cursor, per its documentation | What a buyer should verify |
|---|---|---|
| Action gating | Terminal commands and MCP connections wait for approval by default | Which tools the approval covers, and whether a file read is one |
| File paths | A .cursorignore entry blocks "Code accessible by Agent, Tab, and Inline Edit" | Whether every path that holds a key is listed, and who maintains it |
| Default exclusions | .gitignore entries and a default list that includes .env* are "automatically ignored" | Which features that exclusion covers; the page does not say |
Where does an API key go after the model reads it?
A value that enters the context does not stay in the file. It can appear in the conversation the developer reopens, in a summary the agent writes at the end of the task, or in a commit message. Each is a copy, and one is enough.
Cursor's approval defaults intercept one of those paths: a terminal command waits for a person and an MCP connection waits for a person, so a key used in a command can be stopped at the prompt while a key repeated in a summary passes without one (Cursor, Security, 2026). DAPLab's incident list shows the action side of the same gap: "Cursor's agent deleted PocketOS's production database via a single rogue API call," a call an approval can catch and a reading no approval sees (DAPLab, 2026). OWASP's agentic threat reference is "a threat-model-based reference of emerging agentic threats," a catalogue of what an agent can do rather than what it reads (OWASP, Agentic AI, 2025).
A credential the agent cannot read closes the second path, as Can a Coding Agent Use a Credential It Cannot Read? describes: a process outside the agent holds the value, the agent works with a reference, and the real value is substituted only for a destination the policy names. Can a Browser Agent Read an API Key It Just Generated? shows the same idea on a page, where the model sees placeholders and the values are injected after the model's call. The record follows the design: a value the model never held cannot be repeated.
What does a governed environment change?
A governed environment changes what the model is given, not only where the run is allowed to go. The page the agent reads is drawn with the values a policy names replaced by consistent tokens, so an API key renders as KEY_001 and an account as ACCT_001, and the model works with those strings for the whole run. The real value resolves only at the approved destination, at the moment a named person approves the action that needs it, and every screen in the form the model saw it, every action and every approval, land in a record the customer exports.
The design has a defined edge. Its scope is the rendered page the agent reads and acts on: a dashboard, a console, a settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, which is why the .env file in the first section is a separate problem with a separate answer. A team that governs pages still needs a scoped token, an ignore rule and a workspace that does not hold production keys.
The research on tool-interface defenses places the control at the boundary where a tool's input and output cross, described as a "simple, modular, and model-agnostic defense operating at the agent-tool interface" (Bhagwatkar et al., 2026). A retention commitment sits later, after the copy has been made. The order is the point: substitution before reading, release at the destination, approval by a person, and a record. RedactSure vs Cursor: 2026 Comparison & Alternative compares the two approaches.
What the record shows
The control that decides this question sits before the model reads anything: values replaced with consistent tokens on the page or file the agent opens, the real credential released only at an approved destination, a named person approving the use, and a record of what the model received. Cursor's pages describe approvals for terminal commands and MCP connections and an ignore list for paths, and none of them describes a step that removes a value from the context (Cursor, Security, 2026; Cursor, Ignore files, 2026). A retention setting answers a storage question, and the file the agent opens is read first. Before relying on the setting, a team should test it: put a dummy key in a .env file, ask the agent to diagnose a connection error, and read the request the model receives. If the dummy string is there, the setting in the title was never the control.
Methodology and limitations
The page rests on public vendor documentation read in full: Cursor's agent security page and its ignore-files page, the IETF's OAuth security best current practice, and OWASP's guidance on sensitive information and agentic threats. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it. The statements are the vendors' own, and "not described in the pages reviewed" means the sentences recorded for a page, not what a product cannot do. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. Determinations about custody, retention or disclosure belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Does Cursor's Privacy Mode keep API keys out of the model?
No. What the setting keeps after a request and what the model receives during it are separate questions, and only the second decides this one. Cursor's security page describes approvals for terminal commands and MCP connections, and its ignore page governs paths; neither describes a filter on the context. A key in a file the agent opens is in that context when the request is made, and the setting does not change that.
What does the model receive when the agent opens a .env file?
Whatever the file contains. A .env file usually holds a database URL, an API key and a few flags, and an agent asked to diagnose a connection error reads all of it. The values arrive with their variable names, so the model can tell which string is the key. Cursor's approval default is written for terminal commands and MCP connections; the ignore page is the documented control for paths. A value in the file is in the context before either control applies.
Does an ignore list keep an API key out of the model?
Only for the paths it lists and the tools it binds. A .cursorignore entry blocks files from "Code accessible by Agent, Tab, and Inline Edit," and Cursor says complete protection is not guaranteed because of LLM unpredictability. The page also says the terminal and MCP server tools cannot block access to code the list governs. An ignore rule therefore reduces what the agent can open; it does not change what the model receives from a file that is open.
Who approves the agent's use of an API key?
A person at a terminal prompt or an MCP connection, when those defaults are on. That approval covers the command that would use the key, not the reading that put the key in the context. A governed run adds an approver at the action that needs the real value, with the destination named in advance. Without that step, the approver sees a command and not the value behind it.
What record shows what the model received?
Few vendor pages describe one. Cursor's pages describe approvals and an ignore list, and the session itself is the only account of what the model read. A record that answers the question lists the page or file, the values that were replaced, the tokens the model saw, and the person who approved each use of a real value. That record is the one an assessor asks for.
What should a developer do before putting a key in a project file?
Remove the key from the workspace, or keep the agent from reading it. A scoped token that expires and reaches one service limits what a copy is worth, and an explicit ignore entry tested with a dummy file confirms the path is covered. For the page that mints the key, the stronger move is a render-layer control that shows the model a token and releases the real value only at an approved destination. The two measures cover different surfaces, and a team usually needs both.
How RedactSure Keeps a Project Key Out of the Model's Context
An ignore rule hides a path while the same key is printed on the page that issued it, and nobody approves what the model read. Cursor says files in a default list that includes .env* are "automatically ignored," without saying which features that covers (Cursor, Ignore files, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opened the API keys page on the provider's dashboard: the page printed the live value, and that value entered the context and could leave in a summary or a note. Inside, the same page renders KEY_001, the agent finishes the config fix for the project, and the real value resolves only at the request a named person approves.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A key printed on a provider page stays in the model's context for the rest of the run. Bring the key page and see, with test values, what the model reads, who approves the release and what the record holds. Book a demo