AI 程式開發基礎設施
Coder Agent Relay Separates Cloud Reasoning from Self-Hosted Execution, Bringing Cursor Tool Operations into Enterprise Workspaces
Coder lets Cursor’s cloud agent retain the external control loop while moving command execution, file access, and tool operations into enterprise-managed workspaces. This layered architecture can apply existing RBAC, firewall, and audit controls, but reasoning and model traffic still pass through the vendor, so it should not be considered a fully private deployment.
Coder unveiled Agent Relay on September 2, with Cursor Cloud Agents as its first integration. It is currently available only as a private preview for design partners. The system attempts to separate two parts of a coding agent that are often bundled together: Cursor continues to run the agent control loop, planning, and model inference in the cloud, while Relay provisions the daemon that actually reads and writes files, executes commands, and accesses internal services inside an enterprise’s self-hosted Coder workspace.
When a user creates a session, the external agent provider requests resources from Relay. Coder launches a workspace from a specified template or assigns a prewarmed workspace, then establishes a secure connection between the workspace daemon and the external service. Because the execution environment remains a standard Coder workspace, enterprises can continue using their existing RBAC, identity providers, network policies, Agent Firewall, and audit logs. They can also attribute each job submission, tool call, and file access to the human who initiated the task. The workspace can be destroyed after the task is completed.
The significance of this design is that platform teams can move high-risk tool execution back into their own VPC without rebuilding Cursor’s frontend or agent experience. However, “self-hosted execution” does not mean end-to-end privacy: Coder explicitly states that the agent reasoning loop remains in the provider’s cloud, and LLM requests do not pass through Coder AI Gateway. Publicly available information has yet to explain what code or other content is transmitted between the daemon and the cloud, how tool results are filtered or truncated, which connection protocol is used, what revocation semantics apply after connectivity is lost, or where the verifiable boundaries preventing data exfiltration lie. Cursor’s existing documentation indicates that Cloud Agents typically have access to a full development environment, MCP, and internal network connectivity. Organizations should therefore test network traffic, secret injection, log retention, and prompt-injection defenses before production adoption.