Single API Call Provisioning for Per-User Agent Sandboxes

Single API call provisioning for per-user agent sandboxes turns customer onboarding into one reproducible infrastructure operation. The call creates an isolated environment, attaches persistent state, scopes credentials, and registers its lifecycle. This is the right architectural pattern for agent-powered products because every customer gets a dedicated agent environment without the founder hand-configuring another server.

Why provisioning one agent per customer is an infrastructure problem, not a product problem

The demo works, but customer two needs another environment. Someone has to install dependencies, attach storage, configure credentials, and decide what happens when that customer's agent stops running. A founder who repeats them for each signup has built a working agent without yet building a repeatable way to deliver it.

That gap becomes expensive before the product becomes large. Each customer needs an execution environment of their own, with persistent state, a credential boundary, and a lifecycle. Unlike conventional software, the agent reads files, calls APIs, runs generated code, and chooses actions dynamically, so reusing an environment introduces risks beyond untidy configuration. Hand-provisioning a VPS, Docker container, or cloud VM turns each signup into another infrastructure assignment. The missing step is an onboarding flow that provisions the customer's agent automatically.

What "single API call provisioning" actually means at the infrastructure level

A single provisioning call creates the execution boundary and connects the services that make it usable. That boundary might be a microVM, an isolate, or a hardened container. Persistent storage or memory state lets the agent resume without rebuilding its working context. Host-level credential handling makes authorized operations available without putting raw secrets inside generated code's environment. Lifecycle registration governs idle pauses, on-demand resumes, and clean teardown.

The call is an interface to that whole operation. It replaces the sequence in which a developer connects to a server, installs dependencies, sets environment variables, and configures monitoring. Those steps still take infrastructure work, but no one has to carry them out by hand in the customer onboarding flow.

Cloudflare's Dynamic Worker Loader illustrates the isolate part of this pattern. One API call instantiates a Worker in its own V8 isolate using code supplied at runtime, usually on the caller's thread. A one-off load() call does not need to find a warm sandbox across the network, while get() can reuse a warm, cached isolate. That execution mechanism is one component of the full provisioning contract, which handles isolation, persistence, credential scoping, and lifecycle registration.

Why isolation cannot be optional when agents execute arbitrary code at runtime

Generated code can act on input that an attacker controls. Ambient authority lets the agent inherit permissions from its environment whether or not a particular task needs them. A malicious instruction can work without a software exploit. It can simply tell an authorized agent to use the database credentials, API tokens, or filesystem access it already has.

Tool poisoning can hide instructions in an MCP tool that looks legitimate. A document submitted for summarization can instruct the agent to read SSH keys if those files are reachable. A compromised MCP server can capture API tokens during tool discovery if they are present in the execution environment. A compromised session can also reach internal infrastructure if it has network access and has inherited service-mesh credentials.

Role-based access control alone cannot distinguish those instructions from legitimate requests made by the same authorized process. Standard containers also share a host kernel, so a kernel vulnerability can open a path across tenant boundaries. Firecracker and Kata give workloads separate kernels, removing that particular shared-kernel route rather than guaranteeing that every escape is impossible. A fresh execution boundary limits what can carry over between runs, while user state kept on purpose needs to be handled separately. That boundary must also start quickly enough to be useful.

How startup latency determines whether per-user isolation is usable in an agent loop

In an agent loop, the agent decides what to do, calls a tool, reads the result, and decides again. If the environment is not live, each tool call pays its startup cost. Sequential calls compound that delay. Slow startup can push the agent toward broader, less precise actions simply to reduce the number of calls, making latency a workflow constraint.

The technology choice changes that constraint directly. Standard containers start in hundreds of milliseconds but share the host kernel. Firecracker microVMs start in approximately 125ms with separate kernels, while gVisor uses user-space kernel interception and offers compatibility with a container orchestration platform with stronger separation than plain containers. Google uses gVisor for the first-generation execution environment in Cloud Run and for Cloud Functions. Cloudflare's isolates start in milliseconds and use megabytes of memory, without requiring a warm pool.

Memory determines density as well as startup behavior. Containers need a baseline of 50–100MB, gVisor adds 30–50MB for its application kernel, and Firecracker guests with a minimal setup need 128–256MB. Blaxel addresses a different part of the problem through indefinite standby at zero compute cost, resuming in under 25ms with filesystem, memory, and running processes intact. Keeping a customer's environment asleep avoids rebuilding it without reassigning a running container to another user. Fast creation or fast resume makes dedicated per-customer environments practical without using cross-user reuse as a shortcut.

How credential isolation changes where secrets live and what a compromised run can reach

In the “Agent IN Sandbox” pattern, the agent runtime and generated-code execution share a boundary, so the API keys the agent needs also live inside it. A successful compromise can therefore reach credentials as well as code and files. Stronger isolation from other tenants does not remove that exposure within the compromised tenant's environment.

