Blaxel + Claude: secure code execution for AI agents

Your team is building with Claude. The agent works. By default, tool calls that execute code run inside Anthropic-managed cloud sandboxes, though Managed Agents can also be configured to use a self-hosted sandbox. Customer data enters that managed execution environment on every session. 

You can't push an organization-wide egress policy. Self-hosted sandboxes can access services according to your VPC and firewall rules; Anthropic-managed cloud sandboxes can't directly reach services behind your VPC. For teams with compliance requirements or data residency constraints, that combination stalls production deployment.

Claude Managed Agents (CMA) handles orchestration and context management, with error recovery built into the agent loop. Execution placement belongs to the sandbox provider. Anthropic announced Self-hosted sandboxes in public beta. They move tool execution to an external environment your team governs. 

Blaxel integrates with CMA as a self-hosted sandbox provider. Every tool call runs in an isolated microVM with persistent state; network policy is programmable. Standard deployments run in Blaxel infrastructure. An applicable bring-your-own-metal (BYOM) deployment runs the sandbox runtime on customer hardware.

How the Blaxel + Claude Managed Agents integration works

Blaxel plugs into CMA as a self-hosted sandbox provider, splitting responsibilities between Anthropic's agent loop and a customer-governed execution environment. The sections below walk through how that division is structured and what happens during a session.

Control plane and runtime responsibilities

The integration follows an orchestrator/worker architecture. Anthropic's control plane runs the agent loop. That includes model inference and prompt caching, along with compaction, session history, and error recovery. Blaxel handles the runtime side. That covers where code executes and how environments are isolated. It also controls network access and state persistence.

This division keeps the agent's model-side behavior in CMA while making the execution boundary an infrastructure choice. Security and platform teams can apply deployment, region, network, and lifecycle decisions on the Blaxel side without taking over prompt caching or session recovery. Anthropic still receives tool inputs and outputs through its control plane, and Blaxel continues to manage its control plane in BYOM deployments. 

Self-hosting applies to tool execution. Operational ownership therefore centers on worker images and sandbox policies, along with connectivity and lifecycle. Anthropic retains ownership of the agent loop. That separation is the basis for the setup and responsibility model described below.

Anthropic continues to manage orchestration and context handling, with recovery logic built in, according to InfoQ coverage of the May launch. Execution happens inside a customer-governed external environment. With standard Blaxel cloud, that environment runs on Blaxel infrastructure. With an applicable BYOM deployment, the sandbox runtime runs on bare metal inside the customer's infrastructure.

Session execution flow

When a CMA session starts, Anthropic enqueues it as a work item in the environment's queue. An orchestrator sandbox on Blaxel receives the session.status_run_started event. It then claims the work item. Next, it spawns a worker microVM for that session. Blaxel is one of eight pre-built integrations in Anthropic's self-hosted sandbox documentation. Its inclusion shows that it follows Anthropic's documented provider interface.

Managed Agent sessions persist state across interactions, while Blaxel's tutorial describes the worker sandbox as short-lived and auto-deleted after its TTL expires. Tool execution avoids Anthropic's managed sandbox environment, while tool inputs and outputs still cross Anthropic's control plane. 

The agent can install packages and write files, then build projects and accumulate state over minutes or hours. Nothing resets between tool calls. When the session ends, the sandbox can be cleaned up or kept in standby for reuse. Code execution and filesystem operations happen entirely inside the selected Blaxel deployment. Network requests do as well.

What self-hosted sandbox execution provides

The default CMA setup runs tool calls inside Anthropic-managed sandboxes. For many workloads, that's fine. The pressure comes from security review. In McKinsey's March 2026 survey, nearly two-thirds of respondents cited security and risk concerns. They identified those concerns as the top barrier to scaling agentic AI. 

Self-hosted execution changes the main areas those reviews examine for code-executing agents. They are the data boundary and egress control, along with state persistence and session isolation.

Keep execution inside a governed infrastructure boundary

With self-hosted sandboxes, the agent's code and filesystem stay in your environment. Network egress stays there too. In the default setup, code execution isn't eligible for zero data retention. Container data may also fall under a 30-day retention window. That distinction decides procurement outcomes for regulated data.

A Blaxel environment replaces Anthropic's managed sandbox as the execution boundary. Standard Blaxel cloud runs on Blaxel infrastructure under customer-selected policies and configuration. For execution on customer hardware, an applicable BYOM deployment runs the runtime on customer-provided bare metal. Blaxel's control plane remains managed by Blaxel in that model.

