Coder Agent Relay Moves Cursor Tool Execution Inside the Enterprise Network, While Inference Remains in the Cloud

Coder has announced the first integration between Agent Relay and Cursor. Enterprises can retain the Cursor app, web, and mobile experiences while deploying the workers that directly operate on code in their own cloud, VPC, or internal environment. Each Coder workspace starts a Cursor worker, which proactively establishes an outbound HTTPS connection. Cursor runs model inference and the agent loop in the cloud, then sends tool calls through that connection. Privileged actions such as reading and modifying files, running tests, and accessing internal services occur on machines controlled by the enterprise.

This architecture separates the “location of reasoning” from the “location of execution.” Platform teams can continue using workspace templates to configure images, network egress, CPU/GPU resources, lifecycles, and per-task isolation boundaries. They can also log what the agent accessed, executed, modified, or was blocked from doing. Compared with copying an entire repository into a vendor sandbox, this approach is better suited to codebases subject to data residency and audit requirements. Network and permission policies enforced at the environment layer also do not depend on the model itself refusing dangerous operations triggered by prompt injection.

However, “the code stays on the internal network” does not mean that all data stays there. Inference and planning still take place on Cursor’s side, so deployers must test which content in prompts, tool outputs, error messages, diffs, and artifacts crosses the outbound connection. Cursor’s documentation also explicitly positions the integration as a reference architecture: customers remain responsible for worker images, secrets, scaling, networking, and production validation, and they need an Enterprise plan and a service account key. Agent Relay is currently available only to design partners in private preview. Before production adoption, engineering teams should require data-flow specifications, retention policies, fail-closed behavior during failures, and independently verifiable audit logs.