Developers can give a coding agent a task, such as fixing a bug or adding tests, and return later to a branch or pull request (PR) for review. Cloud agents handle this work remotely. The time saved depends on the task's scope, the agent's permissions, the checks it can run, and the review effort required for its output.
Copy link to headingWhat is a cloud agent?
A cloud agent is a coding agent that works in a separate environment, usually on remote, vendor-managed infrastructure. Some products also support execution on customer-controlled infrastructure. It can check out a repository, edit files, run tests, and return a branch or PR. Remote execution allows work to continue independently of the developer's laptop, subject to session limits and the remote worker's availability.
Both local and cloud agents need access controls. A local agent uses the filesystem, credentials, and network access that its configuration permits. A cloud agent uses a separate environment with its own repository access, secrets, and network policy. Neither location guarantees restricted access. Review each agent's permissions, including vendor defaults, inherited settings, and any exceptions the team enables.
Copy link to headingCloud agents vs. local and background agents
Cloud agents generally execute tools on remote infrastructure, while local agents execute them on the developer's machine. A background agent can run in either location. It continues working outside the active interactive session. Execution location, autonomy, and approval policy are separate choices, even when a vendor bundles them together.
This comparison covers where agents run, how they operate, and what they return. Background agents can be local or cloud-based:
Local agents suit work that needs the developer's current environment and frequent interaction. Cloud agents are well-suited to tasks with a defined scope that should continue remotely. Either can run unattended, depending on the product and its approval settings.
Copy link to headingWhen to use cloud agents
Cloud agents can keep working after a laptop disconnects and run independent tasks in separate remote environments. Common use cases include:
Pull request work: Well-scoped bug fixes and small features can run as unattended tasks that produce a PR for review. Developers define the scope and acceptance criteria before the run, then assess the changes and test results. Code hosts such as GitHub let developers start this workflow by assigning an issue to an agent.
Migrations: A migration may repeat related changes across hundreds or thousands of files. Give each agent a defined scope and a result that reviewers can assess independently. The overall migration may span weeks. A test-library or framework upgrade, for example, can use one task per package, with each task producing its own PR.
Maintenance: Dependency updates, deprecated flag cleanup, and similar recurring work can start on a schedule. Products such as GitHub Copilot cloud agent support scheduled automations, including tasks that prepare dependency-update PRs for review.
Parallel agent fleets: Independent tasks can run side by side in separate environments and branches. Remote execution lets those tasks continue after the developer disconnects. How many agents to run depends on available compute, task dependencies, and the team's ability to review the results.
In each case, permissions determine what the agent can read and change, network policy determines what it can reach, and usage controls determine how many resources it can use.
Copy link to headingHow cloud agents work
Four areas matter when evaluating a cloud agent: its execution environment, task triggers, runtime limits, and access controls.
Copy link to headingExecution environment
The execution environment is the container or virtual machine (VM) that holds the checked-out repository and the agent's processes. Cloud agent products use both. A container shares its host's kernel, while a micro virtual machine (microVM) runs its own guest kernel. microVMs vs containers explains the isolation trade-offs.
A $1M hacker challenge against Vercel Sandbox drew 1,285 reports in two weeks and showed why host-side controls matter alongside VM isolation. The most severe finding was a vulnerability in the Linux kernel's networking stack. Researchers demonstrated a host-memory leak on production sandboxes and host crashes and administrator-level code execution on researcher-controlled machines matching the Sandbox configuration. Vercel began mitigation after notification and reported no demonstrated access to customer files, secrets, or application data. Trail of Bits separately assessed the virtualization boundary as sound and recommended additional hardening.
Copy link to headingTask triggers
Task triggers are events that start a cloud agent run, often from tools the team already uses to track work. Depending on the product, triggers can include an assigned issue, a PR comment, a team chat message, a tracker ticket, a schedule, or a webhook.
Decide who can trigger an agent run. Issue text and comments can contain attacker-controlled instructions, so agent guardrails apply from the first input. Restrict who can initiate runs, treat the content they reference as untrusted, and require an authorized reviewer to inspect agent changes before approving privileged continuous integration (CI) workflows.
Copy link to headingSession and concurrency limits
A session limit caps one run's execution time, while a concurrency cap limits simultaneous runs. GitHub Copilot cloud agent, for example, has a documented, non-extendable 59-minute session limit. If a vendor does not publish a limit, confirm it before relying on long-running tasks. An undocumented limit does not mean unlimited runtime.
Limits shape task design. Work that requires two uninterrupted hours cannot be completed within a one-hour session unless it can be checkpointed and resumed, or split into shorter runs. Dependent runs need durable progress records, such as commits, task manifests, or saved agent memory. Design retries so an interrupted run can resume or repeat without duplicating external changes.
Copy link to headingNetwork access and credentials
Network boundaries control where an unattended agent can connect, and credential handling determines how it authenticates. With credential brokering, a proxy or firewall outside the execution environment injects secrets into matching outbound requests. The agent can then call a service without reading the credentials.
Passing a secret through an environment variable places it within reach of processes that receive or can inspect that environment. If a prompt injection causes the agent to execute malicious code, that code may read the secret and attempt to send it elsewhere. Brokering keeps the credential value outside the environment, but its permissions and request rules still need to limit which authenticated operations the agent can perform.
Copy link to headingHow to evaluate cloud agents
Evaluate cost, isolation, review effort, and observability before granting an agent write access to a production repository. Decide how the team will control each one.
Copy link to headingCost controls
Cloud agents can repeat failed actions and keep spending until they reach a limit or an operator stops them. Vendors charge for different combinations of tokens, credits, seats, and compute, so track the relevant charges together. Use enforceable spending limits where available, along with execution timeouts and model-usage budgets. A compute cap alone does not necessarily cap API spending. Budget alerts can warn before spending reaches a threshold, but notifications alone do not stop a run.
Copy link to headingNetwork security
Unrestricted internet access gives a compromised agent more destinations for sending code or secrets. Web pages, repository files, and packages can contain prompt injections, and cloud agents often execute commands without a developer approving each step. Deny-by-default egress restricts outbound access to approved destinations, such as required registries and APIs. Some products enable an outbound firewall by default, but review its scope and exceptions. Maintain the allowlist as tasks need access to more services.
Copy link to headingReview capacity
Parallel agents can open PRs faster than a team can review them. Unreviewed changes can accumulate and become stale. In the August 2026 AI SDK software factory report, factory agents authored 25–35% of weekly PR merges while humans retained control over every merge. Set an initial concurrency limit based on measured review capacity, then adjust it using queue age, review effort, and change quality. Evaluating AI coding agents covers how to assess that output.
Copy link to headingObservability
Cost surprises and failed runs are harder to investigate when vendors provide different telemetry. OpenTelemetry (OTel) is an observability framework and toolkit for collecting and exporting metrics, logs, and traces. Cursor Enterprise, for example, exports estimated cost metrics and agent lifecycle logs, including PR events. Its metric datapoints do not carry session correlation IDs. Keep the vendor identifiers available in logs and map them to an internal task identifier where supported. Do not assume every record shares one identifier.
Copy link to headingRunning cloud agents with Vercel Sandbox
Vercel Sandbox provides an execution environment for agent-run code. Teams can use it to execute code for their own agent loop or a supported partner agent. It provides managed VM isolation and outbound network controls. Vercel's AI SDK software factory uses an isolated sandbox for each agent, with its code, runtime, and the secrets required for that task.
Copy link to headingMicroVM isolation
Treat agent-run code as untrusted. Standard Linux containers separate processes and resources using namespaces and control groups (cgroups), but share the host's kernel. Calling Sandbox.create() creates a Firecracker microVM with its own guest kernel, filesystem, and network environment. To isolate tasks from one another at the VM boundary, create a separate sandbox for each task. Learn more about this pattern in Run Cursor Cloud Agents on Vercel Sandbox.
Vercel also hardens the host around the VM. Its published security findings describe keeping host and guest kernels up to date, disabling nested virtualization, and using Firecracker's jailer to run microVM processes with restricted permissions.
Copy link to headingOne isolation layer for partner cloud agents
Some cloud agent products let teams choose a separate execution provider. With Devin Outposts, each session can run in a Sandbox microVM while Cognition runs the agent loop and inference. The integration requires Vercel Pro or Enterprise and Outposts access. Claude Managed Agents can execute tools in a Sandbox microVM per session, with credential brokering and deny-by-default egress in Vercel's reference implementation. Cursor Cloud Agents can use Sandbox through Self-Hosted Machines APIs, which require Cursor Enterprise.
In these integrations, the partner runs the agent loop and inference, while code executes in the team's Vercel project. Teams can use the same VM isolation and manage task-specific network policies across supported agent products. Tool results still return to the partner service, so evaluate execution location and model-provider data access separately.
Copy link to headingCredential brokering at the egress firewall
Code inside a sandbox can read any secret its permissions allow. The Sandbox firewall supports credential brokering to keep configured secrets outside the VM. Its deny-all policy blocks outbound traffic, including Domain Name System (DNS) lookups. A restrictive user-defined policy allows specified destinations. Configuring either policy replaces the default allow-all access to the public internet.
For a service such as AI Gateway, a transform rule can inject credentials into matching outbound requests without exposing their values inside the VM. Scope credentials and matchers to the operations the task needs. Matchers select requests to modify. They do not block unmatched requests to an allowed domain. Every Sandbox firewall feature is available on Hobby, subject to the plan's usage quotas.
Copy link to headingPersistent snapshots and forks for faster starts
Fresh environments may need to clone a repository, install dependencies, and prepare a build before starting the task. Sandboxes are persistent by default. Stopping a session automatically snapshots its filesystem, and a later session starts from that saved state. Calling sandbox.snapshot() also captures the filesystem and stops the session. Sandbox.fork() creates a new sandbox from the source's current snapshot and inherited configuration, so snapshot a prepared environment before creating forks. Snapshots expire 30 days after their last use by default.
Sessions run for up to 45 minutes on Hobby and 24 hours on Pro and Enterprise. Resuming a sandbox starts a new session with a fresh timeout. The limit applies to each session, rather than the sandbox's total runtime. To keep reusing the sandbox, keep the required snapshot available under its retention policy.
Copy link to headingFluid compute for agents that wait on models
Agents may spend substantial time waiting for model responses or external APIs. Sandbox uses Active CPU pricing, which excludes time spent waiting for input/output, including network requests and model calls. Provisioned-memory charges continue while the sandbox runs, including those waits.
Stopping a sandbox between tasks avoids charges for provisioned memory while it is stopped. A later session restores its saved filesystem, but services may need to be restarted. Snapshot storage is billed separately, so persistence reduces the need for repeated setup without eliminating storage costs.
Copy link to headingRun cloud agents in isolated sandboxes on Vercel
An unattended agent needs permissions aligned with its task, isolation suited to the workload, explicit outbound network access, and sufficient review capacity to assess its output. The team also needs to know which data reaches the model provider and how long the services retain execution state and logs. What the team must operate depends on the product, deployment model, and task requirements.
Vercel Sandbox provides managed isolation and configurable outbound network controls:
Dedicated-kernel microVM per task: Create a separate sandbox for each task to give it its own Firecracker microVM and guest kernel.
Credential brokering at the egress firewall: Configured transform rules attach credentials to matching requests without placing their values inside the VM.
Partner agents on one isolation layer: Supported Devin Outposts, Claude Managed Agents, and Cursor Cloud Agents integrations can use Sandbox, subject to partner access and plan requirements.
Persistent snapshots and forks: Save a prepared filesystem for later sessions, then create independent sandboxes from that snapshot.
Active CPU billing on Fluid compute: Time spent waiting for model responses or other input/output does not count toward Active CPU usage. Memory and other applicable charges remain.
Create your first sandbox, or browse templates for an agent starting point.
Copy link to headingFrequently asked questions about cloud agents
Copy link to headingWhy did some background agents become cloud agents?
Vendors changed the product names. Cursor's 2.0 release on October 29, 2025, renamed Background Agents to Cloud Agents, and GitHub had renamed Copilot coding agent to Copilot cloud agent by April 2026. Older articles may use the earlier names, so check the vendor's current documentation when comparing products.
Copy link to headingDoes a cloud agent send my code to outside servers?
Usually, yes. Vendor-hosted cloud agents receive repository contents in their remote execution environments. Self-hosted options can keep tool execution and workspace storage on infrastructure the team controls, but prompts, tool results, and code included in those results may still reach the model provider. Review execution location, model data flows, outbound access, and retention terms separately.
Copy link to headingCan cloud agents pick up work from a local session?
Yes, some products support handoffs in both directions. Cursor, for example, supports moving work between local and cloud sessions. What gets transferred depends on the product and handoff method. Check whether the workflow transfers the conversation, applies code changes, or opens the remote workspace for interactive work.
Copy link to headingHow is a cloud agent different from an AI coding assistant?
Coding assistants can suggest code, answer questions, and run tasks through agent modes. Cloud agents usually execute tasks remotely and return reviewable changes, often as a branch or PR. Local assistants can also handle multi-step tasks, so autonomy alone does not separate the categories.