Any service handling electronic protected health information is a business associate, even without decryption keys. That service therefore needs a BAA under HHS guidance. Blaxel says it holds SOC 2 Type II and ISO 27001 certifications. HIPAA support is available under a signed BAA.

Placement is configurable too. Worker sandboxes can be pinned to a specific Blaxel region. Options include us-pdx-1 in Oregon and eu-lon-1 in London. Frankfurt's eu-fra-1 is another option. Teams with residency obligations can keep execution inside a chosen jurisdiction. They do not have to accept default routing.

Some compliance postures block sending customer data to a third-party sandbox at all. Those teams require BYOM execution on customer hardware. Pick your required deployment model and region before the first production session. Then pin worker sandboxes to that configuration.

Control network egress per agent session

Blaxel exposes programmable outbound allowlists and proxy-resolved credentials for CMA worker sandboxes. Allowlistable egress IPs are also available. Maturity varies, so check each status below against your requirements.

• Domain filtering: Restricts outbound traffic to an allowlist. It is in public preview. Enforcement depends on tools respecting HTTP_PROXY and HTTPS_PROXY. Routing-level enforcement is planned.
• Proxy secrets injection: Resolves credentials server-side at the proxy. As a result, the sandbox runtime never sees raw secret values. It is in public preview, and the docs do not recommend it for production yet.
• Dedicated egress gateways: Route outbound traffic through allowlistable IPs assigned only at sandbox creation. This feature is in private preview.
• Custom domains: Generally available for sandbox previews.

Against that set, the default managed sandbox offers less. Admins have no organization-level allowlist they can push across environments. A session running in Anthropic's cloud sandboxes can reach private MCP servers through a tunnel to access internal resources. Direct open-network access from Anthropic-managed sandboxes to private, internal, or VPC-only services is unavailable. For agents needing internal databases or VPN-protected APIs, Blaxel offers private network connectivity for enterprise customers.

Start by listing the internal services your agent needs. Then match each service to a control and check preview status against your requirements. Walk preview-status controls past your security reviewer. Get written sign-off before you count them as production controls.

Persist state across long-running sessions

CMA sessions can run for hours. A worker sandbox on Blaxel holds full filesystem and memory state throughout the session. Sandboxes move to standby and resume. Standby happens after a short period of inactivity, and resume takes under 25 milliseconds. They return to standby after 15 seconds of network inactivity. The in-memory filesystem and running processes stay intact.

A configured TTL can delete a sandbox for automatic cleanup, while sandboxes can otherwise remain in standby indefinitely with no platform-imposed standby-duration cap.

External network connections aren't preserved across standby. That includes database connections and HTTP pools. Agents should reconnect on resume. Put a reconnect step at the top of your agent's resume path. This rebuilds database and HTTP pools before the next tool call. 

For state that must outlive one sandbox, durable Volumes provide single-sandbox block storage. They support raw I/O performance and long-term persistence. Agent Drive is a distributed shared filesystem for data and artifacts across multiple sandboxes and sessions. It is in private preview and supports agent collaboration through shared storage.

In multi-step workflows, for example, an agent can clone a repository and install dependencies, then run tests and iterate on patches. It pays the setup cost once per session. Anthropic may still retain managed package caches between sessions. 

The default managed sandbox preserves no user-controlled filesystem state across sessions. Therefore, user-controlled setup costs return with each new session. This persistence makes long-running autonomous coding and analysis tasks viable on CMA.

Run multi-agent architectures with isolated sessions

The orchestrator maps each CMA session to its own worker microVM. Each worker has an independent filesystem and process space; its network space is independent as well. That boundary matters because agents execute model-generated code. Such code is untrusted by definition.

Containers share the host kernel and provide less segmentation than a hypervisor boundary. This distinction appears in NIST SP 800-190. Containers remain standard for trusted first-party services. The risk is specific to arbitrary code.

MicroVM isolation puts a hardware boundary around each workload. It also gives the workload a separate guest kernel. Lambda tenant isolation uses the same class of boundary for untrusted tenant code. According to the Firecracker design paper, a typical Ubuntu Linux 15.04 installation requires 224 syscalls to run without problems and exposes 52 unique ioctl calls. A microVM moves that boundary into hardware behind a much smaller virtual machine monitor.

A compromised or runaway agent can't reach another session's data or processes in multi-tenant products. Those products rely on per-session boundaries to serve many customers from one environment.

