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.

The default permission model, in plain terms

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:

1. Reads are free. If a file is in your workspace and not ignored, assume the agent can read it.
2. Edits land before you review them. Cursor's docs warn that with auto-reload enabled, agent changes may execute before you look at them — think dev servers that restart on file change, or test watchers.

Control 1: .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.

Control 2: Run Modes for terminal commands

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:

• Allowlist exact, read-only or project-local commands: npm test, npm run lint, git status, git diff.
• Avoid allowlisting interpreters and network tools by prefix (python, node, curl, bash). A prefix like python allows python -c "<anything>".
• Remember that command matching is about the string the agent submits. npm test && curl … | sh is a different command from npm test, and your allowlist should treat it that way.

Control 3: MCP approvals and the MCP allowlist

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.

Control 4: workspace trust for unfamiliar repositories

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.

Control 5: hooks for custom checks

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.

The gaps worth closing

Even with all of the above configured well:

• Workspace edits need no approval. An agent can rewrite package.json scripts, a Makefile, or a CI workflow, and the next command you allowlisted (npm test) runs the modified script.
• Allowlists match strings, not effects. Equivalent commands spelled differently can slip past or get stuck.
• MCP servers run with your credentials. The approval prompt shows a tool call; it does not show what token the server will use.

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.

Adding a policy layer for MCP calls

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.

Quick checklist

• [ ] .cursorignore covers secrets and state files
• [ ] Run Mode allowlist contains exact commands, no interpreter prefixes
• [ ] MCP allowlist limited to read-only tools by name
• [ ] Workspace trust enabled for machines that open unfamiliar repos
• [ ] Diffs to scripts and CI files reviewed before running them
• [ ] MCP servers scoped, pinned and holding narrow tokens

---

Cirvix AgentControl on GitHub: https://github.com/CIRVIX/agent-control
Docs: https://cirvix.com