Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do You Use Cursor on a Codebase That Contains Customer Data?
Keep what the agent can reach smaller than the repository: a seeded fixture instead of a production export, .cursorignore for paths that cannot move, and no live connection string in a file it reads. When a task needs real rows, ask what the model receives from the page that renders them.
A developer fixing a rounding error in a claims service needs the code that computes the total and one record that shows the wrong number. The repository in front of Cursor often supplies both, because the seed file that makes the tests run was built from a production export of patient accounts, and the environment file beside it points at a copy of the live database. Each field the agent reads joins the model's context for the rest of the run, and a field the task never needed is one the model did not have to hold.
Three layers of hygiene carry most of that work: what the seed contains, which paths the agent may read, and which credentials sit in the files it opens. Each layer has a documented limit, and all three act on files and commands, so they run out at the task that needs real values. The work that needs the real records leaves the repository behind, because the agent reaches a live record through a page that is drawn for a person. Cursor sets its approvals at the command and the connection, and it does not describe a change to what a page shows the model (Cursor, Agent, 2026).
Key findings
- For Cursor to be used on a codebase like this one, the values on any page it opens would have to be replaced with consistent tokens before the model reads them, because a file rule stops at the repository, not at a rendered page (What Is Render-Layer Tokenization?).
- It would also require a named person approving each query against real rows and a record of what the model received, the question Arcade states as "Can this agent, acting for this user, perform this action on this resource?" (Arcade, 2025).
- Cursor's documentation describes approval for terminal commands and MCP connections, and none of the pages reviewed describes a control that changes a value on the screen before the model reads it (Cursor, Agent, 2026).
- Cursor's ignore-files page says .cursorignore blocks access to "Code accessible by Agent, Tab, and Inline Edit," and that "the terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore," so the rule governs reads, not commands (Cursor, Ignore, 2026).
- GitHub's token guidance says a creator should "choose the minimal permissions necessary for your needs," least privilege for a credential rather than a file (GitHub, 2026).
- A research note reports that "eight in ten employees use AI tools not approved by their organizations," which is how an export ends up open in an unreviewed tool (Cloud Security Alliance, 2026).
What does Cursor read on a repository that holds customer data?
A coding agent works in three places: the files it reads as context, the commands it runs in a terminal, and the tools it calls through MCP. A governed browser environment sits in a fourth, and it covers what the agent reads and does on a rendered page, a dashboard, a console, a settings page or an internal case screen. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so the repository layers are the control for what the page does not reach. By their own documentation, 8 of 10 coding agents can read environment variables by default, and Cursor is among them, so a live connection string in a file the agent opens is a value the model can read (Can AI Coding Agents Read Your API Keys?).
The first layer is the seed. A test database seeded from a production export of patient accounts gives the agent names, birth dates, medical record numbers and policy numbers that no test asserts on. A generated fixture keeps the shape and drops the people: the same field lengths, the same edge cases, the same nulls, with values that belong to nobody. How Do I Let a Coding Agent Use a Test Database That Contains Real Customer Data? works through that substitution, and Does GDPR Apply When a Coding Agent Reads Customer Data in a Test Database? covers why a test label does not change what follows the rows.
What does .cursorignore keep out of the agent's file reads?
Cursor's ignore file is the second layer, and it reaches only part of what the agent does. It blocks access to "Code accessible by Agent, Tab, and Inline Edit," which places the rule on the agent's own file reads: files it opens to answer a prompt, to finish a line, and a mention pulls in. Files in .gitignore and a default ignore list that includes .env* are "automatically ignored," and the page does not say which features that exclusion covers, so the entry to trust is the one a person writes in .cursorignore (Cursor, Ignore, 2026).
Patterns follow .gitignore syntax, so a folder of exports closes with one line, and an exclamation mark at the start of a line reopens a path an earlier line covered, which means a review has to read the negations too. The page is direct about the limits. It says that "while Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability," and that the terminal and MCP tools cannot block access to code the rule governs (Cursor, Ignore, 2026). A command that prints a file is outside the layer.
Research on automation bias explains why a file like this gets more trust than it earns. It describes "the tendency to over-rely on automation," and a rule that runs without a prompt is the kind of control a team stops checking (Goddard et al., 2012).
What do the vendors themselves say?
Cursor documents the controls that sit around the agent, and the wording is specific. Its agent security page says that "by default, terminal commands need your approval" and that "all MCP connections need your approval," which puts a person in front of the command and says nothing about the rows a query returns (Cursor, Agent, 2026). The same page calls its run modes "best-effort guardrails rather than a hard security boundary," and it warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues," which is a reason to read each prompt (Cursor, Agent, 2026).
GitHub's token page adds the credential side. It tells users to "Treat your access tokens like passwords" and notes that a fine-grained token can be "limited to only access specific repositories," which narrows what a stolen token reaches and leaves the token in whatever file holds it (GitHub, 2026).
Neither documented control changes a value on a page before the model reads it, and neither describes an exported record of what a model saw. What Cursor documents is a person in front of an action, which suits a command that deletes a table or a connection that imports one; the screen stays as the page drew it. Writing the six rows down is the review: the controls a team can name are the ones the vendor documents.
| Dimension | Cursor, per its documentation | What a buyer should verify |
|---|---|---|
| File access | .cursorignore blocks "Code accessible by Agent, Tab, and Inline Edit"; .gitignore entries and a default list are "automatically ignored" | Which paths hold customer records, and whether a negation reopens one |
| Terminal | "By default, terminal commands need your approval" | Who answers the prompt, and whether a printed file is caught in review |
| MCP | "All MCP connections need your approval" | Which servers are connected, and what each one can read |
| Run modes | "best-effort guardrails rather than a hard security boundary" | Whether the team treats a mode as a boundary |
| Rendered page | No page reviewed describes a change to what a page renders | What the model receives when the agent opens a case screen |
| Record | Approval prompts; no exported record is described | Where the account of the run lives, and who can read it |
What should sit in the files Cursor reads instead of a live connection string?
A live connection string undoes the other two layers. A repository can hold a clean fixture and a careful ignore list and still hand the agent a login, because the value sits in a file the agent opens as context: an environment file, a settings file, a comment in a script. A database URL that points at the seeded local instance, a role that can read the tables the test needs and nothing else, and a password that expires with the environment remove that reach entirely without removing the test.
The Columbia lab's incident list shows the reach left in place: "Cursor's agent deleted PocketOS's production database via a single rogue API call," an outcome that a generated fixture and a read-only role would have removed (Columbia DAPLab, 2026). The post adds: "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (Columbia DAPLab, 2026). A connection string in a file the agent reads is a flow decision.
Log files carry a copy of the same value often enough that How Do I Let a Coding Agent Debug With Production Logs Without Exposing Customer Data? is worth reading beside this section.
Where does repository hygiene stop, and what does the model receive from a rendered page?
All three layers stop at the same line: they govern files and commands, and the work that needs a real record happens somewhere else. A developer reproducing a misapplied payment needs the case as the system draws it, so the agent opens the internal case screen. Every field reaches the model: the patient's name, the account number, the date of birth, the adjuster's note. The page was built for a support call, so it carries every field a person on that call might need. What Is the PII Wall? describes where the gap sits, and Does Prompt Injection Expose Customer Records? covers what an instruction hidden in a record can do once the page is in context.
The guardrails around the agent do not close that line. In a benchmark of malicious issue requests against coding agents, "66.5% of the malicious issues from IssueTrojanBench penetrate all the guardrails (agent- and LLM-level) of coding agents" (Singh et al., 2026). The benchmark covered Cursor, Claude Code and Codex Desktop. Its authors add that "the current agent-level defense strategy offers limited additional protection for coding agents," a statement about the framework, not a vendor's settings (Singh et al., 2026).
What does a governed environment change?
A governed environment moves the control to the point where the page is drawn. Values chosen by policy are replaced with consistent tokens for the whole run, so a case screen renders PATIENT_001 and ACCT_002 where the name and the account number sit, and the model works on those tokens. Real values resolve only at the approved destination, at the moment a named person approves the action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
Two consequences follow here. The environment governs the rendered page, so it closes the route the three layers cannot reach and leaves them in place: the fixture, the ignore file and the scoped credential still govern the repository, and a team needs both. It also changes what a successful injection collects. A model holding tokens can still be told to repeat what it sees, and what it repeats is a token that resolves nowhere.
The record is the part a review can use later: which screens the run opened, which of them carried tokens, and who signed for each action.
RedactSure vs Cursor: 2026 Comparison & Alternative sets the two designs side by side, including where each sits and what it leaves open.
What the record shows
A control that replaces the values on a rendered page before the model reads them addresses the one route the repository layers cannot reach. Cursor documents approvals for commands and MCP connections and an ignore file that covers the agent's own file reads; none of those pages describes a change to what a page shows the model. This means a team should seed the tests from generated values, keep the credential useless outside the fixture, and treat the case screen as the place that exposes the record. Name one page the agent opens against the test database, run one query with the seed in place, and compare the fields on the page with the fields in the transcript.
Methodology and limitations
This page rests on Cursor's agent security and ignore-files documentation, GitHub's token documentation, two research papers, a lab post and a Cloud Security Alliance research note, read between October 20, 2026 and October 22, 2026. Public documentation read in full gives a sound view of where each product applies its control.
The products on this page are described from documentation and none was tested for this page. "Not described in the pages reviewed" means the pages reviewed, nothing broader. 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 whether a configuration meets a legal or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Can Cursor read a production export that sits in the repository?
Yes, if the export is a file in the project and the agent opens it. Cursor reads the files it is given as context and the files its tools reach, and an export in the tree is one of them. .cursorignore blocks the paths it lists for the agent's own file reads, and the page says the terminal and MCP tools cannot block access to code it governs. Replacing the export with a generated fixture takes the file out of reach.
Does .cursorignore keep a patient record out of the model's context?
Only for the agent's own file reads, and only while the rule holds. Cursor says .cursorignore blocks access to code Agent, Tab and Inline Edit can reach, and that complete protection is not guaranteed; the terminal and MCP tools can still print a file the rule covers. A rendered case screen is outside the rule entirely. Test the pattern with a dummy file that carries the same name and value.
What should the test database be seeded with?
Generated values that keep the shape of the production export and drop the people. The fixture needs the same field lengths, edge cases, null patterns and table relationships, because those are what the tests exercise. A production export carries every obligation that follows the rows and gives the test no more structure. Where a real record is unavoidable, keep it in one named table and limit who can read that table.
Who approves a query against real records?
A named person, and the approval has to sit outside the model. Cursor requires approval for terminal commands and MCP connections by default, which is a prompt in front of the command; it does not say who answers, and it says nothing about the rows the query returns. For a test database the resource is the seeded copy, and a read-only role narrows what a wrong answer reaches. Write down who approved, for which query, and when.
What record shows what the model read?
From the pages reviewed, none is described beyond the approval prompt itself. Cursor documents approvals for commands and connections, and a transcript shows what the run produced, which is not what the model was shown. A team that needs an account of the fields in context has to build it: the page rendered, the tokens in place of the values, the action, and the approver's name beside it.
Does hygiene in the repository decide what the model reads?
Partly. It decides what the agent can open in the project, which is where most accidental exposure starts, and it stops at the edge of a rendered page. An agent asked to check a case in the console reads the fields it draws, whatever the repository holds, and no ignore file or fixture reaches that page. Treat the repository layers as the first three controls and ask separately what the page shows the model.
How RedactSure Keeps a Customer Record Off the Agent's Screen
Repository hygiene keeps the export out of the tree, and the task that needs a real record still ends on a page that draws it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the internal case screen and reads the patient's name, record number and policy number as the page draws them. Inside: the page renders PATIENT_001 and MRN_002 where those values sit, and the real values resolve only at the destination a named person approved.
RedactSure is deploying now with enterprise and government customers. Cursor states that its run modes are "best-effort guardrails rather than a hard security boundary."
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A fixture keeps the export out of the tree, and the record still draws on a case screen. Bring a Cursor task that opens one and see, with test values, what the page shows the model and who approved it. Book a demo