A long-lived outbound tunnel lets Cursor drive agent commands on machines inside customer networks

The worker is the trust boundary, running as a process on customer-managed hardware rather than as an appliance. Someone installs the Cursor CLI, runs `agent worker start`, and the machine opens a long-lived outbound HTTPS connection to Cursor's cloud ^[5]. Cursor's harness then handles inference and planning, sends tool calls down that connection, and the worker returns results for the next round of inference ^[6]. Direction is a real property here: no inbound rule, no listener to scan, and Cursor states it never initiates a connection into the network ^[5]. It also means the control channel for file edits and terminal commands looks like ordinary egress from a build host.

The path to abuse runs through instruction content that reaches the loop. Cloud agents are driven from the desktop app, cursor.com, mobile, Slack, GitHub and Linear ^[15], and teams pick self-hosted execution precisely so the agent sits with direct access to source control, internal services and code repositories ^[13]. Cursor's material does not describe an approval gate or a command allowlist on the worker side, so the blast radius is whatever identity the worker runs as and whatever that machine can reach.

Transcripts are the other half of the split. Tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor ^[3]. A transcript of an agent working inside a network is also a description of that network: internal hostnames, repository paths, build commands, and whatever a failed command printed. That record sits with the vendor either way the execution is hosted.

The security controls named in the announcement are described only for the default option. Cursor-hosted sessions each run on a dedicated VM with per-agent isolation, secret redaction, egress controls and signed commits ^[12]. The self-hosted path is described in scheduling terms: idle timeouts, a machine that can reset and re-enter the pool or keep its workspace ^[10], pools that serve work from any repository ^[11]. Whether redaction and egress control ride along to a customer-managed worker is not stated ^[18]. A worker that preserved a workspace and then claims the next queued request ^[9] from a different repository is the first thing worth testing.

Capacity is created by a signal from outside the perimeter. A controller watches Cursor's request queue and invokes a spawn script the team supplies to start machines as needed ^[8], so queue depth in Cursor's cloud results in compute starting in the customer's environment; with Lambda MicroVMs as the compute layer, that environment is the customer's own AWS account ^[16]. Pools grow as requests arrive and shrink after workers disconnect ^[7].

The 60% figure Cursor cites for agent-authored merged pull requests is from its own repository ^[14], which sets the volume of internal traffic Cursor expects from its own codebase, a figure separate from whatever volume a customer's repository would generate. The assessment this warrants is narrow: the worker's identity, its network reach, and how long a workspace survives between jobs.