Cursor cloud agent security: what a security team should check

Last checked: 21 Oct 2026. Facts come from Cursor's cloud agent and enterprise documentation, its security page and Trust Center, a Cursor forum reply, a GitHub advisory and AWS's CloudTrail documentation, linked where used.

Cursor documents a reasonable set of controls for its cloud agents, but several start open. Network access is on by default, a user's own network setting beats an inherited team default, and only Enterprise teams can lock it. The audit log records changes to settings, secrets and environments, and it does not record what an agent did during a run.

This is Cursor's documentation as read on 21 Oct 2026. We found no independent analysis of these controls and have not tested them, so treat it as a map of what to verify. For the general method, see the security review your AI agent should pass before it ships.

What a cloud agent holds, and the risk Cursor names

Cursor's cloud agent security overview describes a coding agent running in a virtual machine in Cursor's cloud, holding "the cloned repository, installed dependencies, configured secrets, and network access". It runs terminal commands without asking for approval at each step, and Cursor says plainly that an attacker who plants instructions in content the agent reads "could try to make the agent exfiltrate code to an external host."

Cursor's listed defences include egress controls, .cursorignore, draft pull requests a person reviews before merging, signed commits and hooks. Its security hardening guide describes this as shared responsibility and calls allowlists and .cursorignore "best-effort guardrails" to pair with deterministic ones such as approvals and hooks. Cursor also argues cloud agents "carry a different risk profile, not a worse one" than a laptop. That depends on your configuration.

Repository access and who can steer an agent

Agents reach code through the Cursor GitHub or GitLab App and "can only reach repositories the triggering user could already reach." On Teams and Enterprise, Protected Git Scopes let an admin lock a Git organisation so only your Cursor teams can start agents on it.

Team follow-ups deserve a deliberate decision. Cursor's settings page warns that enabling them "means a user can influence the execution of a cloud agent that runs with another user's secrets and credentials", and advises the same care "you would give shared SSH keys or service credentials". The options are Disabled, Service accounts only and All. The docs do not state the default, so check yours. Transcripts are sensitive too: they "can include prompts, code, tool output, and secrets", and team admins can fetch them through the Cursor Cloud MCP (capabilities page).

Secrets: three types, and what each protects

Cursor's secrets and network page says secrets are encrypted at rest and in transit and come in three types.

There is a dated qualification. In a Cursor forum thread, a Cursor staff reply on 26 May 2026 said redaction "works via substring matching on output", so encodings such as base64 "will bypass the filter", and called this "a known limitation of the approach". The docs do not mention it and we found no later statement. Our view: treat redaction as one safeguard and keep any Runtime Secret narrowly scoped and short-lived.

Secrets can be scoped to one development environment (changelog, 13 May 2026), and the setup documentation says such secrets "apply to every repo in that environment". Environments now hold up to 300 repositories (changelog, 16 Oct 2026), so our reading is that one environment's secrets can reach a lot of code. The setup page also warns that .env.local files included in a snapshot "can be saved and available to cloud agents".

Cloud credentials: short-lived tokens first

For cloud roles and internal APIs, Cursor says to "prefer short-lived OIDC tokens over long-lived keys in Secrets". The identity documentation says tokens last 5 minutes with no refresh endpoint, and "Your verifier must reject unexpected aud values" because Cursor does not allowlist audiences. The key line in the trust model: "Any process that can reach the socket can mint a token: the agent, code it runs, and hooks. Scope permissions to what you would grant that run as a whole." A prompt-injected agent can use the role within whatever it permits, so keep the role narrow.

For AWS, the setup page also describes Cursor assuming your IAM role with an external ID, using STS credentials that "expire after 1 hour". Cursor does not mention CloudTrail. AWS's IAM and STS logging documentation says CloudTrail "captures all API calls for IAM and AWS STS as events", so your cloud team can see what the role did in the account that owns it, with one stated exception for denied cross-account role assumptions.

Network access: open by default

