{"slug": "cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten", "title": "Cursor Agent Permissions Explained: What Runs Without Asking, and How to Tighten It", "summary": "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.", "body_md": "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.\n\nEverything 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.\n\n| Action | Default behaviour | \n|---|---|\n| Reading files, searching code | Runs without approval | \n| Editing files in the workspace | Runs without approval (written to disk immediately), except configuration files | \n| Editing configuration files (e.g. workspace settings) | Requires approval | \n| Terminal commands | Require approval, unless allowed by a Run Mode | \n| Connecting an MCP server | Requires approval | \n| Each MCP tool call | Requires approval, unless the tool is on an MCP allowlist | \n| Network requests from Cursor's own tools | Limited to GitHub, direct link retrieval and web search providers | \n\nTwo consequences follow immediately:\n\n`.cursorignore` for files the agent should never see\nBecause reading needs no approval, the main lever for sensitive files is `.cursorignore`, which blocks agent access to matching paths. A reasonable starting point:\n\n```\n# secrets and credentials\n.env\n.env.*\n!.env.example\n*.pem\n*.key\nsecrets/\nconfig/credentials*.yml\n\n# infrastructure state that often contains secrets\n*.tfstate\n*.tfstate.backup\n```\n\nTwo 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.\n\nBy 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.\n\nCursor describes these as **\"best-effort guardrails rather than a hard security boundary\"**, and that framing is correct. Practical advice:\n\n`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.\n\nBetter: 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.\n\nCursor supports VS Code-style workspace trust, but it is **disabled by default**. Enable it in user `settings.json`:\n\n```\n{\n  \"security.workspace.trust.enabled\": true\n}\n```\n\nCursor 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.\n\nCursor 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.\n\nEven with all of the above configured well:\n\n`package.json` scripts, a `Makefile`, or a CI workflow, and the next command you allowlisted (\nThe 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.\n\n[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.\n\n```\nnpm install -g @cirvix_ai/agent-control\ncirvix init\ncirvix policy check\n```\n\nThen replace the servers in your Cursor MCP config with a single gateway entry, keeping the original definitions in a separate upstreams file:\n\n```\n{\n  \"mcpServers\": {\n    \"cirvix\": {\n      \"command\": \"cirvix\",\n      \"args\": [\"gateway\", \"--servers\", \"/abs/path/mcp-upstreams.json\",\n               \"--policy\", \"/abs/path/cirvix.policy\"]\n    }\n  }\n}\n```\n\nCheck decisions without running anything:\n\n```\ncirvix check --action fs.read --resource .env\ncirvix audit verify\n```\n\nThe 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.\n\nCirvix AgentControl on GitHub: [https://github.com/CIRVIX/agent-control](https://github.com/CIRVIX/agent-control)\n\nDocs: [https://cirvix.com](https://cirvix.com)", "url": "https://wpnews.pro/news/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten", "canonical_source": "https://dev.to/umangcirvix/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten-it-i2c", "published_at": "2026-10-11 14:16:17+00:00", "updated_at": "2026-10-11 14:24:34.166274+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "agent-protocols", "ai-safety"], "entities": ["Cursor", "GitHub", "Visual Studio Code", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten", "markdown": "https://wpnews.pro/news/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten.md", "text": "https://wpnews.pro/news/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten.txt", "jsonld": "https://wpnews.pro/news/cursor-agent-permissions-explained-what-runs-without-asking-and-how-to-tighten.jsonld"}}