Platform Comparison for Single-Call Per-Tenant Agent Provisioning in Production Agentic Systems

Single-call per-tenant agent provisioning gives each customer a private, persistent agent environment with one call and no manual setup. Blaxel and Upstash Box are starting points for builders assembling that infrastructure, while managed per-tenant hosting shifts the provisioning work to a provider. The right choice depends on isolation, persistence, startup latency, and credential handling (as well as whether an API can create a sandbox).

Why single-call per-tenant provisioning is a distinct architectural requirement, not a deployment convenience

An agent that acts with the developer’s credentials instead of the customer’s has already failed the production test. So has an agent that reads another customer’s state. A shared instance may work during development, but in production each tenant must have its own state, credentials, and execution context. The boundary must follow each customer within the deployment.

The call must create a tenant environment that is ready to use, with no process left for someone to configure afterward. When each customer needs manual setup, provisioning takes more work as the customer count grows. Four dimensions expose whether a platform can avoid that work, namely its isolation model, state persistence, cold-start latency, and credential handling. A compute-cost comparison misses how those choices interact.

Isolation model and what “per-tenant” means at the execution layer

A sandbox’s tenant boundary depends on its isolation model, with customers separated by processes, a shared kernel, or separate kernels. For agents running untrusted or model-generated code, that distinction changes the consequences of an escape. Shared-kernel containers start quickly, but a container escape can expose the host or another tenant’s data.

MicroVMs give each workload its own kernel. That closes the shared-kernel escape path between tenants, rather than relying only on separation within one kernel. Blaxel uses Firecracker microVMs, while Upstash Box uses isolated containers. Those are different security boundaries, even when both products expose a straightforward sandbox API. Neither choice removes the need to allocate the boundary per tenant.

Self-hosted teams can instead maintain warm pools of gVisor-sandboxed pods, acquiring an idle pod when a request arrives. The operator then owns pool management as well as tenant assignment. Cloudflare Sandboxes reached general availability on April 13, 2026, on the Workers Paid plan, offering an edge-native option that trades VM-level isolation for geographic distribution. These choices solve different deployment problems. A sandbox shared across tenants does not meet the benchmark merely because it separates their namespaces.

The objection to microVMs is provisioning overhead. Stronger separation can make startup harder to engineer, but warm pools and standby snapshots address that cost without weakening the boundary. The platform must address how securely a tenant runs and how it keeps that boundary practical when customers arrive or return.

State persistence and what survives between sessions

A crash test exposed the cost of incomplete persistence. Killing a container after an action but before its transcript was saved caused the resumed agent to start over and send a duplicate email. The action survived in the outside world, but the agent’s record did not. Preserving files alone cannot resolve that mismatch. An idempotency key is the tool-level fix for preventing a repeated action from becoming a duplicate effect.

Other failures happen before any external action. LangGraph’s in-memory checkpointer loses state on restart, so production requires an external store such as Postgres. Claude Code illustrates a less obvious trap. It keeps sessions in ~/.claude, but account details, MCP server configs, and per-project trust live in ~/.claude.json. Mounting only the session directory leaves that configuration outside the persistent boundary.

Files, memory, running processes, and session logs do not necessarily survive the same events. Blaxel distinguishes standby, where state survives without compute billing, from deletion, where sandbox state is lost. Its Volumes provide guaranteed long-term persistence separate from the sandbox lifecycle. Upstash Box auto-pauses when idle and wakes with its files still there, so each user can keep a long-lived box at near-zero idle cost.

Shared memory introduces a separate ownership problem. A prompt injection that writes into a shared memory store can contaminate another tenant’s context even when execution is isolated. Durable execution engines such as Temporal and workflow SDKs address another layer by recording steps so a run can resume after a crash. A persistent filesystem, a tenant-scoped memory store, and a recoverable workflow serve different purposes.

Cold-start latency and when sandbox boot time becomes a user-experience problem

Starting a sandbox pod from scratch can add seconds before an agent begins useful work. Cold starts for self-hosted gVisor pods can take that many seconds. Users experience that delay as part of the agent’s response. With one sandbox per customer, every new tenant’s first session confronts the provisioning path, so startup is not merely an occasional infrastructure event.

Operators keep idle pods ready, then acquire and release them as requests arrive. That avoids boot latency at request time, but requires pool sizing and ongoing management. Ramp takes another approach by starting sandbox warm-up as soon as a user begins typing a prompt. It also recommends warm sandbox pools for high-volume repositories, exchanging resource cost for a faster perceived start.

Blaxel reports sub-25ms resume from standby with filesystem, memory, and running processes intact, while standby billing covers only snapshot storage. That claim applies only to resume, leaving initial provisioning latency unspecified. Upstash Box bills active CPU rather than wall-clock time, so time spent waiting on the model is not billed. The useful comparison separates first creation, return from idle, and the cost of keeping an environment ready.

Credential handling and enforcing tenant identity without exposing secrets

A platform can isolate execution, preserve state, and resume quickly while still acting as the wrong person. Credentials are a separate enforcement boundary. The authenticated request must establish the tenant independently of any tenant identifier the client supplies. Credentials should be injected outside the sandbox, leaving the agent with only a placeholder.

Claude Managed Agents and the OpenAI Agents API keep users’ credentials in a vault and inject them outside the sandbox. That managed injection does not work with self-hosted sandboxes in the configurations described here. A managed vault is not, by itself, proof that a self-hosted agent receives the correct user’s authority.