How to set up Blaxel as a self-hosted sandbox for Claude Managed Agents

Create a self-hosted environment in the Anthropic Console and deploy the Blaxel orchestrator. Then verify the end-to-end flow. Prerequisites are a Claude API key and a Blaxel workspace with an API key. Most Managed Agents requests carry the managed-agents-2026-04-01 beta header, but memory store endpoints instead require the agent-memory-2026-07-22 beta header.

1. Create a self-hosted CMA environment in the Anthropic Console

In the Anthropic Console, navigate to Workspace > Environments > New > Self-hosted. This tells Anthropic's control plane that tool calls execute on external infrastructure. You can also create the environment from the CLI using Anthropic's self-hosted sandbox docs:

ant beta:environments create \

  --name self-hosted \

  --config '{"type": "self_hosted"}'

Record the environment ID, formatted as env_..., from the response. Then open the environment in the Console and click Generate environment key. Key generation is Console-only, regardless of how you created the environment. The key uses the format sk-ant-oat01-....

You'll work with two credentials from here. The environment key authenticates the worker to its work queue. Your Claude API key creates sessions and reads queue stats from outside the worker host. Keep both handy.

The Blaxel setup script consumes them in the next step. No Blaxel configuration happens yet. This step takes minutes and is purely Anthropic-side.

2. Deploy the Blaxel orchestrator

Clone the sample repository. Set ANTHROPIC_API_KEY and BL_WORKSPACE as environment variables, along with BL_API_KEY. Also set ANTHROPIC_ENVIRONMENT_ID and ANTHROPIC_ENVIRONMENT_KEY from step 1. Then run python3 setup.py. Authenticate the CLI with bl login, then push the worker and orchestrator images:

cd worker

bl push --workspace "$BL_WORKSPACE" --type sandbox

( cd orchestrator && bl push --type sandbox )

The orchestrator is a long-running Blaxel sandbox that exposes a public preview URL. Register that URL as a webhook endpoint in the Anthropic Console. Subscribe it to session.status_run_started, the only event the orchestrator consumes. Rerun setup.py with ANTHROPIC_WEBHOOK_SIGNING_KEY set. The orchestrator can then validate webhook payloads.

The worker uses a Node-based image. It includes Blaxel's sandbox API. It also includes the MCP server exposed by each sandbox for structured tool calls. The surface supports file and process operations, with separate code-search calls. Available calls include processExecute and fsWriteFile; codegenGrepSearch is also available. Custom Docker images work if they copy in the sandbox API binary.

bl push publishes the image only, as covered in the Blaxel CMA tutorial. It does not create a sandbox deployment or restart running processes. Set BLAXEL_WORKER_TTL above your longest expected session. The TTL defaults to two hours. Blaxel deletes the worker when it expires. Once deployed, the orchestrator claims new CMA sessions with no per-session configuration.

3. Verify the integration

Create a CMA session through the API or SDK. From a shell with your Claude API key set, confirm queue connectivity:

ant beta:environments:work stats --environment-id "$ANTHROPIC_ENVIRONMENT_ID"

Confirm that a worker is polling. Watch the worker sandbox status with bl get sandbox --watch. Stream tool-call logs with bl logs sandbox --follow. The worker appears in the watch output when the session starts. Its process exits shortly after the session goes idle. Blaxel deletes the sandbox when the TTL expires.

Run one tool call, such as a shell command or file write. Confirm that the result reaches Claude in the session transcript. After the session finishes, rerun the ant beta:environments:work stats command. Confirm that the queue drained instead of leaving work items stranded.

The Blaxel Console shows per-process execution logs in the sandbox detail page's Logs section. A Terminal tab on the same page lets you inspect the worker filesystem directly. That includes any files the agent wrote during the run. Together, these views confirm the whole flow.

You can trace the session start and the orchestrator's claim, followed by worker creation. Then follow tool execution and result delivery before Claude acts on the output. From this point, any CMA session targeting the environment runs on the selected Blaxel deployment automatically.

How Blaxel + Claude compares to default CMA execution

The choice between default and self-hosted CMA execution comes down to how much infrastructure control your workload requires. The sections below compare responsibilities under each model to help you decide which fits.

Default CMA responsibilities

