Cloud Agents
Cursor Cloud Agents: Security & Network Access
Cloud Agents run in Privacy Mode inside isolated VMs in Cursor's AWS infrastructure. Secrets are encrypted at rest and in transit and can be scoped as Environment Variables, Runtime Secrets, or Build Secrets. Every commit is signed with an HSM-backed Ed25519 key. The agent has internet access by default, but you can restrict outbound egress with three network access modes and an allowlist at the user, environment, or team level.
On this page
- How does Cursor protect secrets passed to cloud agents?
- How are cloud agent commits verified and access locked down?
- What should I know about how cloud agents run my code?
- How long does Cursor retain cloud agent data?
- How do I control which networks cloud agents can reach?
- What IP ranges do cloud agents connect from?
How does Cursor protect secrets passed to cloud agents?
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. 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.
- Secret type
- Environment Variable
- Exposure
- Visible to the cloud agent; encrypted at rest and in transit
- Best for
- Non-sensitive configuration the agent benefits from seeing, such as flags or public URLs
- Secret type
- Runtime Secret
- Exposure
- Loaded as an env var, but redacted from tool-call results, chat transcript, commits, and commit messages and replaced with
[REDACTED] - Best for
- Sensitive credentials that should not be exposed to the agent or committed
- Secret type
- Build Secret
- Exposure
- Available only to the Docker build process; not exposed to the running agent's environment
- Best for
- Private package registries or build-time credentials
| Secret type | Exposure | Best for |
|---|---|---|
| Environment Variable | Visible to the cloud agent; encrypted at rest and in transit | Non-sensitive configuration the agent benefits from seeing, such as flags or public URLs |
| Runtime Secret | Loaded as an env var, but redacted from tool-call results, chat transcript, commits, and commit messages and replaced with [REDACTED] | Sensitive credentials that should not be exposed to the agent or committed |
| Build Secret | Available only to the Docker build process; not exposed to the running agent's environment | Private package registries or build-time credentials |
Runtime Secrets were previously called Redacted Secrets. Because they still function internally as environment variables, they remain visible to users interacting with the agent's environment via the Terminal.
To use a Build Secret securely inside your Dockerfile, reference it from a RUN step with a Docker secret mount, for example RUN --mount=type=secret,id=MY_TOKEN,env=MY_TOKEN,required=true ./scripts/install-private-deps.sh.
How are cloud agent commits verified and access locked down?
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. 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. 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 PRs satisfy branch protection rules that require signed commits without extra configuration.
- 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. on its repositories.
What should I know about how cloud agents run my code?
Cursor documents the 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. so you can reason about the trust boundary. The points below summarize 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 routes requests under zero-data-retention terms so providers don't store or train on your code. is disabled, Cursor collects prompts and dev environments to improve the product. If you disable Privacy Mode when starting a cloud agent and then enable it mid-run, the agent continues with Privacy Mode disabled until it completes.
How long does Cursor retain cloud agent data?
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. 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 additionally cap conversation retention with a policy.
Custom retention windows are in early access for select Enterprise teams. Admins can set the team's Cloud Agent retention window to Indefinite or 90 days from Team Settings on the 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. dashboard. Setting it to 90 days runs a background job that deletes conversations older than the window and applies to every agent run the team owns, including saved-environment and API runs. Switching back to Indefinite stops further deletions but does not restore data already removed.
How do I control which networks cloud agents can reach?
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. 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.
- Mode
- Allow all network access
- Behavior
- 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. can reach any external host; no domain restrictions apply.
- Mode
- Default + allowlist
- Behavior
- 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. can reach the default domains plus any domains you add to your allowlist.
- Mode
- Allowlist only
- Behavior
- 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. can only reach the domains you explicitly add to your allowlist.
| Mode | Behavior |
|---|---|
| Allow all network access | 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. can reach any external host; no domain restrictions apply. |
| Default + allowlist | 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. can reach the default domains plus any domains you add to your allowlist. |
| Allowlist only | 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. can only reach the domains you explicitly add to your allowlist. |
Even in Allowlist only mode, a small set of domains stay accessible so Cloud Agents can function, including Cursor's own services and source control management (SCM) providers.
These settings layer by scope. User-level settings apply to all 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. you create. Saved environments can set their own mode and allowlist (or inherit the user or team setting, optionally adding an environment allowlist) so a production-adjacent environment can run Allowlist only while others stay on Default + allowlist. Team admins set a default for the whole team, and the team-level allowlist is the same allowlist used for the sandbox default network allowlist.
When a team-level setting exists: an environment's own mode applies to agents using that environment; if the environment inherits and a user has configured a setting, the user setting takes precedence; otherwise the team default applies. Enterprise admins can use Lock Network Access Policy so the team-level setting applies to every member and users cannot override it.
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. upload artifacts (screenshots, videos, and log references shown on PRs) to cloud-agent-artifacts.s3.us-east-1.amazonaws.com. If you use Default + allowlist or Allowlist only, add that exact host. Don't broaden it to *.s3.us-east-1.amazonaws.com: the wildcard opens egress to every bucket in the region and creates an exfiltration path for a prompt-injected agent. Blocking the host only disables uploads; sessions and other tool calls keep working.
For private resources, 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. do not need to run on your hardware. For services in a VPC or intranet, use Tailscale userspace networking, Cloudflare Tunnel, or a similar private-network client in the agent environment so the service never has to accept inbound public traffic. For TCP targets such as private databases, use a tunnel client that exposes a local TCP listener so the agent connects to localhost. 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. or Cloudflare Tunnel.
What IP ranges do cloud agents connect from?
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. 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.
Cursor changes its IP addresses from time to time for scaling and operational needs, and does not recommend allowlisting by IP address as your primary security mechanism. If you must use the ranges, Cursor strongly encourages regular monitoring of the JSON API endpoint. For git hosts specifically, Cursor recommends the git egress proxy IP allow list, which routes all git traffic through a narrower, stable set of IPs and works across GitHub, GitLab, Azure DevOps, and Bitbucket.
Frequently asked questions
Are Cloud Agents available in Privacy Mode?
Yes. Cloud Agents are available in Privacy Mode, Cursor never trains on your code, and code is only retained for running the agent. If Privacy Mode is disabled, Cursor collects prompts and dev environments to improve the product; and if you enable Privacy Mode mid-run after starting with it disabled, the agent finishes the run with Privacy Mode disabled.
What's the difference between a Runtime Secret and an Environment Variable secret?
An Environment Variable secret is visible to the cloud agent and is best for non-sensitive configuration such as flags or public URLs. A Runtime Secret (formerly Redacted Secret) is still loaded as an environment variable, but its contents are redacted from the agent's tool-call results, chat transcript, commits, and commit messages and replaced with [REDACTED]. Because it still works as an env var internally, it remains visible to users interacting with the environment via the Terminal.
Can I delete a cloud agent's data on demand?
You can use the Delete Agent API to permanently delete a cloud agent's conversation transcript and its artifacts. It does not delete environment snapshots, which can't be deleted on demand and instead follow a rolling 90-day inactivity retention window.
Sources & last verified
- Cursor Docs - Cloud Agent Security & Network
- Cursor - Default network allowlist (sandbox terminal)
- Cursor - Protected Git Scopes (model & integration management)
- Cursor - Enterprise private connectivity
Cursor ships frequently. Facts verified against primary sources on June 29, 2026.