Cursor app security checklist for AI built code

Cursor lets you ship fast but AI generated code can hide secrets, vulnerable packages and overly broad tool access. This checklist shows how to review Cursor rules, lock down .cursor/mcp.json with env var references, gate dependencies and secrets and capture SARIF for release evidence. Pair it with LyraShield as release assurance for AI built apps. Start with our broader vibe coding security guide for baseline controls then apply the Cursor specific steps below.

Why cursor builds need a review

Cursor composes code from prompts, editor context and connected MCP servers. That speeds delivery but widens the surface for prompt injected code, leftover credentials and transitive dependency risk. AI assisted edits can appear in many files in one session, so manual spot checks miss patterns.

A lightweight pre release review helps. If you also ship with other builders, compare patterns in our Lovable app security checklist to see how rules hardening and MCP lockdown translate across tools. For Cursor, focus on three risk areas: rules that over grant trust, MCP servers with broad tool scopes and secrets that leak into the repo.

Map your review to trusted references. OWASP Top Ten covers injection and misconfiguration patterns you will see in AI built projects, see OWASP Top Ten. CWE entries like CWE 798 for hard coded credentials give precise weakness language for tickets. The MCP spec defines auth and tool discovery norms at MCP authorization spec.

Harden rules and project context

Cursor rules live in .cursor/rules and in Cursor settings. Treat them as security policy, not just style hints. Version them in git and review changes like code.

Check that rules forbid risky behaviors: no direct production database writes, no copying secrets into code, no disabling auth checks for debugging and leaving it disabled. Require that generated API routes include input validation and auth middleware. Document the sources the agent may read, for example only src and docs, not .env or secrets folders.

Pin your stack guidance in rules: specify allowed package registries, minimum Node version and lockfile update policy. Cursor docs describe rules loading at Cursor rules. Make rules explicit about shell usage: deny destructive shell patterns like rm recursive and require confirmation for database migrations.

Add a final rule: any change that touches auth, payments or file upload must add a test and be flagged in the pull request description. That creates an audit trail for verification.

Lock down MCP config in .cursor/mcp.json

Cursor loads MCP servers from .cursor/mcp.json using a mcpServers object. This file is where credential leakage often happens.

Current setup: follow the Cursor integration guide with pinned @lyrashield/mcp@0.2.12 and authenticate local stdio separately using npx -y lyrashield@0.2.14 login --oauth. The Agent Plugin package 0.1.31 is published; its public listing and authenticated client runtime acceptance remain pending. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. Confirm client discovery, then make an authenticated read-only workspace call.

Secure pattern:

{
  "mcpServers": {
    "lyrashield": {
      "command": "npx",
      "args": ["-y", "@lyrashield/mcp@0.2.12"],
      "env": {
        "LYRASHIELD_API_KEY": "${env:LYRASHIELD_API_KEY}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${env:DATABASE_URL}"
      }
    }
  }
}

Key hardening points:

• Use ${env:VAR} interpolation, not raw tokens. Env vars stay outside git.
• Keep .cursor/mcp.json in git but validate it in CI that no literal sk keys appear. Use a secret scanner before merge.
• Limit tool scope per server. Prefer servers that expose only needed methods, like read only database tools for code generation context.
• Separate local and shared config. Local overrides should not be committed with personal paths.
• For remote MCP, Cursor can call remote MCP endpoint with Bearer lsk key via env var. See MCP spec overview for transport and auth expectations.

Review the MCP config on every pull request that changes tooling. Treat new MCP servers like dependencies, with an owner and review date.

Restrict agent permissions and approval mode

Cursor agent mode can read files, run commands and edit code. Scope that power.

Set approval mode to require confirmation for shell commands, network calls and file writes outside src. Disable auto run for migrations and package installs on feature branches. Enable it only after tests pass in CI.

Create an allow list for commands the agent may run: npm run lint, npm run test, npm run build. Deny curl with secrets, direct git push to main or unscoped docker commands. Document these checks in your pull request template so reviewers know what to expect.

