How to Secure Cursor: 12-Step Hardening Guide

How to secure Cursor in 12 steps

The work splits into three layers: what Cursor sees (codebase indexing, MCP, extensions), what Cursor’s output ships (review gates, branch protection, CI), and what reaches production (dynamic scan on deploy).

Cursor bundles Tab completion, Chat, Composer, Agent, and MCP. Each speeds up code, and each can land a bad auth pattern or leaked key on main if you only trust the diff highlighter.

Layer 1 - Lock down what Cursor sees (5-minute setup)

Step 1. Create a .cursorignore for every repo

Cursor’s codebase indexer ingests every file in the working tree by default, including .env, secrets in config, infrastructure-as-code with embedded credentials, and customer-data fixtures. Without an ignore file, these can be sent to the AI model with completions.

Create .cursorignore at the repo root:

# Secrets
.env
.env.*
*.pem
*.key
*.p12
*.pfx
secrets/
config/credentials.json
config/production.json
config/staging.json

# Infrastructure
terraform.tfvars
*.tfstate
*.tfstate.backup

# Customer data fixtures
fixtures/customers.json
fixtures/users.json
seeds/production.sql

# Build artifacts (also reduces noise)
node_modules/
.next/
dist/
build/

Verify in Cursor: open the file, confirm Cursor shows “Ignored” status.

Expand the ignore list when you add new secret-bearing paths (Stripe CLI config, gcloud ADC files, kubeconfig, .aws/credentials if ever in-repo). A quarterly git ls-files | grep -iE 'secret|credential|key|env' catches drift.

Step 2. Enable Privacy Mode

Settings → General → Privacy Mode → enabled.

Privacy Mode prevents Cursor from retaining code or training on it. Code still transits to the AI model for completions, but it isn’t stored server-side.

For Business plan: enforce at org level - Admin console → Policies → “Require Privacy Mode” → enable.

Privacy Mode does not stop a developer from pasting a production dump into Chat. Policy still matters.

Step 3. Audit MCP servers

Open ~/.cursor/mcp.json (macOS/Linux) or %APPDATA%\Cursor\mcp.json (Windows) and list every enabled MCP server. Each runs with full user permissions on your machine.

For each entry, confirm you installed it, still use it, and trust the publisher. Remove anything you can’t account for.

MCP runs code with your privileges. Prefer read-only tokens for GitHub/Slack MCP servers; never point MCP at production databases with write roles for casual coding sessions.

// Prefer scoped tokens via env, not hard-coded secrets in mcp.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GH_READ_TOKEN}" }
    }
  }
}

Step 4. Audit installed extensions

Cursor inherits VS Code’s extension model, so every extension runs with full IDE trust. List them:

Cmd/Ctrl+Shift+P → "Extensions: Show Installed Extensions"

Remove unused extensions and prefer verified publishers for anything that touches your codebase (formatters, linters, AI tools).

In high-security environments, disable auto-update until changelogs are reviewed. Updates install without a prompt.

Layer 2 - Gate what Cursor’s output ships (workflow controls)

Step 5. Branch protection on main

Without branch protection, Composer and Agent changes can reach main (and CI auto-deploy) without human review.

GitHub: Settings → Branches → main → Require pull request before merging → Require approvals (at least 1, ideally code owners).

GitLab equivalent: Settings → Repository → Push Rules + Protected Branches.