The secrets and network page says "The agent has internet access by default." The three modes are Allow all network access, Default + allowlist (Cursor's default domains plus yours) and Allowlist only. Even Allowlist only leaves "a small set of domains" open, including Cursor's services and source control providers.

Users, team admins and environment owners can all set the mode. An environment's own mode applies to agents using it. If the environment inherits, "the user setting takes precedence" over the team default. Our reading is that a team default is a starting point individuals can change. Only Enterprise makes it binding: "Locking is available for Enterprise teams only." A lock does not reach self-hosted machines, which use their own network. Our post on self-hosted Cursor agents covers that runtime.

The "Default" list is the desktop sandbox's list on Cursor's run modes page. When we checked, it included broad hosts such as *.googleapis.com and *.githubusercontent.com. Our reading is that some entries are places where anyone can create storage, which makes Default + allowlist looser than Allowlist only. Cursor makes the same point about its artifact bucket: don't widen it to a region-wide S3 wildcard, which "opens egress to every bucket in the region and creates an exfiltration path for a prompt-injected agent". Allowlist semantics also change: from the week of 28 Sep 2026, *.example.com also allows example.com. Re-read your allowlist after releases.

Reaching internal systems without opening inbound ports

Cursor documents running "Tailscale userspace networking, Cloudflare Tunnel, or a similar private-network client in the Cloud Agent environment", so "your private services do not need to accept inbound traffic from the public internet." The setup page says Tailscale must use userspace mode and tunnel tokens belong "in Cursor Secrets, not in your repository". No plan restriction is stated.

Cursor's private connectivity is a separate Enterprise service over AWS PrivateLink or Cloudflare Tunnel, arranged through Cursor. It covers self-hosted source control such as GitHub Enterprise Server, artifact registries and webhooks back to Cursor, over HTTPS on port 443. It is not the documented route for agents to reach your internal APIs or databases.

Isolation, encryption, retention and data location

The overview says each agent "runs in its own VM boundary", on "Firecracker-based microVM infrastructure", in an AWS account separate from Cursor's other production systems. Traffic uses TLS 1.2 or higher, data at rest AES-256 "with per-agent keys", and Enterprise teams can arrange customer-managed keys (CMEK) through sales, per the privacy and data governance page. Cursor states that its employees "do not have access to the code inside Cloud Agent VMs". That covers the VMs, and transcripts and snapshots are stored elsewhere.

Retention is longer than many reviewers assume. Conversation history "is kept indefinitely by default", snapshots last up to 30 days of inactivity (renewed on each resume) and "can't be deleted on demand", and Enterprise can cap history at 90 days. With Privacy Mode on, Cursor says it never trains on code accessed by cloud agents and "Most models" run under zero-data-retention agreements, though its data use page says providers may keep data flagged by abuse detectors.

For a UK buyer, no UK storage region is documented. US-only residency covers cloud agents on Enterprise, enabled per team, and "EU + UK inference-only coverage is available on request". For agents started from Slack or the web, "The region of the issuing command can't be guaranteed." Our UK data residency guide covers the wider GDPR question.

Signed commits and the pull request

Cloud agents "sign every commit with a HSM-backed Ed25519 key", shown as "Verified" on GitHub and GitLab, and their pull requests satisfy branch protection that requires signed commits, with no setup. A signature shows a commit came from Cursor. It says nothing about whether the change is correct, so the review of the draft pull request still carries the weight.

Audit logs, and what they do not record

Cursor's compliance and monitoring page says audit logs "record who changed what", with payloads that "never" carry "prompts, agent output, generated code, or credentials". They are Enterprise only. At the time of checking, events covered secret changes (name and scope only), egress mode and allowlist changes, the lock and environment lifecycle.

The page lists what is not logged: agent responses, prompts and generated code; Grok Bot actions; cloud agent automation runs; failed sign-in attempts; and secret values. Events can be exported, queried by API or streamed to a SIEM, webhook or S3 (arranged by contacting Cursor). Retention of audit events is not stated, so ask.

Run content sits elsewhere. Admins can review runs in the Cloud Agents dashboard. On Enterprise, OpenTelemetry Export can send prompts and responses to your collector if you opt in, but "Cloud Agent, IDE, and CLI tool calls report no payloads yet." For tool activity, hooks are the route. Cloud agents run repository hooks (Enterprise adds team and managed hooks), but not during early read-only turns, MCP hooks are deferred, and failures "fail open by default" unless you set failClosed: true. See Cursor rules, skills, subagents and hooks for setup and monitoring AI systems for using the records.

The controls at a glance

Cloud agents need a paid plan, and Cursor's pricing page shows which tiers include them.

What you can check independently

Cursor's security page lists "AIUC-1, ISO/IEC 27001:2022, and ISO/IEC 42001:2023 certifications, along with a SOC 2 Type II attestation", with reports on request through the Trust Center. No public page states each certificate's scope, so request the reports and read it. The subprocessor list changes often (the update log shows four inference providers added between 10 Sep and 8 Oct 2026), so check it on the day and subscribe to updates.

One published advisory concerns cloud agents. GHSA-whx2-4gvm-m3r3 (CVE-2026-61613), rated High, was a browser sandbox escape in browser-enabled sessions, fixed on Cursor's side on 31 Mar 2026 and published on 6 Jul 2026 with no customer action needed. It shows what sits in a session: a GitHub App token plus any credentials you configured, whose impact "could be higher depending on those credentials' permissions".

Which contract applies

Cursor announced on 14 Aug 2026 that it had been acquired by SpaceX, and contracting is mid-migration. Cursor's MSA (updated 12 Oct 2026) says customer data will not train AI models unless the customer explicitly agrees, and its DPA incorporates the UK Addendum for UK GDPR transfers. SpaceX Super Intelligence (SpaceXSI) also publishes a Cursor addendum, dated 7 Oct 2026, that applies only to customers with an existing Grok or X Teams subscription on that date. Your legal team should confirm which agreement covers your purchase and read the addendum in full. Our SpaceX Super Intelligence guide covers how Cursor fits with Grok.

Common questions

Can a Cursor cloud agent reach the internet, and can we restrict it?

Yes, internet access is on by default. Users, team admins and environment owners can choose Allow all network access, Default + allowlist or Allowlist only, and Enterprise teams can lock the setting so users cannot override it. Cursor advises allowing the exact artifact upload host rather than a region-wide S3 wildcard.

Where should we keep credentials for a cloud agent?

In Cursor's Secrets, as a Runtime Secret or Build Secret, and out of the repository. Runtime Secrets are redacted from the transcript, tool results and commits but remain visible in the agent's Terminal, and a Cursor staff reply of 26 May 2026 said encodings can bypass the redaction. For cloud roles, Cursor recommends short-lived OIDC tokens, which any process in the run can mint, so scope the role to the run.

What does Cursor's audit log record, and what does it leave out?

It records administrative and security events, such as sign-ins, settings, secrets, environments and egress changes, on the Enterprise plan. It does not record prompts, agent responses, generated code, cloud agent automation runs, failed sign-ins or secret values. Enterprise OpenTelemetry Export can carry prompts and responses if you opt in, and hooks are the route for tool-level activity.

Can cloud agents reach systems that are not on the public internet?

Yes. Cursor documents running Tailscale in userspace mode or Cloudflare Tunnel inside the agent environment, so private services need no inbound access from the internet. Separately, Enterprise private connectivity over AWS PrivateLink or Cloudflare Tunnel covers self-hosted source control, artifact registries and webhooks back to Cursor.

Can we keep cloud agent data in the UK?

Not according to Cursor's documentation as at 21 Oct 2026, which lists no UK storage region. Enterprise teams can enrol in US-only residency, and EU and UK inference-only coverage is available on request. Confirm the position in writing, and check the contract and the published subprocessor list.

We use Cursor in our own engineering, and the table above is the list we would settle before the first cloud agent runs. For a view of where your setup stands, start with a diagnostic, or see our SpaceXSI implementation services and Request a Quote.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer.