Cursor released Self-Hosted Machines on September 2, giving teams a way to move Cloud Agent tool execution onto laptops, virtual machines, clusters, or sandbox infrastructure they manage. That is a meaningful change for engineering organizations whose source control, build systems, internal services, or custom hardware cannot be exposed to a vendor-managed execution environment.
The boundary is narrower than the name may suggest. Cursor's documentation says the agent loop, inference, and planning remain in the Cursor cloud. The self-hosted worker edits files, runs terminal commands, operates browsers, and reaches local MCP servers inside the customer's environment. For security and governance teams, the important question is therefore not simply where the agent runs, but which parts of the agent system run where.
The worker moves; the agent loop does not
A self-hosted worker opens an outbound HTTPS connection to Cursor and waits for tool calls. Cursor handles inference and planning, sends a requested action to the worker, and receives the result before the next reasoning step. Cursor says it does not initiate inbound connections into the customer's network.
That split gives organizations direct control over the execution machine. They can choose the operating system, install internal build tooling, use GPUs or Macs, and place the worker next to services that are not reachable from a public cloud environment. Cursor also supports personal machines and shared team pools, so the same model can cover one-off developer machines and centrally managed enterprise capacity.
This is materially different from a fully self-hosted coding agent stack. The compute that touches the repository and executes commands is customer-managed, but the orchestration and model-processing layer is still a Cursor service.
Self-hosted execution does not mean all data stays local
Cursor's documentation is unusually explicit about the network boundary. The full checkout, build cache, and machine-local credentials remain on the worker, but the worker sends Cursor the content needed for the agent session. The examples listed by Cursor include file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata.
Cloud Agent artifacts can also be uploaded to Cursor-managed storage so they appear in pull requests and dashboards. Cursor says Privacy Mode prevents code sent by the worker from being used for training by Cursor or model providers, but that is different from saying the content never leaves the customer's network.
This distinction matters in architecture reviews. A company can keep its repository checkout and secrets on internal machines while still sending selected source content and tool output to an external processing service. Self-hosted execution is therefore not automatically equivalent to full local processing or a complete data-residency guarantee.
The strongest benefit is access to private infrastructure
The release is most compelling where agent execution needs to sit beside infrastructure that already exists. A worker can access private source control, internal package registries, build pipelines, local services, and specialized hardware without moving those systems into Cursor's managed environment.
Cursor also added dynamic pools that can scale workers around queued requests and can serve more than one repository. The company documents integrations with existing sandbox and compute providers, plus computer use on Linux and Mac. That turns the feature from a single remote development box into an execution layer that can be fitted into an organization's existing developer platform.
For platform teams, that is a practical architectural option: keep the execution substrate under existing infrastructure controls while using Cursor for the agent loop.
Security reviews need two separate boundaries
The operational implication is that security teams should evaluate two boundaries separately.
The first is the execution boundary: where commands run, where the working tree lives, which internal services are reachable, what credentials exist on the machine, and how workers are isolated and patched.
The second is the processing boundary: which file fragments, command output, screenshots, MCP results, transcripts, and artifacts are sent to Cursor or stored outside the worker. Those flows determine whether a self-hosted deployment satisfies a particular confidentiality, retention, or regulatory requirement.
Collapsing those questions into a single "self-hosted" label can produce a false sense of control. The feature can reduce exposure of infrastructure and credentials while still leaving an outbound data path that needs explicit policy.
A useful release gate is to document both boundaries before enabling the service for sensitive repositories. Teams can then decide which repositories are eligible, which outbound destinations are allowed, what tool output may contain, whether artifact uploads should be disabled, and what contractual or retention controls apply to data processed by Cursor.
Self-hosting shifts responsibility as well as control
Cursor recommends its managed Cloud Agents for most teams and notes that organizations operating their own workers take responsibility for the worker image, infrastructure, secrets, scaling policy, and production validation. The self-hosted option also means the customer pays for and operates the execution machines in addition to the selected model usage.
That trade is reasonable for organizations that need private-network access, custom hardware, or tighter control of the execution environment. It is less compelling when managed isolation and private connectivity already satisfy the requirement.
The important architectural takeaway is precise: Cursor has moved the agent's hands into infrastructure the customer controls, but not the agent's brain. For an enterprise deployment, that separation should be visible in threat models, data-flow diagrams, procurement reviews, and release criteria.