CODEOWNERS on **/auth/**, **/payments/**, .github/workflows/** forces the right reviewers when Composer touches high-risk paths.

Step 6. Required PR review on AI-generated commits

Add a PR template that asks contributors to disclose AI-generated portions, so reviewers know where to look.

.github/pull_request_template.md:

## AI-Generated Code

- [ ] This PR contains code generated by Cursor / Claude Code / other AI tools
- [ ] AI-generated portions noted in commit messages
- [ ] Security-sensitive sections reviewed (auth, payments, data access)

## Security checklist

- [ ] No new hardcoded secrets
- [ ] Input validation on every new endpoint
- [ ] Authorization (not just authentication) on resource access
- [ ] Error handlers don't expose stack traces

Step 7. CI security gate

Add a security scan to CI that blocks merge on critical findings. Static scan + dynamic scan if your deploy preview supports it.

GitHub Actions example:

- name: Security scan
  run: |
    # Static: secret detection
    npx gitleaks detect --source . --report-format sarif
    # Dependency audit
    npm audit --audit-level=high
    # Custom rules for AI-generation patterns
    npx semgrep --config=auto --error

For dynamic scan against the deployed preview, see Vibe Code Scanner - runs as a CI step against your preview URL.

Add Semgrep custom rules for the patterns below (NEXT_PUBLIC_*SECRET*, USING (true), open CORS). See SAST tools for AI code.

Step 8. Disable Composer auto-accept

Composer writes multiple files at once, and teams tend to accept changes without reading every file.

Settings → Composer → require explicit accept per file (verify the exact setting name in your version). It slows the workflow but forces a read of each diff.

Never auto-accept changes under middleware, auth, payments, IaC, and workflow YAML.

Step 9. Run Agent mode in feature branches only

Agent mode runs autonomously and can commit. Configure it to operate only in feature branches, never directly on main. Combined with step 5, Agent commits land in PRs that require review.

If Agent can run terminal commands, watch for curl | sh, broad rm, and package installs. Approve shell deliberately.

Layer 3 - Scan what reaches production

Step 10. Dynamic security scan on every deploy

Static scans catch some patterns. Dynamic scans of the running app catch BOLA, IDOR, RLS, and CORS issues that only surface at runtime.

Add a dynamic scan step to your deploy pipeline:

- name: Dynamic security scan
  run: |
    curl -X POST https://app.vibe-eval.com/api/scan \
      -H "Authorization: Bearer ${{ secrets.VIBEEVAL_TOKEN }}" \
      -d '{"url": "${{ env.PREVIEW_URL }}"}' \
      --fail

Block deploy on critical findings and alert on high ones.

Step 11. Quarterly .cursorignore review

New secret-bearing files get added over time, so update the .cursorignore from step 1. Quarterly, run git ls-files | grep -iE 'secret|credential|key|password|env' to find files it misses.

Step 12. Monthly MCP and extension audit

Repeat steps 3 and 4 monthly, since new MCP servers get installed during exploration and old extensions accumulate. Put the audit on a calendar invite.

The 12-step setup as a single command

For a fresh repo, the layer-1 setup is one block of work:

# Create .cursorignore from template
cat > .cursorignore <<'EOF'
.env
.env.*
*.pem
*.key
secrets/
config/credentials.json
terraform.tfvars
*.tfstate
fixtures/customers.json
EOF

# Add PR template
mkdir -p .github
# (copy the template from step 6)

# Enable git hook for secret scanning
npm install --save-dev gitleaks
echo 'npx gitleaks protect --staged' >> .husky/pre-commit

Common mistakes when securing Cursor

Skipping .cursorignore because “I’ll remember not to share secrets” - Cursor’s codebase indexing is automatic, so remembering doesn’t help.

Treating Privacy Mode as the only control - It only addresses retention. The model still sees the code, and the security of generated code is a separate problem.

Trusting the AI to add auth checks because the prompt mentioned auth - It often adds authentication but misses authorization. Required PR review is the gate.

Believing static scan in CI is enough - Use it alongside a dynamic scan of the deployed app.

Configuring policies but not enforcing them - Business plan policies bind only when SSO is required; without enforcement, individual users can opt out.

Installing MCP servers from blog posts without reading the package - Each server runs code as your user.

Letting Composer rewrite CI or auth “to make tests pass” - The agent can weaken assertions or remove middleware. Diff those files carefully.

Pastes of production .env into Chat - Privacy Mode does not make that safe.

Patterns Cursor ships most often

Common patterns in Composer output:

1. Auth without authorization - requireAuth present; no owner_id === session.userId.
2. NEXT_PUBLIC_ / VITE_ secrets - so the browser can “see the key.”
3. CORS * - to silence a local frontend/backend port mismatch.
4. SQL / ORM string concat from training data examples.
5. Unvalidated webhooks - Stripe/GitHub handlers that trust the body.
6. Package hallucination - npm install of a name that does not exist (or exists as malware).
7. Verbose 500s in production error handlers.
8. Missing rate limits on login, signup, and LLM proxy routes.

When reviewing a Cursor PR, search the diff for those eight before debating style.

# Quick hostile grep on a branch
git diff main...HEAD | grep -nE 'NEXT_PUBLIC_.*(SECRET|KEY)|dangerouslySetInnerHTML|USING \(true\)|cors\(\{ origin: .?\*'

Composer / Agent session runbook

1. Create a feature branch with a narrow ticket.
2. Confirm .cursorignore and Privacy Mode.
3. Disable unnecessary MCP for the session.
4. Prefer small Composer tasks over “rewrite the app.”
5. Read every file in the multi-file accept list.
6. Run tests locally; re-run security tests if the agent “fixed” failures.
7. Open PR with AI disclosure.
8. After preview deploy, dynamic scan.

Abort if the agent starts editing production Terraform with live credentials in the workspace.

How to verify Cursor hardening

Team rollout plan (2 weeks)

Week 1 - Local defaults

• Ship a company .cursorignore template into every repo.
• Require Privacy Mode in the handbook (and org policy if Business).
• Ban auto-merge for Composer/Agent branches.
• Document approved MCP servers.

Week 2 - Pipeline

• Add gitleaks + Semgrep + npm audit as required checks.
• Add dynamic scan against preview URLs for apps with auth/data.
• Schedule monthly MCP/extension review on the calendar.
• CODEOWNERS on auth/payments/workflows.

Solo founders: do Layer 1 the same day you install Cursor; add CI before public launch. See the solo founder pre-launch checklist.

Cursor vs Claude Code vs Cline (security)

The controls transfer between tools under different names. If you use more than one agent, standardize on ignore files, secret scanning, and dynamic deploy scans.

Rules and .cursorrules hygiene

Project rules (.cursorrules / project instructions) steer generation. Example security rules:

- Never commit secrets; use env vars.
- Every new HTTP route requires auth middleware and ownership checks.
- Prefer parameterized queries; no string-built SQL.
- Do not weaken CI security jobs to make tests pass.
- New Supabase tables ship with RLS in the same change.
- No dangerouslySetInnerHTML with user content.

Review rules files in third-party templates and forked repos like code, since malicious rules are a real path. See indirect prompt injection when rules pull remote content.

Composer sessions without shipping BOLA

Composer optimizes for feature completeness. Add a standing rule that every new endpoint ships with a negative authz test.

Related resources

• Is Cursor Safe? - IDE-level audit
• Cursor Security Risks - 12 patterns in Cursor-generated code
• Cursor Enterprise Security - Business plan controls
• Vibe Coding Vulnerabilities - full vulnerability taxonomy
• Vibe Code Scanner - automated dynamic scan
• Token Leak Checker - finds secrets in deployed bundles
• Package Hallucination Scanner - finds AI-invented dependencies
• OWASP Top 10 for AI Code
• How to Secure Claude Code - parallel agent hardening
• How to Secure Cline - open-source agent controls