Developer data protection
Cursor
Check every Cursor access path
Use .cursorignore for the Cursor file and context controls it documents, then verify terminal and MCP access separately in your actual client and execution mode. Cursor does not describe the file as a universal isolation boundary. A small, synthetic canary test can show what your configuration allows without using a real secret.
For Endpoint security and Cursor administrators
One exclusion file does not describe every tool path.
Synthetic marker files and unexecuted tests. No observed Cursor or Aona results are claimed.01
Understand the documented boundary
Cursor’s ignore-file documentation describes excluding files from code available to Agent, Tab, Inline Edit and explicit references. It separately cautions about terminal and MCP tool access and does not guarantee complete protection. Read that as a reason to identify the path being exercised, rather than treating every successful exclusion test as equivalent.
Other controls may change the outcome. A sandbox can restrict a process independently of an editor’s file-selection rules. The same test may behave differently in a local workspace, container or remote session. Record those conditions before interpreting an apparent success or failure.
Source context: Cursor: Ignore File
02
Prepare an isolated canary folder
Use a new folder containing only the supplied allowed and restricted marker files. Copy cursorignore.example to .cursorignore in that folder. The files are deliberately obvious synthetic text. They contain no credentials, customer data, repository instructions or executable code.
Keep the real repository closed while preparing the exercise. Check that the ignore pattern matches the intended relative filename and that no broader parent rule changes the test. A mistaken pattern is a configuration finding. It does not establish whether another Cursor access path respects the intended exclusion.
Source context: Cursor: Ignore File
03
Exercise four paths separately
Start with a permitted-file baseline so you know the client can read the isolated folder. Then review the excluded marker through the intended context or file-selection route. Record whether the UI hides it, the request is denied, an approval appears or the text reaches the conversation.
Terminal and MCP checks are separate rows. Use only the canary folder and an already approved, bounded file-reading capability. Do not install a server, grant new access or disable a sandbox merely to complete the matrix. Mark a path not applicable if the client does not expose it. A written observation is more useful than forcing every row to pass.
| Path | Question | Result to record |
|---|---|---|
| Context/reference | Can the excluded file be selected or used? | Hidden, denied, allowed or untested |
| File-reading tool | Does the selected tool return the marker? | Decision plus visible output |
| Terminal tool | Can the process read that same file? | Mode, approval and output |
| Approved MCP tool | What does the connected reader return? | Server scope and output, or not applicable |
Source context: Cursor: Ignore File
04
Interpret the result without overstating it
If the allowed marker cannot be read, resolve the baseline first. If an excluded marker appears, record the exact path and configuration before changing anything. A denial from a sandbox shows that sandbox’s decision, not necessarily enforcement by .cursorignore. Likewise, a hidden file picker does not establish a terminal restriction.
Public practitioners have reported different outcomes around .cursorignore and sandboxed containers. Those accounts help identify questions to test; they are not proof of today’s behaviour in your installed version. This guide supplies a procedure and blank results, not a reproduced vulnerability or a guarantee that a specific release prevents access.
Source context: Cursor community: context exposure question · Cursor community: sandbox and dev-container question
05
Turn the observation into an approval condition
Record the client version, OS, account, workspace location, execution mode and effective settings with the result. Keep the approved scope small enough that an engineer can repeat it after an upgrade. Retain the canary files separately from genuine restricted material.
If the organisation requires a file never to enter model context, do not rely on a result from one route while leaving others unresolved. Consider a narrower workspace or an independently enforced access boundary. Review supported endpoint policy controls as another layer, with their own test and evidence, rather than assuming they inherit the editor’s rules.
Source context: Aona: AI security coverage
Put it into practice
Cursor access-path canary lab
Compare context, file, terminal and approved MCP access without placing secrets in the test.
Synthetic marker files and unexecuted tests. No observed Cursor or Aona results are claimed.
| Route | Input | Observed |
|---|---|---|
| Allowed baseline | allowed-canary.txt | Untested |
| Excluded reference | restricted-canary.txt | Untested |
| File-reading tool | Same restricted marker | Untested |
| Terminal read | Same restricted marker | Untested |
| Existing approved MCP reader | Same folder only | Untested or not applicable |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Cursor access-path canary lab
Synthetic, unexecuted fixture. No real secrets, network addresses, agent instructions or MCP server are included.
Preparation
1. Put allowed-canary.txt, restricted-canary.txt and cursorignore.example in a NEW isolated folder with no other files.
2. Copy cursorignore.example to a file named .cursorignore in that folder. Do not overwrite a configuration in a real repository.
3. Open only this folder in your organisation-approved client. Record its version, account, OS and execution mode.
Manual observations
- Establish whether the approved context/file route can read allowed-canary.txt.
- Review whether the excluded file is offered by explicit reference and whether the client returns its marker.
- If approved for this isolated test, ask the existing terminal tool to read ONLY restricted-canary.txt. Do not disable restrictions to obtain an answer.
- If an already approved MCP reader is scoped to this folder, test the same marker there. Otherwise record NOT APPLICABLE. No new server or credentials are needed.
Use results.csv. Expected restriction is an organisation decision, not a documented result. Record output only from these synthetic files. These materials perform no API calls or commands automatically.
## Guide and source references
Canonical guide: https://aona.ai/resources/guides/cursorignore-terminal-mcp-file-access/
Source review: 2026-09-21
- Cursor: Ignore File: https://cursor.com/docs/reference/ignore-file
- Cursor community: context exposure question: https://forum.cursor.com/t/controlling-llm-context-exposure-in-cursor-cursorignore-shell-commands-and-fine-grained-allowlists/150898
- Cursor community: sandbox and dev-container question: https://forum.cursor.com/t/clarification-request-how-does-cursorignore-interact-with-auto-run-in-sandbox-inside-a-dev-container/159139
- Aona: AI security coverage: https://aona.ai/resources/ai-security-coverage/
allowed-canary.txtInspect
SYNTHETIC_D03_ALLOWED_MARKER_7Q9
This is deliberately permitted fixture text.
restricted-canary.txtInspect
SYNTHETIC_D03_RESTRICTED_MARKER_8R2
This is a fake marker, not a credential or company secret.
cursorignore.exampleInspect
# Copy to .cursorignore only in the isolated canary folder.
restricted-canary.txt
results.csvInspect
date,client_version,os,account,workspace_location,execution_mode,path,expected,observed,approval,marker_in_output,evidence
,,,,,,allowed baseline,DEFINE,UNTESTED,,,
,,,,,,excluded reference,DEFINE,UNTESTED,,,
,,,,,,file read,DEFINE,UNTESTED,,,
,,,,,,terminal read,DEFINE,UNTESTED,,,
,,,,,,approved MCP reader,DEFINE,UNTESTED OR NOT APPLICABLE,,,
Before you proceed
Keep these distinctions clear
- Testing a real secret
- A canary answers the access question without exposing a credential. Do not replace it with production data.
- Changing the mode mid-test
- Record the original configuration and the changed one as different results, including any approval granted.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint data paths alongside client access controls.
Cursor support is not a promise that every IDE, CLI, shell or MCP route is inspected or blocked. Native agent inspection remains limited rollout.
Bring the completed matrix and intended restriction to a scoped endpoint demonstration using synthetic material.
Review your use caseFAQ
Questions for this decision
Is .cursorignore the same as a sandbox?
Does an ignored file being absent from search prove it cannot be read?
Should I disable the sandbox to make the canary test work?
Have these fixtures been tested against my Cursor release?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Cursor: Ignore File
Describes .cursorignore patterns, context/file scope and terminal/MCP limitations.
vendor · checked 2026-09-21 - Cursor community: context exposure question
Dated practitioner concern about file selection, shell output and context boundaries; not a reproduced current flaw.
practitioner · checked 2026-09-21 - Cursor community: sandbox and dev-container question
Reports configuration-dependent observations that motivate recording environment and mode.
practitioner · checked 2026-09-21 - Aona: AI security coverage
States endpoint/path requirements and the limited scope of native agent inspection.
vendor · checked 2026-09-21