playbook
Cursor rules for repositories with secrets
A practical rule set for using Cursor in repositories that may contain API keys, private keys, .env files, customer fixtures, or deployment credentials.
Bottom line
If a repository contains secrets, treat Cursor as a high-risk developer workflow until the repository is cleaned, scanned, and approved. Rules help, but rules are not a secret-management system. Your default should be:
Cursor may work in approved repositories only. It must not read, summarize, edit, generate, commit, or ask for production secrets, private keys, customer exports, deployment credentials, or real .env values.This page gives a small team a copyable policy for Cursor repositories that might contain API keys, private keys, .env files, cloud credentials, local database URLs, customer fixtures, or deployment scripts.
For broader rollout risk, start with the Cursor AI security risks review and the Cursor AI agent permissions checklist.
Repository decision table
Classify the repository before anyone opens it in Cursor:
| Repository state | Cursor default | Required fix before wider use |
|---|---|---|
| No secrets, no customer data, good tests | Allow pilot | Add project rules and secret scan in CI. |
Local .env files exist but are gitignored | Restrict | Move secrets outside the workspace or use fake local values. |
| Historical commits contain real credentials | Block | Rotate exposed secrets and clean history only with a planned process. |
| Customer exports, production logs, or support tickets are present | Block | Replace with redacted fixtures. |
| Deployment, Terraform, Kubernetes, or CI secret files are present | Restrict | Require explicit human approval for changes and terminal commands. |
| Private keys, signing keys, or cloud root credentials are present | Block | Remove from repo and rotate before AI-assisted work. |
The practical rule is simple: Cursor can only help safely when the workspace is already safe enough for an external reviewer to inspect.
Project rule template
Put this in a Cursor project rule or the repo’s agent instructions:
# Secret handling rule
You are working in a repository that may contain sensitive engineering material.
Do not request, reveal, summarize, transform, log, or commit:
- API keys, access tokens, session tokens, OAuth secrets, SSH private keys, signing keys, or certificates.
- .env values, local database URLs, cloud provider credentials, production credentials, or CI/CD secrets.
- Customer exports, support tickets, production logs, payment data, health data, legal records, or regulated personal data.
If a file appears to contain secrets:
1. Stop reading the file.
2. Say that the file appears sensitive.
3. Ask the human to provide a redacted fixture or non-sensitive example.
4. Do not copy values into chat, generated code, comments, tests, commit messages, or logs.
When changing code:
- Prefer fake placeholders such as EXAMPLE_API_KEY, test-token, or localhost-only credentials.
- Do not add new secret-like literals.
- Do not weaken .gitignore, .cursorignore, secret scanning, CI, or review gates.
- Do not run destructive commands, credential commands, cloud CLIs, deployment commands, or git history rewrite commands without explicit human approval.Keep this rule short enough that developers can read it. A rule that nobody understands will not protect the repository.
.cursorignore starter
Cursor documents .cursorignore and .cursorindexingignore as ways to control file access and indexing. Use them as a guardrail, not as your only control. Cursor’s docs also warn that agent-initiated tool calls, such as terminal and MCP server access, are not blocked by .cursorignore.
Start with:
# Local secrets
.env
.env.*
!.env.example
!.env.template
# Common credentials
**/credentials.json
**/secrets.json
**/*.pem
**/*.key
**/id_rsa
**/id_ed25519
# Customer or production data
exports/
customer-data/
support-dumps/
production-logs/
*.sql
*.sqlite
*.db
# Local tool state
.aws/
.azure/
.gcloud/
.kube/Also keep .gitignore and repository-level secret scanning. .cursorignore can reduce exposure inside Cursor, but it does not rotate exposed credentials, clean Git history, or replace review.
Approval checklist
Before approving Cursor for a repository, record the answer:
| Question | Pass condition |
|---|---|
| Are real secrets absent from the working tree? | Only fake .env.example or local placeholders remain. |
| Has the repository been scanned? | Local and CI secret scans pass. |
| Is GitHub secret scanning enabled where available? | Secret scanning and push protection are enabled or explicitly tracked as a gap. |
| Are customer fixtures synthetic or redacted? | No copied support tickets, production logs, or database dumps. |
| Are project rules committed or documented? | Cursor rules or agent instructions include secret-handling rules. |
| Are terminal commands controlled? | Deployment, cloud, credential, destructive, and git-history commands require approval. |
| Is code review mandatory? | AI-generated changes cannot bypass review and CI. |
If any answer is unknown, keep the repository restricted.
CI and GitHub controls
Do not rely on developer discipline alone. Add automated checks:
| Control | Why it matters |
|---|---|
| Pre-commit or local secret scan | Catches obvious leaks before review. |
| CI secret scan | Catches leaks from any developer or branch. |
| GitHub secret scanning alerts | Helps detect supported exposed secrets in repository content and history. |
| Push protection | Blocks many supported secret types before they land in the repository. |
| Required review | Forces a human to inspect AI-generated diffs. |
| Required tests | Reduces the chance that AI-generated changes break production behavior. |
GitHub’s secret scanning documentation says alerts can be generated when supported secrets are found in a repository, and GitHub’s enablement docs describe push protection as a way to proactively block pushes containing supported secrets. Treat those as backstops. They do not prove the repository is free of every possible secret.
Developer operating rule
Give developers one clear rule:
If Cursor asks for a secret, touches a secret-looking file, prints a token, suggests weakening ignore rules, or wants to run a credential or deployment command, stop and move the task back to human review.That rule should apply even when Privacy Mode is enabled. Cursor’s Privacy and Security docs describe Privacy Mode as a data-handling control, not as permission to put production credentials into prompts, terminal output, or generated files.
Rollout plan
| Day | Action |
|---|---|
| 1 | Pick two low-risk repositories and add the secret-handling project rule. |
| 2 | Add or tighten .cursorignore, .gitignore, and fake .env.example files. |
| 3 | Run local secret scans and remove copied customer data or production logs. |
| 4 | Enable GitHub secret scanning or document why it is not available. |
| 5 | Allow Cursor for read/suggest/edit workflows, but keep deployment and credential commands manual. |
| 10 | Review AI-generated diffs for secret-like literals, unsafe logging, and fixture quality. |
| 14 | Decide whether the repository stays approved, needs more controls, or returns to restricted status. |
Record the result in the Small Team AI Security Checklist.
Evidence checked
- Cursor ignore files documentation
- Cursor rules documentation
- Cursor privacy and security documentation
- GitHub secret scanning documentation
- GitHub secret scanning enablement documentation
- AI Tool Risk Checker
- Small Team AI Security Checklist
FAQ
Can .cursorignore protect secrets by itself?
No. It is useful, but it is not enough. Cursor’s docs describe important limits around agent-initiated tool calls. You still need to remove secrets, scan repositories, control terminal use, and require code review.
Should .env files be in the same workspace as Cursor?
Avoid it for company repositories. Use fake local values, a secure secret manager, or environment injection outside the repository. If a real .env file is present, treat the repository as restricted until the team approves the workflow.
Are project rules enough to stop the model from exposing a secret?
No. Rules are instructions, not hard security boundaries. Use them to make the desired behavior explicit, then back them up with ignore files, secret scanning, branch protection, review, and developer training.
What if Cursor already saw a real API key?
Assume the key may be exposed. Rotate it, remove it from files and history where appropriate, check logs, and record the incident. Do not keep using the same credential because it was “only pasted once.”
Recommended next step
Run the AI Tool Risk Checker for each Cursor repository. If the result is high risk, use the Small Team AI Security Checklist to record the owner, blocked data types, secret-scanning status, and review rule before developers use Cursor on that codebase.