playbook

Cursor AI agent permissions checklist for small teams

A practical checklist for deciding when Cursor agents may read files, run commands, use terminals, and touch repositories.

Bottom line

Cursor agents should not get the same freedom as a developer on day one. They can read repository context, help edit code, use terminal output, and influence changes that later reach production. A small team should approve agent behavior separately from ordinary autocomplete or chat.

Start with this rule:

Cursor agents may help inside approved low-risk repositories, but they may not handle secrets, run destructive commands, modify deployment settings, or act on production infrastructure without human approval.

This playbook extends the broader Cursor AI security risks review into an operating checklist.

Permission model

Use four levels instead of a single yes/no decision:

Level	Agent access	Good for	Default controls
Level 0	No agent use	Restricted repositories, regulated data, customer exports, production secrets	Block agent workflow.
Level 1	Read and suggest only	Docs, examples, tests, prototypes	Human copies or applies changes manually.
Level 2	Edit files, no terminal	Low-risk app code and internal tools	Code review and CI required.
Level 3	Edit files and use terminal output	Mature repos with tests and non-sensitive local data	Explicit command allowlist and reviewer approval.

Do not allow Level 3 access just because the repository is important. Important repositories usually need stricter controls, not broader agent permissions.

Repository approval checklist

Before allowing Cursor agents on a repository, answer:

• Does the repository contain real customer data, fixtures copied from production, or support exports?
• Does the working tree contain .env, private keys, session tokens, local credentials, or cloud config files?
• Can tests run without connecting to production systems?
• Can the agent see deployment scripts, Terraform, Kubernetes manifests, or CI secrets?
• Does the team have mandatory code review before merge?
• Does CI catch test, lint, type, and secret-scanning failures?
• Is there a rollback path if generated code causes a bug?

If a repository fails any of these checks, keep it at Level 0 or Level 1 until the issue is fixed.

Command rules

For small teams, approve command categories rather than individual prompts:

Command category	Default policy	Examples
Read-only inspection	Allow with care	git diff, git status, test file reads, package metadata reads
Local tests	Allow after setup	npm test, pytest, cargo test, type checks
Package installation	Require approval	npm install, pip install, lockfile changes
File deletion or movement	Require approval	recursive delete, generated cleanup, mass rename
Git history changes	Block by default	reset, force push, amend shared commits
Secret management	Block	reading .env, rotating keys, editing production secrets
Infrastructure changes	Block unless explicitly scoped	deploy scripts, cloud CLI, Terraform, Kubernetes
Network calls	Require approval	fetching remote scripts, calling APIs, uploading logs

If the agent suggests a command that you would not paste into a shared terminal in front of the team, do not run it.

Secret exposure controls

Cursor’s data-use documentation says Privacy Mode enables zero data retention for model providers, but Cursor may still store some code data to provide features. That makes secret hygiene non-negotiable.

Minimum controls:

1. Remove .env files from agent-visible folders.
2. Run local secret scanning before enabling agent workflows.
3. Keep customer exports, database dumps, and production logs outside the workspace.
4. Use fake fixtures for tests.
5. Rotate any secret that was pasted into a prompt, terminal output, chat, or generated file.
6. Teach developers to stop and report exposure quickly.

Privacy Mode is a baseline. It is not permission to expose credentials.

Human review rules

Every agent-generated change should pass the same gates as a junior developer’s first pull request:

• Human reads the diff.
• Human understands any dependency change.
• Tests run locally or in CI.
• Generated migrations, auth changes, and security-sensitive code get extra review.
• The reviewer checks whether the agent added logging that could expose customer data or secrets.
• The reviewer checks whether comments or test fixtures contain real identifiers.

Do not allow an agent to merge its own work.

Pilot plan

Use a two-week pilot:

Timeframe	Action
Day 1	Pick two low-risk repositories and set agent level for each.
Day 2	Remove secrets and real data from local workspaces.
Day 3	Run baseline tests and secret scanning.
Week 1	Allow Level 1 or Level 2 workflows only.
Week 2	Allow limited Level 3 commands only if Week 1 produced no incidents.
End of Week 2	Review failed commands, bad suggestions, test breakage, and developer feedback.

After the pilot, document approve, restrict, or block decisions in the Small Team AI Security Checklist.

Evidence checked

• Cursor data-use overview
• Cursor security
• Cursor models
• Small Team AI Security Checklist
• AI Tool Risk Checker

FAQ

Is Privacy Mode enough for Cursor agents?

No. Privacy Mode helps with model-provider retention and training posture, but agents still work with repository context, file content, terminal output, and prompts. You still need repository classification, secret scanning, command rules, and human review.

Should agents be allowed to run tests?

Usually yes, after the test command is known and safe. Tests that connect to production databases, real APIs, customer accounts, or paid resources should be blocked until they are redesigned.

Should agents edit deployment files?

Not during the first pilot. Deployment scripts, infrastructure files, CI secrets, and production configuration should stay human-owned until the team has a proven review workflow.

Recommended next step

Run the AI Tool Risk Checker for the Cursor workflow, then record the repository approval level in your checklist.