Default CMA execution works well for teams without infrastructure requirements. Anthropic provisions a fresh, isolated Linux container per session. It publishes that the underlying isolation mechanism uses isolated Linux containers, and Anthropic's broader engineering documentation further specifies gVisor-based containment. The container runs Ubuntu 22.04 with up to eight GB of memory and 10 GB of disk under the sandbox reference specs. That fixed session footprint gives teams a documented baseline for evaluating whether the managed environment fits their workloads.

Anthropic also pre-installs packages and caches them across sessions sharing the same environment. Credentials go through a managed vault that substitutes secrets at egress. There's nothing to deploy, no orchestrator to maintain, and no lifecycle to monitor. For prototyping and internal tools, as well as workloads without compliance constraints, it's the faster start.

Teams gain convenience by accepting less infrastructure control. They accept Anthropic's execution placement and lifecycle. Its networking model is part of the same tradeoff for avoiding worker deployment and monitoring. That makes the default path easier to evaluate quickly, while security review still has to decide whether the managed boundary and available connectivity fit the workload.

Self-hosted CMA responsibilities

The self-hosted CMA integration has an operator-managed deployment model. Your team deploys the worker fleet and monitors its images and TTLs. It also manages sandbox lifecycle decisions. These are implementation responsibilities of Anthropic's self-hosted integration pattern.

For self-hosted environments, Anthropic's self-hosted sandbox documentation says to pass file or GitHub repository pointers via sessions.create(metadata={...}) and have your orchestrator fetch or clone them before dispatch; current support excludes memory_store resources. The model provides control over data residency, network egress, credential handling, and the execution environment.

Choose the deployment model according to the workload. Coding and PR review agents often process regulated customer data. Data analysis agents can too. They may also need internal services. Those workloads and multi-tenant products can use the self-hosted path to address requirements raised during production review. 

Agents handling non-sensitive tasks without infrastructure requirements may be better served by the default when its managed gVisor/container boundary is acceptable under the workload's untrusted-code threat model and security review. Self-hosted execution is appropriate when infrastructure control is a production requirement.

How to run Claude agents with secure, self-hosted code execution

The gap between a working demo and a production Claude agent is often the execution environment. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027. Inadequate risk controls are among the named causes. Production reviews demand control over where code runs and which networks it reaches. 

Credential handling is another requirement. Self-hosted sandbox execution moves the execution boundary and network policy into the governed environment. It also supports credential controls. The agent loop stays with Anthropic. Tool execution moves to a customer-governed environment.

Blaxel provides infrastructure for autonomous agents and offers a perpetual sandbox platform. It integrates with Claude Managed Agents as a self-hosted sandbox provider. Blaxel Sandboxes give every worker isolated execution and fast resume from standby. State persists across every tool call in a session, with programmable networking controls on top. Volumes cover data that needs to outlast any single sandbox. 

Teams get the full CMA harness with execution controls in a customer-governed Blaxel environment. Generally available capabilities can support production use, while preview networking controls require separate review. BYOM is available when execution must remain on customer hardware.

Talk to the team at blaxel.ai/contact or start building at app.blaxel.ai.

FAQ

What is self-hosted sandbox execution for Claude Managed Agents?

Choose it when a production review requires control over runtime placement and egress, or when the agent needs access to private services. Self-hosting applies to tool execution. Anthropic still runs the agent loop and receives tool inputs and outputs. With BYOM, execution stays on customer hardware, while Blaxel continues to manage its control plane.

Does self-hosted execution affect Claude's agent capabilities?

memory_store is currently unavailable in self-hosted environments. Pass file or GitHub repository pointers through sessions.create(metadata={...}) and fetch or clone them before dispatch. Claude's reasoning loop is otherwise unchanged. Also confirm that the worker image and MCP server expose every file and process operation your workflow expects, along with the required code-search operations, before migrating production sessions.

What compliance coverage does Blaxel provide for Claude agent execution?

Map each requirement to a deployable configuration. Blaxel holds SOC 2 Type II and ISO 27001:2022 certifications. It also signs BAAs for HIPAA workloads. Zero data retention is available when sandboxes are deleted without entering standby. That option trades standby resume for 200–600ms initial creation. Teams choosing ZDR should therefore budget for recreation instead of standby resume.

Can multiple Claude agents run in isolated sandboxes simultaneously?

Yes. Treat each concurrent CMA session as a separate worker-capacity unit: each gets an isolated microVM and does not share filesystems or processes unless shared storage is configured. Orchestrators compete for work from the same environment queue, and one orchestrator claims each item. Set BLAXEL_WORKER_TTL above the longest expected run, then size and monitor the fleet for peak concurrency.