Bringing Claude self-hosted sandboxes to OpenShell on Red Hat AI

The promise of enterprise AI agents is straightforward: Let the model think, Let the code run, and keep everything under your control.

Until now, this promise was hard to deliver. If you wanted Claude to write and execute code for your team, you had 2 options: 

• Run everything on the cloud and accept that your data, your code, and your execution environment live outside your perimeter. 
• Build the entire orchestration stack yourself and lose the intelligence that makes managed agents valuable.

Anthropic's self-hosted sandboxes for Claude Managed Agents change that equation. Effectively, this capability outsources the “thinking” while keeping the “doing” on your own infrastructure.

We tested this with OpenShell, an open source project started by NVIDIA where Red Hat is an active contributor. The integration works out of the box, on both a developer laptop with Podman and a Red Hat OpenShift AI cluster. Here is what we learned.

Outsource the thinking, keep the doing

Anthropic runs the orchestration layer, including the Claude model, conversation management, tool routing, and retry logic. You run the execution layer, an environment worker on your infrastructure that polls for tasks, executes them locally, and posts results back.

Your data, your files, and your execution results stay on your infrastructure. The model reasons in Anthropic's cloud and sends tool calls to your worker. Everything that matters stays inside your perimeter.

Self-hosting is the right fit when agents need to operate on data that cannot leave your network, reach internal services that are not publicly routable, or run under your organization's own audit controls.

Greater security posture for execution (the where)

Anthropic's self-hosted model solves where code executes but it doesn’t address the security needs of the execution itself. The documentation describes the worker model and session lifecycle, but isolation, policy enforcement, and credential protection within the sandbox are the customer's responsibility.

That is the gap OpenShell fills.

OpenShell is an open source sandbox runtime for AI agents, started by NVIDIA, where Red Hat is an active contributor and maintainer. It wraps the execution environment with kernel-enforced defense, including Landlock file system restrictions, seccomp system call filtering, network namespace isolation, per-binary Open Policy Agent (OPA)/Rego network policy, and L7 HTTP inspection through Transport Layer Security (TLS) interception.

Agent-generated code runs more safely, even if the agent itself gets prompt-injected. Here is what that looks like in practice.

Per-binary network policy. OpenShell identifies the exact binary making each outbound connection, verifies its SHA-256 hash, and evaluates policy. A rule can allow the agent runtime to reach api.github.com but deny curl from reaching the same host. If a compromised agent spawns a subprocess to exfiltrate data, the proxy catches it because the subprocess has a different binary hash. Standard containers tell you which pod made a request. OpenShell tells you which binary inside the pod made a request to which URL path.

Credential isolation. Secrets are never stored inside the sandbox. OpenShell's inference routing proxy intercepts outbound model API calls and injects credentials at the network boundary. The agent calls a local endpoint that carries no keys. Even if the agent is compromised, there is nothing to exfiltrate.

Deny-all by default. Every sandbox starts locked down. All network egress denied. All file system paths restricted. All credentials removed. You explicitly grant access to what the agent needs. This posture works in air-gapped environments where the only permitted egress is the poll endpoint for Anthropic's work queue.

Structured denial intelligence. Blocked connections are not silently dropped. OpenShell deduplicates denials by host, port, and binary, then generates policy proposals with confidence scores. Security teams get visibility into what agents are attempting, and the sandbox learns from its own denials over time.

Figure 1: OpenShell enhances the security of the execution layer while Anthropic handles the reasoning. Same isolation on any driver

How it works together

The integration point is Anthropic's container-per-session pattern. Their documentation describes a spawn.sh script that launches a fresh container for each session. We replaced that container with an OpenShell sandbox.

An environment worker polls Anthropic's work queue. When a user starts an agent task, Anthropic enqueues a session. The worker running inside an OpenShell sandbox claims it and executes the agent's tool calls (bash, file read, file write, file edit) inside the sandbox with full policy enforcement. Results go back to Anthropic. The sandbox is torn down when the session completes.

source ~/.ant-env
ant beta:environments create --name self-hosted \
    --config '{"type": "self_hosted"}'
ant beta:agents create --name secure-agent \
    --model claude-sonnet-4-6
ant beta:worker poll --workdir /workspace

Each session gets its own OpenShell sandbox. The worker passes in only the environment key (never your API key) and tears down the sandbox when done.

In the demonstration, the AI agent never executes code (shell commands, file operations, etc) directly on the host machine:

• The OpenShell worker polls Anthropic for work
• Anthropic sends tool execution requests (bash, file read, file write, file edit)
• OpenShell executes those requests inside an isolated sandbox with full policy enforcement
• Generated files remain confined inside the sandbox
• Data only leaves the sandbox through explicit extraction steps
• The sandbox is destroyed when the session completes

Figure 2: Claude Managed Agents self-hosted environment, active

Figure 3: Claude Managed Agents, active agents running claude-sonnet-4-6

Figure 4: Claude Managed Agents sessions, idle sessions linked to test-agent-with-tools

From laptop to cluster on the same architecture

We tested on 2 OpenShell drivers to confirm that the promise holds across environments.

The OpenShift driver runs the sandbox as a Kubernetes pod on OpenShift with all 5 enforcement layers. This is where you run in production. The OpenShift driver creates the pod, applies policy, and manages the lifecycle through the OpenShell gateway. See it in action:

The Podman driver runs the sandbox as a rootless container directly on a developer laptop. Landlock and SELinux enforcement come from Linux Security Module (LSM) enablement, giving you kernel-enforced file system, system call, and network policy without requiring Kubernetes or root privileges. See it in action:

Same code. Same isolation model. Same security posture.

OpenShell supports additional drivers beyond the 2 we tested here, including podman, libkrun microVMs, Docker, and vanilla Kubernetes. The architecture is driver-agnostic. If your infrastructure runs containers, OpenShell can sandbox agents on it.

In both cases, credentials were physically separated from the execution environment. The integration required no changes to the Anthropic worker model. The code is available here.

Why this matters

Your data stays home. The model reasons in the cloud. Code runs on your infrastructure. It can query your database, run Prometheus queries across your clusters, or process records containing PII. Only the sanitized results go back to Anthropic. You outsource the intelligence without outsourcing the risk.

Untrusted code runs safely, wherever you run it. Agent-generated code is inherently untrusted. OpenShell treats it that way from the start, with deny-all defaults, credential isolation, and per-binary policy enforcement. This works on a developer laptop, on an OpenShift cluster, in an air-gapped environment, or on bare metal with Podman. As we described in Every layer counts: defense in depth for AI agents on Red Hat AI, putting an agent in a container is not enough. OpenShell adds 5 layers of kernel-enforced isolation on top.

One architecture, everywhere. Teams build and test locally with Podman, then deploy the same isolation model to OpenShift without rearchitecting anything. The driver changes. The security posture does not.

What comes next

OpenShell is planned for integration into the Red Hat AI platform, which would give enterprise teams secure agent sandboxing as a native platform capability.

The Anthropic integration described here is one pattern. In a follow-up post, we cover the broader picture and explore three distinct modes of agent sandboxing, from full containment to execution-only isolation, and how Red Hat AI with OpenShell covers each of them.

The implementations described in both posts are early validations, not shipping Red Hat AI product features yet. The patterns are proven. The engineering work to productize them is underway.

One more thing. The best AI reasoning in the world should not require you to give up control of your execution environment. Outsource the thinking. Keep the doing. That is the architecture enterprises need, and it's the one we're building.