FirstOpsFirstOps
Sign in
Reference·7 min read

Cursor Security

A reference guide to the security model of Cursor: what it can access, how it can fail, and the controls to put in place before you let it run against sensitive code and production credentials.

AD
Anshal Dwivedi

Cursor Security#

A working reference on the security model of Cursor — what the agent can access inside an IDE, how it can be manipulated, and the controls that matter before it runs on a repo with production credentials.

The short version#

Cursor is a coding agent embedded in an IDE. It reads the open project, the files in the workspace, the shell it invokes, and — through tool integrations and MCP servers — a widening surface of external systems. Like other coding agents, its security posture is shaped by three properties:

  1. It inherits the developer's local credentials and access.
  2. It consumes untrusted input as part of its work — file contents, documentation pages, PR comments, search results, MCP responses.
  3. It executes actions — edits files, runs commands, opens PRs, interacts with external services.

This is a reference for teams that use Cursor seriously and want to understand what they are actually trusting.

What Cursor can access#

A Cursor install, on a default developer machine, has transitive access to:

  • The workspace and filesystem — all files in the currently open project, plus any file Cursor follows via imports, references, and tool calls. This is not sandboxed to a single repo directory in practice.
  • Developer credentials on disk — ~/.aws/credentials, ~/.ssh/, ~/.kube/config, .env files in projects, password-manager dump files, SSO token caches. Any file the developer's user account can read, the agent can read.
  • The shell — commands run by the agent execute as the developer, with all of their environment variables, network access, and local privileges.
  • Cloud CLI sessions — any aws, gcloud, az, kubectl, gh session already logged in is effectively delegated to the agent.
  • External APIs via tools and MCP servers — configured MCP servers, the agent's indexer, and its web tools. Each of these is an independent credential perimeter.
  • Source repositories — including private ones, via the developer's Git credentials.

The attack surface that matters#

The most important security property of Cursor — and the one most often missed — is that the agent's trust boundary is not at the output of the model. It is at the input. Any content that reaches the model's context window is effectively a principal with authority.

This is the shape of attack that matters in practice:

  • Prompt injection from repository content. A dependency, a documentation file, a README fetched during browsing, a cursor rules file committed by a contributor, or a comment in a PR you reviewed — any of these can contain instructions the model will treat as authoritative. The CamoLeak vulnerability disclosed against GitHub Copilot in October 2025 (CVSS 9.6) was an instance of this pattern — hidden HTML in a PR drove the agent to exfiltrate AWS keys.
  • Supply chain compromise of agent dependencies. The LiteLLM compromise in March 2026 showed that a single upstream library can harvest credentials from every machine running the agent. The agent itself does not misbehave — the library beneath it does. Cursor and similar IDEs rely on a tower of dependencies, each of which is an entry point.
  • MCP server compromise. MCP servers extend the agent's capabilities. Each one holds its own credentials and makes its own upstream calls. A compromised MCP server can return instructions to the agent, return fabricated data, or act on the agent's behalf against systems the agent would not normally reach.
  • Split-instruction attacks. Two individually innocuous instructions, staged across two tickets or two documents, can compose into a destructive action the model would have rejected if presented as one.

"Refuse obvious bad instructions" is a defense at the wrong layer. The problem is that the inputs that make it into the agent's context are not all under the developer's control.

The five controls#

1. Minimize developer-machine credential exposure#

Before any IDE-specific controls, address the posture of the machine the IDE runs on. Claude Code, Cursor, and every other coding agent operate as the developer — so the developer's on-disk credentials define the blast radius. Practical steps:

  • Use short-lived credentials (SSO, Vault-issued tokens, application default credentials with refresh) instead of long-lived access keys.
  • Remove stale ~/.aws/credentials, unused service account keys, and old cloud CLI sessions.
  • Move high-sensitivity secrets out of developer machines entirely — route them through brokered access.

2. Inventory and scope MCP servers#

Each MCP server Cursor can call is a capability grant. For each configured MCP server:

  • What credentials does it hold?
  • What systems can it read from and write to?
  • Does it require an agent-visible step that a human would not approve in isolation?

In the aggregate, a stack of five MCP servers can add up to more access than any single CI/CD system in your environment. Treat them accordingly.

3. Workspace hygiene#

Cursor's behavior is heavily influenced by workspace content — cursor rules files, README files, inline comments, and the content of files the agent reads during a task. Treat these as inputs to a security-critical system:

  • Review .cursor/rules files the way you review CI config.
  • Be cautious with LLM-readable instructions committed by contributors.
  • Prefer repositories where untrusted contributors cannot modify files the agent will read before review.

4. Action-level governance#

Permission prompts at the shell-command level are useful but do not answer the questions that matter for a security team:

  • Is this agent allowed to take this action on this resource?
  • Whose request is it acting on behalf of?
  • Is this action consistent with the task the agent was asked to perform?

These questions need to be answered at the moment of the action, in a layer the agent has to pass through — not in policy files the agent checks itself.

5. Audit with the principal chain#

For every consequential action an agent took — a commit, a cloud resource change, an API call — the audit record should let you answer: which human's request, through which agent, using which tool, produced this action? In the first hour of an incident, this is the difference between scoped remediation and whole-environment rollback.

Where Cursor differs from Claude Code#

The overall model is the same, but two specifics are worth noting:

  • Cursor has tighter IDE integration. The agent sees more of the workspace passively — open tabs, recent files, the indexer's view — which increases the input surface.
  • Cursor has more configuration surface. Rules files, custom instructions, MCP wiring, and tool permissions are all configurable per-project. That configuration surface is itself a governance surface.

The five controls apply identically. The implementation details differ in where they hook in.

Common questions#

Does Cursor's "ask before running" handle this? It handles a subset of risk — destructive shell commands the user did not intend. It does not handle prompt injection from repository content, data exfiltration through allowed commands, compromised dependencies, or compromised MCP servers. Necessary, not sufficient.

Is this worse than just reviewing PRs by hand? That framing misses the point. Cursor is not writing code you then review. It is also reading credentials, executing commands, and interacting with external services as part of its work. The risk model is closer to "an autonomous service account with the developer's full privileges" than "a code suggestion tool."

Should I disable MCP servers entirely? Probably not — they are where much of the productivity value is. But inventory them, minimize their credentials, and treat their responses as untrusted input.

How does this relate to AI agent governance? Cursor is one specific instance of the general AI agent governance problem. Every control here — identity, access, audit, runtime enforcement — generalizes.

Where FirstOps fits#

FirstOps treats Cursor as one of the agent runtimes it governs — discovering configured MCP servers and tool connections, issuing scoped, verifiable identities to the agents and tools involved, enforcing access policy at the call site rather than inside the agent runtime, and producing a principal-chained audit record that is usable during an incident. If you are working through the controls above and want them as a system rather than a per-developer checklist, we would be glad to walk through it.

Further reading#