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

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; check it again after major releases, because defaults do change.

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:

.env
.env.*
!.env.example
*.pem
*.key
secrets/
config/credentials*.yml

*.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 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

Docs: https://cirvix.com