Developer Platforms
Cursor Cloud Agents Get Per-Request Vercel Sandboxes
Vercel said on September 3 that Cursor Cloud Agents can use Vercel Sandbox instead of Cursor-hosted machines. The reference gives each request an isolated Firecracker microVM, uses Functions and Workflow for durable control, and injects short-lived user-scoped credentials; it documents an architecture, not an independent security proof or a guarantee that generated code is correct.
Citation-ready: Vercel announced on September 3, 2026, that Cursor Cloud Agents can run each request in an isolated Vercel Sandbox microVM with durable orchestration and short-lived user-scoped credentials.
What happened and why it matters
No. The architecture narrows execution and credential scope, while repository permissions, network egress, dependency risk, secret handling, tests, review, merge rules, deployment, and independent isolation evidence remain separate controls.
Official Vercel changelog and reference architecture
Primary reference: Vercel: Cursor Cloud Agents can run in Vercel Sandbox. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 3, 2026 |
|---|---|
| Checked by Kaleido Field | September 4, 2026, 10:05 CST |
| Source function | current developer-platform analysis separating agent harness, self-hosted execution API, per-request microVM, durable queue and retries, short-lived credentials, cleanup, enterprise-plan dependency, isolation testing, code review, and deployment authority |
The control plane owns lifecycle, not intent
Functions and Workflow can claim requests, create workers, watch sessions, retry, and clean up. Cursor still owns the agent harness and inference loop, while the repository and CI policies decide which changes are acceptable.
Record request and user identity, repository and commit, agent and model version, sandbox image, network policy, credentials, commands, files, artifacts, exit state, retry lineage, cleanup receipt, diff, tests, reviewer, and merge decision.
Durable retries require idempotent effects
A worker can fail after pushing a branch, posting a review, changing an issue, or starting a deployment. Retrying the whole job without an operation key and live-state readback can duplicate or conflict with that side effect.
Test lease expiry, duplicate delivery, timeout after commit, partial artifact upload, revoked credential, malicious repository instructions, dependency compromise, network denial, cleanup failure, stale base branch, CI failure, and rollback.
Evidence boundary
Official platform facts: integration availability, Cursor Enterprise requirement for Self-Hosted Machines, Cursor ownership of the harness and inference loop, Firecracker microVM per request, scale-to-zero workers, Vercel Functions and Workflow control plane, durable retries, and short-lived user-scoped credentials. Vercel positioning: isolated, durable agent execution without long-lived workers. Not established: independent sandbox-escape assessment for this integration, default egress and secret policy, repository or organization isolation, malicious dependency handling, retry idempotency, workload performance, code correctness, test quality, merge safety, deployment authority, or production outcomes.
FAQ
What isolation does Vercel describe?
A dedicated Firecracker microVM for every agent request.
Who manages the agent loop?
Cursor manages the agent harness and inference loop; Vercel supplies the execution and durable control-plane components.
Is Cursor Enterprise required?
Vercel says Cursor Self-Hosted Machines requires a Cursor Enterprise plan.