What Cursor typically generates and where the trust boundary is
Cursor does not generate one fixed kind of app. It edits whatever project you open, in whatever framework you chose, so the stack, hosting and database are yours. The question for review is different from tools that host your app: what did the agent change, what did it run, and what did it have access to while doing so.
Cursor's agent security documentation describes several guardrails. By default, terminal commands need your approval, though you can configure run modes to pre-approve trusted calls. Third-party tool connections through MCP need approval, and you can pre-approve specific tools with an allowlist. It says the agent cannot make arbitrary network requests, and that workspace trust, which offers a restricted mode for untrusted repositories, is off by default. It also advises keeping version control so you can revert unintended changes. Confirm all of this in the current documentation, since these settings change between versions.
The trust boundary therefore has two sides. On the code side, everything the agent writes is untrusted until you review and test it, in the same way you would treat a contribution from an unknown developer. On the environment side, everything you pre-approve widens what a mistake or a prompt injection hidden in a file, web page or issue can do on your machine.
The review checklist
| Area | What to verify | How to test on your own project | Pass condition |
|---|---|---|---|
| Terminal approvals | The agent cannot run commands unattended beyond what you chose deliberately. | Open the agent run mode settings and read the allowlist entries. | No broad entries, and nothing that deletes, pushes or publishes is pre-approved. |
| MCP servers | Every connected server is one you chose, from a source you trust. | Open your MCP configuration and list each server, command and token. | You can explain each server, and none holds broader credentials than needed. |
| Rules files | Project rules contain no secrets and no instructions to skip review. | Read every rules file in the repository and your user rules. | Rules describe conventions only, and were reviewed like code. |
| Untrusted repositories | You did not open a cloned unknown repository with full agent access. | Check the workspace trust setting and how you open third-party code. | Unknown code is opened in a restricted mode or a disposable environment. |
| Secrets in the repo | No keys were written into files, examples or tests by the agent. | Run the pattern search and the history search in the commands section. | No hits, or every hit has been rotated. |
| Diff review | Each AI change was read, especially auth, data and configuration files. | Review the diff by file with git before staging. | You can state what each changed file does and why. |
| Dependencies | Every package the agent added exists, is intended and is current. | Compare the lockfile diff against the prompt and run the audit. | No unfamiliar packages and no unaddressed high-severity advisories. |
| Running app | Authorization and input handling work when called directly. | Test each route with curl as an unauthenticated user and as the wrong user. | Rejected requests, and no cross-user data. |
Commands and queries to run
These run in your own repository. Start with the changes: which files did the agent touch, which packages did it add, and did any secret appear.
The last command lists any environment file that is tracked. The pass result is no output, apart from an example file that holds only placeholders.
git status --short
git diff --stat
git diff -- package.json package-lock.json
git diff | grep -nE "sk_live_|sk-[A-Za-z0-9]{20,}|BEGIN PRIVATE KEY|password\s*="
git log --all -p -S"BEGIN PRIVATE KEY" | head -50
npm audit --omit=dev
git ls-files | grep -E "^\.env" Treating the agent as a contributor with your permissions
The agent acts with your account's access. If your shell holds cloud credentials, a database connection string or a publish token, then a command the agent runs can use them. Reduce that exposure directly. Work against a development database with throwaway data, not production. Keep production credentials out of the shell where the agent runs. Prefer scoped, revocable tokens over personal admin keys.
Prompt injection is the concrete risk behind the approvals. Text in a file, dependency README, web page or issue can contain instructions aimed at the agent. Cursor's own guidance lists guardrails for this, but the most dependable control is that risky actions still need your explicit approval. Widening an allowlist because the prompts are annoying trades that control for convenience. If you want fewer prompts, narrow them to specific, read-only commands.
Finally, read the changes that matter most closely: authentication and session handling, database access and policies, payment or webhook code, configuration and infrastructure files, and anything touching secrets. Cursor's documentation notes that configuration file edits need consent first. Keep that default. Agents are generally good at making a feature work and less reliable at noticing what they exposed along the way.
Common mistakes with this workflow
- Approving everything to keep the agent moving, then forgetting the allowlist exists.
- Running the agent in a shell that has production credentials loaded.
- Committing large AI diffs unread because the tests pass. Passing tests do not check authorization.
- Adding an MCP server from a random guide without reading what it can do.
- Pasting a real key into a prompt or a rules file. Treat it as leaked and rotate it.
- Opening a downloaded repository with full agent permissions before reading it.
- Skipping version control, which removes your ability to undo an agent mistake.
- Trusting that a package the agent suggested exists and is the right one. Verify the name and publisher.
Keep it working
Re-read your run mode and MCP settings after each Cursor update and whenever you add a server. Run the diff and secret commands before every commit. Pass condition: no unattended command can change anything you cannot undo, no secret is tracked or in history, and each merged AI change has been read and tested against the running app.
Frequently asked questions
Does Cursor make my code secure?
No tool can promise that. Cursor documents guardrails for what the agent may do, but the code it writes is only as safe as your review and testing. Treat every diff as untrusted, and verify authorization and input handling by calling the running app directly.
Should I let the agent run terminal commands automatically?
Cursor's default is that commands need approval. If you loosen that, limit it to specific, read-only commands and keep anything that deletes, pushes, deploys or touches a database on manual approval. Check the current documentation for the available run modes.
What is prompt injection in this context?
It is text inside content the agent reads, such as a file, web page or issue, that tries to steer the agent into unintended actions. Your defenses are approvals for risky actions, restricted access for untrusted code and scoped credentials.
Where do I keep secrets so the agent does not see them?
Keep them in your platform's secret store or a local environment file that is ignored by git, and avoid pasting them into prompts. Check Cursor's current documentation on ignore files and privacy settings for what the editor can read or send.