The Cursor docs cover terminal and tool approval at Cursor tools. Pair that with least privilege on your cloud provider: the developer token used for AI assisted work should not have production deploy rights. Use short lived credentials for staging and require human approval for production.

Log agent actions when possible. If Cursor generates a summary, paste it into the pull request so security review has context on what was automated versus hand written.

Gate dependencies and secrets before merge

AI coding assistants often add packages to solve a task. That accelerates delivery but can introduce vulnerable or malicious dependencies.

Run SCA on every pull request. OSV provides a broad vulnerability database at OSV database. For Node projects, run npm audit or pnpm audit and require high severity advisories block merge. Record the baseline: if you must ship with a known advisory, document the exception, owner and mitigation date.

For secrets, run gitleaks or similar and fail on new findings. Check .env.example for placeholder patterns only, never real values. Validate that no bearer tokens, private keys or lsk keys are committed. The docs on SARIF upload for secret scanning results are at SARIF support.

Add a pre commit hook that runs secret scanning locally and enforce the same scan in CI. Require environment file changes include reviewer approval from security owner.

Capture release evidence with SARIF

Collect evidence that your checklist ran. SARIF gives you a standard format for security findings that GitHub code scanning can render.

Steps:

1. Run lint, typecheck, dependency audit and secret scan.
2. Convert each tool output to SARIF.
3. Upload SARIF to GitHub with actions upload sarif.
4. Store the SARIF artifact with the release tag.

See GitHub guidance at GitHub SARIF upload. Keep a changelog entry per release listing new MCP servers, new dependencies and any risk exceptions.

Capture screenshots or logs for manual checks that cannot be automated. A simple markdown file in docs slash security evidence with dates, tools run and reviewers adds verification value.

Check	Where to configure	What good looks like
Rules hardening	.cursor/rules, settings	No destructive commands, auth required on routes, allowed registries pinned
MCP lockdown	.cursor/mcp.json mcpServers with env interpolation	No raw keys in git, least privilege servers, reviewed on PR
Agent permissions	Cursor approval mode, command allow list	Shell requires confirm, no prod deploy from agent token
Dependency gate	CI with OSV and npm audit	High severity blocks merge, exceptions documented
Secret gate	gitleaks, env file policy	No secrets in repo, env vars from manager, SARIF uploaded
Release evidence	GitHub Actions SARIF	SARIF on PR and main, evidence file per release

Why pair cursor with LyraShield

LyraShield AI is release assurance for AI built apps, see https://lyrashieldai.com. The loop is target, review, evidence, fix, retest, report: detection stays separate from proof, recorded scans contribute to an assurance record and fix proposals are approval gated so PR execution is blocked until a server generated patch is bound to the exact approval.

MCP integration fits Cursor. Local stdio via npx -y @lyrashield/mcp@0.2.12 keeps tokens in env vars and remote at https://app.lyrashieldai.com/api/mcp accepts Bearer lsk key for team use. The GitHub Action is diff-aware and emits SARIF candidate findings for changed files; it does not mark them as confirmed results or create a fix. SARIF output targets GitHub code scanning so results appear in your pull request.

Status note: LyraShield is live in open beta with open registration. The scan pipeline, findings and evidence, approval-gated fix proposals, retests, reports, billing and Local/Desktop flows are implemented. MCP and the runner-local GitHub Action are available now; production availability remains bounded by retained evidence and release gates. Automatic server-generated Fix PR execution is not enabled and self-serve checkout is live.

Pairing gives you a consistent loop across editors while Cursor handles fast iteration locally.

Launch checklist and next steps

Run through this before each release and keep the evidence.

1. Verify .cursor/mcp.json has no raw secrets and all servers use ${env:}.
2. Confirm rules file includes auth and input validation requirements.
3. Check agent approval mode is on for shell and network.
4. Run dependency and secret scans and upload SARIF.
5. Document any risk exceptions with owner and date.
6. Build and run basic auth tests.

When ready, apply the same evidence pattern using our AI app security checklist tool and create an account at https://lyrashieldai.com to start building assurance records today.

For related tool patterns, also review Bolt app security checklist and V0 app security checklist to keep controls consistent across your AI builder fleet.