Cursor shipped a quiet expansion of Cloud Agents last week, introducing self-hosted machines, team pools, and persistent Projects. While most coverage fixated on the long-running coordinator agent, the critical shift is architectural: Cursor moved tool execution to your hardware but kept the agent loop—planning, state, and inference—firmly in its own cloud. This creates a split-trust model that feels on-prem but fails strict sovereignty tests.

The Worker Model and Network Boundaries

The setup relies on a worker process installed via the Cursor CLI. Running agent worker start opens a single long-lived outbound HTTPS connection to Cursor’s cloud, specifically targeting api2.cursor.sh, api2direct.cursor.sh, and cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Your machine executes terminal commands, file edits, and browser actions locally, requiring no inbound ports or public IPs. This outbound-only design keeps your firewall untouched, but it means the 'brain' of the operation remains entirely dependent on Cursor’s infrastructure availability.

Where Your Code Actually Goes

Docs specify that raw code and secrets stay on your hardware, but file chunks required for inference are uploaded to Cursor’s cloud. Screenshots, videos, and log references also leave your network to render in pull requests and dashboards. For compliance officers hoping for an air-tight boundary, this is a critical nuance: content crossing the loop boundary does not stay local. However, users can block the S3 artifact endpoint, sacrificing dashboard visibility to keep those specific outputs internal.

Rules Files and Guardrail Enforcement

In this split architecture, .cursor/rules and hooks travel with the worker, executing locally alongside the tools. This means policy enforcement is local, but policy drafting context is remote. The model decides what to attempt in the cloud, while your local rules constrain how those attempts execute. This differs from tools like Claude Code, where guardrails and execution often reside in the same process, offering a different trust shape that Cursor’s split model does not replicate.

Team Pools and Routing Mechanics

For teams, self-hosted machines form pools where requests wait for available workers. Routing is controlled via labels (e.g., gpu, ios) and triggers from Slack or GitHub. Cursor enforces strict permission scoping: only repo owners and collaborators can route runs to self-hosted workers, preventing random commenters from abusing your infrastructure. Enterprise plans are required for pools, which support up to 1,000 workers per team via Kubernetes operators and Helm charts.

Key Takeaways

  • Cursor’s self-hosted runners are not true on-prem solutions; inference and planning remain in Cursor’s cloud.
  • File chunks for inference and artifacts for dashboards leave your network, though artifact uploads can be blocked.
  • Rules files enforce local execution constraints, but the model’s intent is generated remotely.
  • Team pools require Enterprise plans and use outbound-only HTTPS connections for security.
  • The architecture shifts the operational burden of patching and capacity management to the user.

The Bottom Line

Cursor moved execution to your hardware but kept the brain. For most compliance stories, this trade-off is acceptable; for full sovereignty, it is not. Audit your trust boundaries before pointing a pool at production secrets.