“Sandbox as Tool” separates those two roles instead. The agent runs on the operator's server and calls a disposable sandbox when it needs code execution. Secrets stay outside that sandbox. A compromised execution environment then has no raw host credentials to steal, though the operator still needs to take care in choosing which actions the agent is allowed to take.

Cloudflare implements host-mediated outbound access through globalOutbound. A host-level handler intercepts outbound HTTP requests from generated code and can inspect them, rewrite them, inject authentication keys, or block them. The code requests an operation without handling the key directly. Composio's connected accounts provide a related boundary by storing each user's OAuth credentials and brokering tool calls on the agent's behalf. Together, these mechanisms separate access to an authorized operation from possession of the secret that authorizes it.

What persistent state per user means for agent continuity and why it is architecturally distinct from caching

Persistent state preserves work. Files the agent wrote, repositories it cloned, and packages it installed form part of its working environment. Memory can preserve variables, loaded datasets, and interpreter state, while process preservation lets background services or watchers continue after standby. A data analysis agent can then pick up its work without loading the same dataset on every tool call.

Blaxel's standby preserves filesystem, memory, and running processes, but does not provide a durability guarantee. Deleting the sandbox destroys that state, while Volumes provide guaranteed long-term persistence beyond the sandbox lifecycle. Upstash Box illustrates the user-facing economics of a narrower promise, automatically pausing when idle and waking weeks later with files intact. An environment can last a long time without the user paying for compute to run the whole time.

Continuity belongs to the user: untrusted code can run in a fresh sandbox and use per-user state kept on purpose as the context for its work. That distinction reconciles clean execution with an agent that remembers. Rebuilding everything on each invocation uses up tokens, takes more time, and loses work done along the way. The persistent environment becomes the user's “agent home,” rather than a generic session that resets whenever they leave.

How integration breadth at the host level determines what a per-user agent can actually do

An isolated environment is useful only if the agent can reach the tools its job requires. OAuth, webhooks, and API authentication across users introduce another provisioning burden beyond compute. Composio's connected accounts keep each user's OAuth credentials separate and broker access on that user's behalf. This lets the host provide managed integration access without the operator handling individual tokens. Compute isolation alone cannot supply that capability.

The integration layer also becomes a shared dependency. In April 2026, Composio experienced cumulative API degradation and webhook unavailability affecting Slack, Outlook, Notion, and HubSpot. A cleanup job stopped pruning a trigger-processing table, creating a growing backlog and cascading timeouts. Webhook triggers for several apps were unavailable for 36 hours. Operators need circuit breakers and application-level fallback behavior because a healthy sandbox cannot compensate for an unavailable integration service.

A common protocol addresses portability. Anthropic, OpenAI, Google, Microsoft, and AWS have adopted the Model Context Protocol. Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation for neutral governance. Tooling built on that standard need not be locked to one platform, but protocol compatibility does not make a particular integration provider continuously available.

What the provisioning pattern means for operators building agent-powered products at scale

For operators, the lesson is to make customer onboarding the trigger for provisioning and eliminate the manual setup job. The customer becomes the unit of scale. The first customer receives an environment through the same operation used for the tenth, rather than through a founder's one-off configuration. By the hundredth, growth should repeat the provisioning contract. When the platform handles provisioning, monitoring, and recovery, the operator no longer has to do those jobs for each customer.

The Stripe analogy explains the division of responsibility. A software company taking payments can call an API. An agent-powered product can likewise consume a hosting contract rather than assemble and operate every customer's environment itself. For a B2B product, that environment can also use the operator's brand, giving each end-customer a private, persistent agent activated at onboarding.

Cloudflare offers runtime-created isolates and host-mediated outbound requests, Blaxel emphasizes rapid resume with live working state, and Upstash Box shows idle pauses with retained files. Composio manages access to integrations, while the execution boundary comes from elsewhere. Compare what each complete system does during onboarding to check that it gives the customer the isolation, state, credentials, and lifecycle behavior they need.

The failure modes that single API call provisioning prevents — and the ones it does not

A reproducible call removes the configuration drift of hand-built customer environments. Per-user boundaries keep one customer's retained state from becoming another customer's working context, while host-level secret injection keeps raw credentials outside the environment where compromised generated code runs. Platform-managed lifecycle handling also removes the founder's recurring job of provisioning and recovering individual instances. A short API surface is not itself proof of a sound boundary.

The pattern does not stop malicious instructions from reaching an agent. Isolation contains their effects rather than providing deterministic prevention of prompt injection. It also cannot repair an unavailable integration layer. Fallback behavior remains an application responsibility. Nor does it make the agent's decisions correct. An agent that deletes the wrong files or makes unintended API calls can still do damage within its authorized scope.

Operators must design the agent's behavior and integration surface carefully, while the provisioning platform handles the repeatable environment contract. Single API call provisioning is the infrastructure contract that says “this environment is isolated, persistent, and credential-scoped for this user”, the operator's job is to build an agent worth running inside it.