AWS AgentCore Identity and some Azure Foundry tools handle OAuth sign-in and token storage, but self-hosted deployments still leave tenant-to-session mapping to the application backend. AgentCore’s managed Consent portal handles session binding for Gateway flows, which is a distinct case. Composio works at the tool-integration layer through per-user connected accounts and runtime tool discovery. Its connected accounts hold OAuth tokens so agents can act for the right user without developers having to handle the tokens themselves.

Ownership checks belong on session start, read, stream, resume, and approval operations, with concurrency and spending limits enforced per tenant. Shared memory needs the same ownership boundary. Cross-tenant tests must cover sessions, files, memory, and credentials, because correct execution isolation cannot compensate for a backend that resumes the wrong session.

Pre-action authorization and the gap sandbox isolation does not close

Even with the right isolation, persistence, latency, and credential model, a tool call can remain unsafe. A sandbox limits where an action can run. It does not decide whether a permitted API call has an allowed recipient, amount, or data scope. A legitimate-looking request with malicious parameters can execute within the sandbox’s permitted capabilities.

The March 2026 paper Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents describes the need to authorize tool calls before they execute. It presents Open Agent Passport, or OAP, which intercepts tool calls synchronously, evaluates a declarative policy, and produces a cryptographically signed audit record. The paper reports a measured median enforcement latency of 53ms. Model alignment provides training-time, probabilistic defenses, with enforceable policy at each call serving a separate function.

The OAP paper also reports a live adversarial testbed. Social engineering often succeeded under a permissive policy, while a similar group of attackers had a 0% success rate across 879 attempts under a restrictive policy. That result supports combining model defenses with policy enforcement while recognizing the limits of each. This action boundary is where spending limits for each tenant, restrictions on data classification, and recipient allowlists belong. Sandbox isolation enforces none of them.

Microsoft introduced the open-source Agent Governance Toolkit in April 2026 to address runtime security for agents. The OWASP Top 10 for Agentic Applications, 2026 edition, identifies goal hijacking, identity and privilege abuse, and memory and context poisoning as leading risks. These risks survive a good sandbox choice.

Applying the four dimensions to the named agent runtimes builders are actually choosing

OpenClaw fits builders who need multi-user messaging and self-hosted sub-agent orchestration. Its channels include Slack, Discord, Telegram, WhatsApp, and iMessage, but operators must choose and configure their own sandbox and credential handling. OpenClaw disclosed nine CVEs in four days in March 2026, including one rated CVSS 9.9, making a CVE-watch and patch cadence part of production operation. NemoClaw adds enterprise controls through a CLI plugin, a versioned orchestration blueprint, and an OpenShell runtime that is container-based by default.

Claude Code starts from a different deployment model. It is a local CLI with deep codebase context, suited to single-developer or small-team work and lacking native per-tenant provisioning. Claude Code Channels connects running sessions to messaging services, but the work still runs on the local development machine. For deployments to be persistent, both configuration paths must be mounted, or CLAUDE_CONFIG_DIR must be set to a volume. Tenant isolation and credential management require additional engineering, while Anthropic API outages affect production-critical workflows without a fallback model.

Codex offers an OpenAI-native path with managed infrastructure backing and the benefit of OpenAI’s credential vault and injection model. Codex pairs strong managed credential handling with a provider-chosen isolation design, a different allocation of infrastructure control from a raw sandbox provider. The deployment decision includes how much infrastructure control the builder needs.

Upstash Box is a good choice for coding-agent environments and persistent environments for each user because files survive auto-pause and it bills for active CPU. Its isolated containers remain a different boundary from Blaxel’s microVMs. Blaxel combines that microVM boundary with standby snapshots and fast resume, and is a first-class sandbox provider in the OpenAI Agents SDK. Credential injection remains operator-configured. With either provider, persistence alone falls short of a complete tenant authorization system.

Managed per-tenant hosting offers an alternative to assembling these components. In that model, each customer receives a private, persistent, branded agent activated at onboarding, while the provider handles the provisioning infrastructure. Pre-built integrations through Composio can remove custom OAuth work for services including Gmail, Slack, WhatsApp, and GitHub. The product being bought is tenant provisioning itself. That differs from buying a runtime and building the customer lifecycle around it.

How to provision a dedicated AI agent for every customer without building everything yourself

The first decision is where the provisioning work belongs. Infrastructure builders need control over isolation and credential injection, making raw sandbox providers such as Blaxel and Upstash Box appropriate starting points. Agent product builders already have a working agent and need to distribute it reliably. For them, managed per-tenant hosting can move isolation, persistence, updates, and credential plumbing out of the team’s scope. Operators and SaaS companies adding agents to an existing product fit the white-label model, with tenant activation built into onboarding.

Enforcement follows the same steps with each of those choices. Authentication establishes the tenant, followed by budget, session, context, sandbox, model execution, and persistence. Platform selection determines how much of that sequence is supplied and how much the application must build. It does not automatically add pre-action authorization. All three builder profiles should plan for that explicitly, especially when agents can spend money or access sensitive data.

The practical test is whether one API call can provision a fully isolated, persistent agent for a new tenant, with that tenant’s credentials injected outside the sandbox and no manual operator configuration. The right runtime is the one that passes that test with the division of responsibility the team intends to own.