Cloudflare Sandboxes Put Cursor Agents Inside the Customer's Control Plane
Cursor Cloud Agents can run on Cloudflare Sandboxes, but customer control only matters when egress, secrets, artifacts and worker capacity are governed explicitly.
TL;DR
Cloudflare's September 2, 2026 announcement connects Cursor Cloud Agents to Cloudflare Sandboxes through Cursor Self-Hosted Machines. Cursor keeps the agent loop — inference, planning and orchestration — while a worker selected by the customer executes terminal, filesystem and browser actions. That is a meaningful shift in execution placement, not proof that the workload is automatically safe. The practical boundary moves to the worker: its identity, filesystem, outbound HTTPS policy, credentials, logs and shutdown path.
The source separates Cursor's control plane from the customer worker, and it documents outbound HTTPS, local repositories/caches/secrets, uploaded artifacts, and worker pools. Netics' view is that the announcement matters because worker pools turn concurrency into an operations problem, while the adoption decision still requires explicit verification of egress, credentials, cleanup and stop authority. What teams should verify before adoption is therefore the full execution contract, not the marketing label for the environment.
The announcement changes the location of work
Cloudflare is not announcing a new coding model in this release. It is announcing another execution option for a workflow developers already start from the Cursor app, cursor.com or the Cursor mobile app. Cursor continues routing work and streaming results to the user. With a self-hosted machine, however, the worker that performs the actions can run in a Cloudflare Sandbox inside the customer's Cloudflare account.
That distinction deserves precision. The source separates the Cursor control plane from the worker that carries out the task. It also explicitly distinguishes this worker from Cloudflare Workers, the serverless developer platform. Conflating the two would lead to the wrong operational assumptions: this is a customer-selected execution environment for an agent workflow, not a claim that every Cursor operation has become a Cloudflare Workers function.
For a platform team, the architectural appeal is obvious. Existing Cursor habits remain intact while the execution surface can be placed closer to the organization's code and security requirements. The trade is equally obvious: the customer now owns more of the operational problem. Placement creates a control point; it does not configure the controls.
Outbound connectivity is helpful, but it is not an egress strategy
Cloudflare's source describes an outbound connectivity model. A Cursor worker runs the Cursor CLI and opens a long-lived outbound HTTPS connection to Cursor's backend. Cursor does not need to open an inbound connection into the customer's network. That reduces one class of exposure and can fit environments where inbound access is deliberately closed.
It does not answer the egress question. Outbound is still a permission. The worker needs to reach a remote backend, and the organization needs to decide what else it may reach while running shell commands, package installation, browser actions or build steps. A sandbox with unrestricted internet access is isolated from the host in one dimension and still permissive in another.
The minimum control set should be explicit before a worker is allowed near a meaningful repository: an identity per worker or pool, an allowlist or policy for destinations and ports, DNS and proxy logs, rate and volume limits, and a kill path that does not depend on the agent cooperating. Package registries, source-control endpoints, artifact stores and observability services should be deliberate destinations, not accidental consequences of a broad outbound rule.
This is where the integration should be evaluated differently from a demo. Ask what the worker can contact during a failed task, not only what it contacts during a successful one. A command that installs a dependency or uploads a diagnostic bundle can turn egress into a data-transfer decision. The long-lived HTTPS connection is a transport mechanism; the organization's policy must sit around it.
“Secrets stay local” still requires a secrets design
The release says repositories, build caches and secrets stay on the customer's machines during self-hosted operation. That is an important boundary and a reason to prefer a customer-operated worker over an opaque shared runtime. It is not the same as saying secrets are invisible to the agent.
A coding agent executing terminal and filesystem actions can encounter credentials through environment variables, configuration files, credential helpers, mounted volumes or command output. The fact that the underlying machine remains under customer control does not remove the need to decide which secrets are mounted, for how long, and for which task. A sandbox is a place to enforce that decision, not a substitute for making it.
Use short-lived credentials where the workflow allows it. Separate read-only checkout access from publish, deploy or production access. Keep signing keys and broad cloud credentials outside the default worker image. Redact command output and logs before they become artifacts. Make the worker identity visible in audit records so a pull request can be tied to a run, a pool and an authorization decision.
The source's caveat about uploads matters here. File chunks read by the model are uploaded during inference, and screenshots, videos and log references can be uploaded so they appear in pull requests and dashboards. “The repository stays here” therefore describes storage location, not a promise that no repository-derived material leaves the environment. Security review needs both statements: what remains on the worker and what is intentionally transmitted as context or output.
Worker pools turn concurrency into an operations problem
Cursor supports connecting one worker through My Machines. Enterprise teams can also use self-hosted worker pools as named routing targets. New agent chats can wait until an available worker claims them, while pool orchestration can watch demand, start capacity and release it when sessions end.
This is more than a scaling convenience. A pool is a routing and authorization boundary. Teams may create separate pools for different execution environments, but that separation only helps if repositories, credentials, network policies and logging follow the pool's purpose. A “trusted” pool with broad deployment access should not be the default destination for exploratory code changes simply because it has spare capacity.
Capacity signals deserve governance too. Starting workers when demand rises can increase cost and enlarge the number of active identities. Releasing them when sessions end reduces exposure, but cleanup must be verified: temporary files, package caches, browser profiles, tokens and logs should not survive into the next assignment. Orchestration is therefore part of the security model, not a background scheduler to ignore.
A sensible rollout starts with one narrow pool, a small repository class and a documented stop condition. Measure queue time, failed runs, intervention reasons, egress events and credential exposure attempts. Expand only when those signals are legible. The Netics analysis of agent permissions before platforms makes the broader point: authorization is the architecture, not a feature to add after the agent is connected.
What teams should verify before adoption
Start by writing down the execution contract for a worker. Name the repositories it may access, the filesystem paths it may modify, the commands that require approval and the destinations it may contact. State whether browser actions are allowed, whether package installation is permitted, and who can stop or revoke the worker.
Then test the data path with a deliberately harmless repository that contains no real secrets. Trace which content is sent to Cursor for inference, which artifacts are uploaded, where logs are retained and how a failed session is cleaned up. Do not infer these answers from the word “self-hosted”; verify them in the configuration and the resulting records.
Finally, separate the value proposition from the control claim. Cursor's familiar interfaces and Cloudflare's customer-account execution can be a useful combination for teams that want agent productivity without placing every action on an unmanaged machine. But the integration does not eliminate the need for network policy, credential scoping, artifact review or human approval on sensitive changes. It relocates those decisions to a boundary the customer can own.
Sources
- Cloudflare — Cloudflare Expands Support for AI Coding Agents with Cursor Cloud Agents on Cloudflare Sandboxes — Cloudflare, September 2, 2026.
For practical AI and infrastructure decisions, visit the Netics homepage.