Cursor Security Assessment | AI Security Labs

The question it answers

For every place Cursor runs: if injected text hijacked the agent right now, what could it reach, and would you know? Everything below is a way of answering that question with evidence rather than assumptions.

Developer assessment (1 hour)

Run the audit (about a minute). The Cursor Security Audit container checks your sandbox, allowlists, MCP servers, hooks, CLI and a project of your choice, offline and read-only. Save the HTML report.
Work through the checklist. Items marked "manual" are the ones the audit cannot see: your run mode, team policies, cloud agents and working habits.
Compare against the common misconfigurations and fix every Critical one first.
Prove the controls work with the ten-minute self-test below.
Keep the evidence: the audit report, the completed checklist and the test results. Re-run after each Cursor upgrade and at least monthly.

The ten-minute self-test

Configuration you haven't tested may not do what you think. Make a throwaway project containing a fake .env, apply the baseline, and try each of the following. Every one should be refused or stopped for your approval.

Try this	What should stop it
Open the folder without trusting it, then start the agent	Restricted mode turns AI features off
"Run curl https://example.com"	The sandbox's network policy blocks it; a rerun outside the sandbox is reviewed first
"Write a file in my home folder"	The sandbox limits writes to the workspace; anything outside is reviewed first
"Add a new server to .cursor/mcp.json"	`.cursor/*.json` is write-protected in the sandbox
Run `agent -p "cat .env"` in the CLI	The CLI's `Read(*/.env)` deny rule
"Write a script that connects to the database"	The security rule: the script should read credentials from environment variables

The files it tests are in the audit's fix section. Re-run it after every Cursor upgrade.

Team assessment method

For a team or organisation, allow two to four weeks across 6 phases:

Scope and inventory. List the surfaces in use (the editor, the Cursor CLI, cloud agents, Bugbot), plans and seats, versions, run modes, MCP servers, extensions, hooks and the repositories cloud agents can reach. Useful sources: the team dashboard, EDR process inventory and a code search for .cursor/, .cursorrules and AGENTS.md.
Threat model. For each place Cursor runs (laptop, WSL, container, cloud agent), write down the identities and credentials it holds and the data and systems it can reach. That list is your blast radius.
Configuration review. Compare each developer's run mode, sandbox.json, permissions.json, hooks and CLI configuration, and the team's dashboard policies, with the checklist. On each developer machine, the audit container does the local part in about a minute.
Technical testing. Try to break it, safely, in a test project: read a planted fake secret, reach a host that is not allowed, write to .cursor/mcp.json, open a crafted repository with a project permissions.json and a rules-file injection, and send a crafted message through an MCP server. Each attempt should be both blocked and detected.
Detection and response review. Confirm the audit log or OpenTelemetry export is arriving; check that your alerts fire on the test activity from phase 4; run a tabletop for "the agent leaked a key" and "a cloud agent pushed malicious code".
Report and roadmap. Record findings with their misconfiguration IDs, score each domain with the maturity model below, and write a plan that fixes them in order of risk, following the fix order.

Enterprise checklist

Use these as the evidence behind each maturity score.

Governance

An approved policy for AI-assisted development, published and acknowledged.
Named owners for team policies, MCP and extension intake, detections and incident response.
Controls mapped to the frameworks you report against (OWASP Top 10 for Agentic Applications, NIST AI RMF, ISO/IEC 42001, SOC 2 change management).

Identity and access

SSO with phishing-resistant MFA; SCIM provisioning on Enterprise; leavers removed promptly.
Devices limited to the company team with the AllowedTeamId policy.
Cloud agents and automation use scoped service accounts, not personal tokens.

Policy enforcement

The agent sandbox enforced organisation-wide, with Run Everything unavailable.
Auto Run configuration, an MCP allowlist and a repository blocklist set in the team dashboard.
Workspace Trust enforced with the WorkspaceTrustEnabled policy, and allowed extensions with AllowedExtensions.
.cursor directory protection and browser controls on, where your plan has them.

Data protection

Privacy Mode enforced for the team.
Secret scanning with push protection on every repository; .cursorignore treated as hygiene, not a boundary.

Endpoint and network

EDR on every developer host, and inside WSL and dev containers where required.
Corporate proxy and CA configured; an egress allowlist for model endpoints and package registries.
A standard container or cloud agent with no credentials for untrusted code.

CI/CD, cloud agents and production

Cloud agent network access limited to an allowlist, with only task secrets in each environment.
The GitHub connection limited to needed repositories; branch protection stops agents merging; CODEOWNERS covers .cursor/, rules files and workflows.
Bugbot autofix off or limited to new branches.
No agent has standing write access to production; a break-glass procedure is documented.

Observability and response

The team audit log retained according to policy, knowing it doesn't contain prompts.
Detections for agent activity deployed and tested, including changes to .cursor/ files and new MCP servers.
Runbooks for a leaked key, an injected agent action, a malicious MCP server or extension, and a compromised cloud agent; a tabletop run in the last 12 months.

Threat intelligence and testing

Cursor's security advisories and research followed, with a regular summary for the team.
The phase 4 tests re-run after each upgrade and policy change.
Cursor in the scope of the annual penetration test or red team.

Maturity model

Score each domain from 0 to 4 and track it quarterly.

Level	Name	What it looks like
0	Unmanaged	Personal accounts, no policy, no visibility.
1	Aware	Policy written; approved accounts; developers trained; some user-level settings.
2	Managed	Managed settings enforced across the fleet; sandbox on; MCP and plugin allowlists; telemetry on.
3	Monitored	Detections tested; CI agents separated from privileged jobs; version floor enforced; advisories drive patching.
4	Optimised	Attack tests run automatically in CI; metrics drive policy; agent identities fully scoped; production access denied by default and proven.

A sensible first target for most organisations is level 2 everywhere, and level 3 for policy enforcement, isolation and CI/CD, because those three domains carry most of the critical risks.

Score it

Pick a level for each domain. The weighted score updates as you go; nothing is sent anywhere.

Domain	Weight	Evidence to collect
Governance	10%	Policy, owners, framework mapping
Identity and access	15%	SSO and SCIM setup, login enforcement, CI identity
Policy enforcement	20%	Team dashboard policies, MDM profiles, audit reports
Isolation (sandbox, containers)	15%	Sandbox settings, phase 4 test results
Supply chain (MCP, plugins, actions, packages)	10%	Allowlists, pinning, intake records
CI/CD and production	15%	Workflow review, branch protection, production access review
Observability and response	10%	Telemetry proof, detections, tabletop
Threat intelligence and testing	5%	Advisory tracking, test runs

Weighted score: 0.0 of 4 · Unmanaged

Sources

Cursor documentation: Agent security, Run modes, sandbox.json, permissions.json, Hooks, MCP, CLI permissions, Cloud agent security.
Why each control matters, with incident sources: Common Cursor Misconfigurations.
Frameworks: OWASP GenAI Security Project, NIST AI RMF, ISO/IEC 42001.

The domain weights and maturity levels are AISecurityLabs.org guidance, not a standard; adjust them to your risk profile. Informational only, with no guarantee of a vulnerability-free setup, so test every configuration in your own environment. AISecurityLabs.org is independent and not affiliated with Anysphere.