Cursor Cloud Agent Security and Network Access, Explained

Secrets provided to Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. are encrypted at rest and in transit and are not visible to anyone other than the Cloud Agent user. You choose how exposed each secret is by setting its type. The table below maps the three secret types to what they're for.

Runtime Secret redaction is narrower than the name suggests. The value stays in the process environment, which is how your test suite authenticates at all. What gets replaced with [REDACTED] is the copy that would otherwise land in tool-call results, the chat transcript, commits and commit messages. Treat the type as a control on what gets written down, and assume anyone who can open a Terminal in that environment can read the value.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. both prove their commits came from Cursor and let admins limit which repos agents can touch. The two controls below work without per-agent setup.

• Signed commits: Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. sign every commit with an HSM-backed Ed25519 key. On GitHub and GitLab the commits show a "Verified" badge. This works automatically for all Cloud Agents with no setup required, and the resulting PRs satisfy branch protection rules that require signed commits.
• Protected Git Scopes: Team admins can lock a Git organization to your Cursor organization so only your teams can start Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. on its repositories.

A signature is provenance and nothing more. Cloud Agent PRs satisfy branch protection rules that require signed commits with no extra configuration, so a rule that checks only for a signature has not reviewed anything on your behalf. Of the two, Protected Git Scopes is probably the one that changes your exposure, since it decides who can start an agent on those repositories at all.

Cursor publishes six operating assumptions for Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., and several of them describe risks you take on by running one. The list below is what Cursor says you should know.

• Grant read-write privileges to Cursor's GitHub app for the repos you want to edit; Cursor uses this to clone the repo and make changes.
• Your code runs inside Cursor's AWS infrastructure in isolated VMs and is stored on VM disks while the agent is accessible.
• The agent has internet access by default; you can configure network egress controls for users, teams, and saved environments to restrict the domains it can access.
• The agent auto-runs all terminal commands so it can iterate on tests, unlike the foreground agent, which requires approval for every command. Auto-running introduces data exfiltration risk: an attacker could use a prompt injection attack to trick the agent into uploading code to a malicious site.
• If Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. is disabled, Cursor collects prompts and dev environments to improve the product.
• If you disable Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. when starting a cloud agent and then enable it mid-run, the agent continues with Privacy Mode disabled until it completes.

The auto-run point is the one worth reading twice. A foreground agent asks before every terminal command, and a Cloud Agent runs all of them so it can iterate on tests, which is also what a prompt injection needs to get code out of the VM.

The network access modes further down are the lever for that risk, and they act on where code can go rather than on whether the command runs.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. store two kinds of data per run, and each follows its own retention rule. The list below describes what is kept and for how long.

• Conversation history is the agent's transcript, the prompts, model responses, tool calls, and demo artifacts you see when you open an agent. It is kept indefinitely by default so you can revisit and resume past runs.
• Environment snapshots are encrypted point-in-time copies of the VM disk that let agents start or resume without recloning. They are stored for a maximum of 90 days of inactivity; each start or resume from a snapshot extends its expiry by another 90 days, after which an unused snapshot is deleted automatically regardless of plan or policy.

You can use the Delete Agent API to explicitly delete a cloud agent's conversation history and artifacts; it does not delete environment snapshots, which follow the inactivity window above. Enterprise team admins can also cap conversation retention with a policy. The snapshot is the gap that tends to matter, since it is a copy of the VM disk and it outlives the agent you deleted. If a credential ever reached that disk, rotate it rather than waiting out the inactivity window.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. reach the internet by default, and you control outbound egress with one of three access modes configured from the Cloud Agents dashboard for users, saved environments, and team admins. The table below describes each mode.

The table gives you behavior, not a recommendation. The mode I'd reach for first is Allowlist only, since that is the only one whose boundary you wrote yourself. It is the wrong order, though, once you work through what breaks. Allowlist only leaves a small set of domains reachable, Cursor's own services and your SCM among them, so whatever your install step fetches fails first, and a wildcard is the tempting fix at that point. Start on Default + allowlist, whose default domains are the same set the desktop agent's sandbox uses, then tighten once you know the host list.

The environment wins, then the user, then the team default, and each level can set its own mode and allowlist. A user-level setting applies to every Cloud Agent you create. A saved environment can set a mode outright, or inherit the user or team setting and optionally add an environment allowlist, so a production-adjacent environment runs Allowlist only while the rest stay on Default + allowlist. The team-level allowlist is the same one used for the sandbox default network allowlist, which means one list to maintain rather than two.

How much the precedence matters scales with headcount. On a small team it barely does, since everyone sets their own mode and a mistake gets fixed by asking. Past the size where nobody knows who configured what, a team default is only a default: a member who already set a preference keeps it, so an admin switching the team to Allowlist only has changed things only for the people who never configured a setting of their own. Lock Network Access Policy makes it apply to everyone, and locking is Enterprise-only. When a run fails on network, the thing I'd check first is which scope applied, because editing a level that did not apply leaves the run failing the same way.

No. Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. do not need to run on your hardware, and your private services do not need to accept inbound traffic from the public internet. For a service in a VPC or intranet, run Tailscale userspace networking, Cloudflare Tunnel, or a similar private-network client inside the agent environment. The agent connects out through an authenticated path while the service stays where it is.

Picking between them depends on the shape of the target. Cloudflare Tunnel fits a service you can reach through an authenticated HTTPS hostname, because the agent then calls that hostname like any other external URL and you allowlist it the same way. For TCP targets such as private databases, use a tunnel client that exposes a local TCP listener and point the agent at localhost instead.

Enterprise teams with private GitHub Enterprise Server or GitLab Enterprise can use private connectivity with AWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. Press Enter for the full definition. or Cloudflare Tunnel. The setup guide carries the flags and the Access-token handling.

Needing a private database reads as a reason to self-host the runtime, and it usually isn't one. My Machines and a Self-Hosted Pool are for owning the machine that runs tool calls, which is a different problem. Choose where cloud agents run has that comparison.

Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. make outbound connections from specific IP ranges, published in CIDR notation through a JSON API endpoint so you can allowlist them on firewalls if needed. Fetch them with curl https://cursor.com/docs/ips.json. The list below explains the fields the response returns.

• version: schema version number for the API response.
• modified: ISO 8601 timestamp of when the IP ranges were last updated.
• cloudAgents: an object of IP ranges keyed by cluster.
• gitEgressProxy: the IP addresses used by the git egress proxy.

Those fields are the easy half. modified is the one to watch, because it is the only signal in the payload that the ranges moved, and a firewall rule built from a single curl can keep passing review long after it stopped matching what Cursor is using. Cursor Review sits differently. Its IPs are an additional list on top of the git egress proxy addresses, and Cursor calls those stable, with advance notice to teams on IP allow lists before any address is added or removed.