Security1 publisher3 min readPublished
Cursor's self-hosted agent workers still send file contents and diffs back to its cloud
Cursor now runs coding-agent tool calls on machines you own, but its documentation is explicit that the loop, the inference and the content the agent reads stay on Cursor's side, so what you get is reachability into your infrastructure while the data boundary stays with Cursor.
The Watch · Security desk

What happened
- Cursor's Self-Hosted Machines feature moves Cloud Agent tool execution onto machines the customer manages, while Cursor keeps running the agent loop, inference and planning in its own cloud.
- The documentation says the worker sends Cursor file contents, terminal output, diffs, screenshots, local MCP results and routing metadata during a run, plus a desktop stream if sharing is enabled.
- Screenshots, videos and log references upload to Cursor-managed storage so they render in pull requests and the dashboard, and the docs tell operators to keep secrets out of tool output and artifacts.
- Cursor's changelog describes the same feature as keeping tool execution entirely in your own network, with codebase, build outputs and secrets all staying on internal machines.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- contradiction A reviewer working from the changelog approves a network boundary; a reviewer working from the docs page approves a content-forwarding arrangement, and only the second description survives a data-flow diagram.
- constraint Egress filtering can remove the artifact bucket and nothing else, so which repository content reaches Cursor stops being a firewall decision and becomes a question of whether secrets ever land in tool output.
- decision Self-hosting answers unreachable services or GPU and Mac hardware, while a requirement that source content never leave the perimeter goes unanswered, and Cursor points those buyers back to its managed allowlists, PrivateLink and Privacy Mode.
- cost Taking the worker in-house means owning a fleet to size, patch, scale and keep on call, which is precisely the operational bill the managed option removes.
The full checkout, the build cache and machine-local credentials do stay on the worker, which is the part of the changelog's claim that holds [5]. The arithmetic on the wire is where it comes apart. Cursor's docs require outbound HTTPS to three hostnames: `api2.cursor.sh` and `api2direct.cursor.sh` for the agent session, and `cloud-agent-artifacts.s3.us-east-1.amazonaws.com` for artifact uploads [7]. One of the three is optional. Block the bucket and artifact uploads stop while tool calls and their results keep working [8]. Two mandatory destinations remain, and they are the ones carrying session content [19]. So the operator, not egress policy, decides what reaches Cursor, per the docs' single line about keeping secrets out of tool output [6].
For whoever writes the firewall rules, the shape is a worker that dials out. `agent worker start` opens a long-lived outbound HTTPS connection and Cursor pushes tool calls down it, with no inbound ports, no public IP and no VPN tunnel [9]. Cursor never initiates a connection into the network [9]. A perimeter review looking for inbound exposure finds nothing, while terminal commands from outside arrive inside a session the proxy logs as ordinary HTTPS [2].
The documentation names three reasons to self-host: code or services that cannot be reached from outside the network, custom hardware such as GPU machines or Macs for iOS work, and custom images such as a different operating system or an existing build pipeline [3]. Data boundary is absent from that list [20], and Cursor writes the counter-argument itself: you don't need to own the compute to keep agents inside your security perimeter, followed by the managed controls said to cover it, among them an isolated VM per agent, outbound allowlists scoped by user, team or environment, AWS PrivateLink or Cloudflare Tunnel to GitHub Enterprise Server and GitLab Enterprise, Privacy Mode and customer-controlled secrets [10].
One configuration moves isolation backwards. My Machines lets several agents run on the same machine [11], where managed Cloud Agents get a VM per agent that Cursor provisions and tears down [10]. Team Pools puts it back to one agent per machine, with service account authentication and centrally managed images [11], and the anysphere/k8s-workers template creates one worker Pod per claimed request [12]. "Your machine" also stretches: the docs accept a VM from a partner host such as AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B or Vercel [13], so self-hosted compute can still sit in someone else's tenancy.
No vulnerability is at play here, and no patch deadline applies. What a security team signs for is a worker that executes terminal commands issued by a loop it does not run [2], and that can click, type, take screenshots and drive a browser on Linux and Mac under that loop's control [16].
What to watch
- Whether Cursor documents a mode that withholds tool-call content, and not just artifacts, from api2.cursor.sh.
- Whether Team Pools gains audit logging that ties a given chat to the worker and image that claimed it.
- Whether the changelog wording gets reconciled with the docs page's list of what the worker forwards.