Cursor Agent Permissions Explained: What Runs Without Asking, and How to Tighten It

A developer's guide details Cursor's default agent permissions, showing that the agent reads files, searches code and edits workspace files without approval, while terminal commands, configuration edits and MCP tool calls require approval unless allowlisted. It recommends tightening defaults with .cursorignore for secrets, named read-only MCP tool allowlists, enabling VS Code-style workspace trust (off by default), and hooks for rules pattern allowlists cannot express, noting Cursor calls these "best-effort guardrails rather than a hard security boundary.

Cursor's agent can read your codebase, edit files, run terminal commands and call MCP tools. How much of that happens without asking you is controlled by a handful of settings that are easy to skim past. This guide explains Cursor agent permissions as they work by default, what each control actually governs, and the gaps worth closing for real projects. Everything below about Cursor's defaults comes from Cursor's Agent Security documentation https://cursor.com/docs/agent/security ; check it again after major releases, because defaults do change. | Action | Default behaviour | |---|---| | Reading files, searching code | Runs without approval | | Editing files in the workspace | Runs without approval written to disk immediately , except configuration files | | Editing configuration files e.g. workspace settings | Requires approval | | Terminal commands | Require approval, unless allowed by a Run Mode | | Connecting an MCP server | Requires approval | | Each MCP tool call | Requires approval, unless the tool is on an MCP allowlist | | Network requests from Cursor's own tools | Limited to GitHub, direct link retrieval and web search providers | Two consequences follow immediately: .cursorignore for files the agent should never see Because reading needs no approval, the main lever for sensitive files is .cursorignore , which blocks agent access to matching paths. A reasonable starting point: secrets and credentials .env .env. .env.example .pem .key secrets/ config/credentials .yml infrastructure state that often contains secrets .tfstate .tfstate.backup Two caveats. First, .cursorignore governs Cursor's own file access; a terminal command the agent runs cat .env is a separate route, governed by your command approvals. Second, ignoring a file is not the same as the secret not being on disk. The strongest version of this control is not having production secrets in the working tree at all. By default every terminal command asks. That is safe and quickly exhausting, which is how people end up approving everything. Run Modes let trusted commands run without prompting, ranging from a simple allowlist up to an Auto-review classifier. Cursor describes these as "best-effort guardrails rather than a hard security boundary" , and that framing is correct. Practical advice: npm test , npm run lint , git status , git diff . python , node , curl , bash . A prefix like python -c "<anything " . npm test && curl … | sh is a different command from Every MCP connection needs your approval, and each tool call needs approval too, unless you pre-approve specific tools with an MCP allowlist. The temptation is to allowlist a whole server once it seems well behaved. Better: allowlist read-only tools by name list issues , get file contents and keep anything that writes, deletes, posts or deploys on manual approval. And review what each server can reach — a filesystem server rooted at your home directory makes "read-only" a much bigger promise than it sounds. Cursor supports VS Code-style workspace trust, but it is disabled by default . Enable it in user settings.json : { "security.workspace.trust.enabled": true } Cursor notes that restricted mode breaks AI features, and recommends opening untrusted repositories in a basic text editor instead. Organisations can enforce the setting through MDM. Cursor also supports hooks, which let you run your own scripts around agent actions. If you need rules a pattern allowlist cannot express — "allow git push only to branches starting with agent/ ", or "block any command that mentions a path outside the repo" — hooks are where that logic lives, and it can be tested like normal code. Even with all of the above configured well: package.json scripts, a Makefile , or a CI workflow, and the next command you allowlisted The mitigations are mostly hygiene — version control before delegating, reviewing diffs to scripts and CI files, narrow tokens — plus a policy decision point for the actions that matter. Cirvix AgentControl https://github.com/CIRVIX/agent-control is an open-source authorization layer you can put in front of Cursor's MCP servers. Cursor talks to cirvix gateway as its only MCP server; the gateway launches your real servers and evaluates every routed tool call against a policy file before forwarding it — permit , hold for a named approver, or deny , with deny as the default. npm install -g @cirvix ai/agent-control cirvix init cirvix policy check Then replace the servers in your Cursor MCP config with a single gateway entry, keeping the original definitions in a separate upstreams file: { "mcpServers": { "cirvix": { "command": "cirvix", "args": "gateway", "--servers", "/abs/path/mcp-upstreams.json", "--policy", "/abs/path/cirvix.policy" } } } Check decisions without running anything: cirvix check --action fs.read --resource .env cirvix audit verify The boundary matters: the gateway governs MCP calls routed through it. Cursor's built-in file reads, edits and terminal commands do not travel over MCP, so they remain governed by Cursor's own permissions above. Use both: Cursor's controls for built-ins, a policy layer for the third-party tools that hold your credentials. Cirvix AgentControl on GitHub: https://github.com/CIRVIX/agent-control https://github.com/CIRVIX/agent-control Docs: https://cirvix.com https://cirvix.com