OpenShell + SuperInference: Running Autonomous AI Agents at Scale in Secure Container Sandboxes

If 2025 was the year of “look what this agent can do” demos, 2026 is the year the industry is asking a harder question: what is the trust boundary for an agent that can actually act?

Autonomous AI coding agents can now write code, execute shell commands, read and modify files, make API calls, and iterate on their own output. That’s powerful — and dangerous. An agent with unrestricted access to your host system is one prompt injection away from exfiltrating credentials, deleting production databases, or sending unauthorized network requests.

NVIDIA OpenShell solves this by providing sandboxed container runtimes for AI agents — every session isolated, every resource metered, every permission verified before execution. And SuperInference AMI is now a validated flavor image in this ecosystem, making it the first autonomous coding agent that combines multi-provider LLM routing, zero cold-start deployment, and container-native detached execution in a single, minimal image.

This post covers the architecture, the integration, and why this combination is the key building block for running autonomous agents at enterprise scale.

What is OpenShell?

OpenShell is an open-source project from NVIDIA that applies the isolation principles of a web browser to agentic AI workflows. Every agent runs inside its own sandbox — a container with kernel-enforced security boundaries:

• Landlock file system restrictions — agents can only touch what you allow
• seccomp system call filtering — dangerous syscalls are blocked at the kernel level
• Network namespace isolation — every outbound connection is intercepted and evaluated against policy
• Per-binary network policy — OpenShell identifies the exact binary making each connection, verifies its SHA-256 hash, and applies rules. A compromised agent that spawns a subprocess to exfiltrate data gets caught because the subprocess has a different binary hash
• 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 architecture is deny-all by default: every sandbox starts locked down. You explicitly grant access to what the agent needs via declarative YAML policies.

Why AMI for OpenShell?

The OpenShell ecosystem follows a thin-base + flavor pattern. A minimal UBI (Red Hat Universal Base Image) base provides OS-level dependencies, and each agent gets its own flavor image containing only what it needs.

Here’s how the flavors compare:

Image	Size	Cold Start	License	Runtime Downloads
openshell-ami	~200-250 MB	Instant	Apache 2.0	None
openshell-claude	~350-400 MB	10-20s	Proprietary	Every boot
openshell-codex	~350-400 MB	Instant	Apache 2.0	None
openshell-adk	~300-350 MB	Instant	Apache 2.0	None
upstream monolith	2.81 GB	Fast	Mixed	Varies

AMI has the smallest footprint of any flavor because it ships as a single compiled binary — no Node.js runtime, no Python, no npm packages in the container. The result is an image roughly 12x smaller than the upstream OpenShell Community monolith.

And because AMI is licensed under Apache 2.0, the binary is baked in at build time. No runtime downloads from vendor CDNs. No licensing workarounds. No cold-start penalty. Mirror the image to an internal registry and it works immediately — critical for air-gapped and enterprise environments where runtime internet access is prohibited.

Compare this with Claude Code’s proprietary license (“All rights reserved”), which requires downloading the agent from Anthropic’s CDN on every uncached boot — a 10-20 second cold-start penalty and a hard dependency on external network access.

The Integration: Container-Native Detached Mode

AMI wasn’t adapted for container deployment — detached mode is a first-class execution path designed from the ground up for autonomous, non-interactive operation. No REPL, no TUI, no human in the loop.

The execution model is simple:

# Pass a task, get structured output, read the exit code
podman run --rm \
  --tmpfs /dev/shm:rw,nosuid,nodev,exec,size=2g \
  -e AGENT_PROMPT="Fix the failing tests in src/auth/" \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  -v ./myproject:/sandbox/project \
  ghcr.io/superinference/openshell-ami

Under the hood:

1. The entrypoint detects the agent name, verifies the binary is present, writes a startup probe marker at /tmp/agent-ready, and execs into AMI detached mode
2. AMI receives the task via --prompt or AGENT_PROMPT
3. With --yolo, AMI executes autonomously within the sandbox policy — no permission prompts
4. Output streams as structured JSONL to stdout — complete execution traces, tool call logs, file changes, and audit events
5. AMI exits with a semantic status code: 0 (success), 1 (error), 2 (permission denied), 3 (max turns reached), 4 (aborted)

This makes AMI trivially integrable with any orchestration system that can run containers: Kubernetes Jobs, GitHub Actions, CI/CD pipelines, batch schedulers, or the kagenti operator.

Kubernetes Deployment

For platform-managed deployments, AMI works with the kagenti operator via an AgentRuntime custom resource:

apiVersion: kagenti.dev/v1alpha1
kind: AgentRuntime
metadata:
  name: code-review-agent
spec:
  harness: ami
  image: ghcr.io/superinference/openshell-ami:latest
  env:
    - name: ANTHROPIC_API_KEY
      valueFrom:
        secretKeyRef:
          name: llm-credentials
          key: anthropic-key
    - name: AGENT_PROMPT
      value: "Review the pending PR and post findings"
  resources:
    limits:
      memory: 4Gi
      cpu: "4"

The operator resolves the harness to a validated image, manages lifecycle, injects sidecars for telemetry and identity, and exposes the agent as a managed service.

FRITO: The Universal Agent Flavor

Every other agent in the OpenShell ecosystem is locked to a single LLM provider. openshell-claude needs Anthropic. openshell-codex needs OpenAI. openshell-adk needs Google.

AMI’s FRITO (Free-tier Retrieval & Inference Token Ops) makes openshell-ami the universal agent flavor. A single image works with any model backend:

• Cloud providers: Anthropic, OpenAI, Google, DeepSeek, xAI, Mistral
• Free-tier routing: GROQ, OpenRouter, GitHub Models, Cerebras, HuggingFace, Together.AI
• Self-hosted: Ollama, vLLM, any OpenAI-compatible endpoint, Red Hat AI (RHOAI)

FRITO rotates across providers with automatic fallback, quota tracking, and cost optimization. In our benchmark, FRITO scored 100% using only free-tier APIs — matching Claude Opus 4 and beating both Gemini models.

For air-gapped deployments, point AMI at a local Ollama or vLLM instance:

podman run --rm --network=none \
  --tmpfs /dev/shm:rw,nosuid,nodev,exec,size=2g \
  -e DEFAULT_PROVIDER=ollama \
  -e OLLAMA_HOST=http://ollama.internal:11434 \
  -e AGENT_PROMPT="Audit src/ for security vulnerabilities" \
  -v ./codebase:/sandbox/project \
  ghcr.io/superinference/openshell-ami

No internet access needed. Zero vendor CDN dependencies.

Two-Layer Security Model

Running AMI inside OpenShell creates a defense-in-depth architecture with two independent security layers:

Outer Layer: OpenShell Sandbox Policy

• Container isolation — non-root sandbox user, restricted mounts, network policy
• Filesystem confinement — writes limited to /sandbox and /tmp
• Resource limits — CPU, memory, disk quotas enforced by cgroup
• Network controls — outbound filtered, inbound blocked by default
• Credential injection — API keys injected at the network boundary, never inside the sandbox

Inner Layer: AMI Permission System

• 25 bash security validators — command injection, shell quoting, redirections, obfuscation detection
• Recursive descent AST parser — full bash command structure analysis before execution
• 4-tier command classification — safe, unsafe, destructive, hardline-blocked
• Environment scrubbing — 30+ patterns strip API keys and credentials from output
• Self-kill protection — prevents the agent from terminating its own process

Even when running with --yolo (full autonomy), AMI’s hardline security rules remain active — fork bombs, rm -rf /, and 19 other destructive patterns are unconditionally blocked regardless of permission mode. The OpenShell sandbox provides the infrastructure-level boundary on top of this.

This means an attacker would need to bypass both AMI’s application-layer security AND the kernel-enforced sandbox to cause damage. Neither layer trusts the other.

CI/CD: Build, Test, Scan, Publish

We don’t just ship an image — we continuously validate it. The openshell-ami container image goes through an automated pipeline on every push:

build (image → artifact)
  ├─ Suite 1: OpenShell Container Tests (39 tests)
  ├─ Suite 2: Config Validation
  ├─ Suite 3: CLI Flags
  ├─ Suite 4: Security & Integrity
  └─ Suite 5: Provider Tests (150 tests)
       │
  publish (security scan → ghcr.io)

All five test suites run in parallel inside the container itself — the same image that gets published is the one that gets tested. No “works on my machine” gaps.

The publish job includes a 3-layer security scan before pushing to the registry:

1. Image env vars — scans docker inspect output for API key patterns (sk-ant-, AIzaSy, gsk_, etc.)
2. Image history — scans all layer build commands for leaked secrets
3. Image filesystem — runs a container to check /sandbox/.config/ and /sandbox/.superinference/ for credential files and key patterns

Only after all three pass does the image get tagged and pushed to ghcr.io/superinference/openshell-ami.

Why This Matters for Agents at Scale

The industry is moving from “one developer, one agent” to fleet-scale autonomous agent deployment. Companies want to run hundreds of agents across repositories, reviewing PRs, fixing bugs, writing tests, performing security audits — all without human intervention.

This creates three hard problems that OpenShell + AMI solve together:

1. Security at Scale

One agent with unrestricted access is a risk. A hundred agents with unrestricted access is an incident waiting to happen. OpenShell’s sandbox-per-agent model means each agent gets the minimum permissions it needs, with deny-all defaults. AMI’s internal security layer means even a compromised sandbox can’t execute destructive operations. This scales linearly — adding more agents doesn’t increase the blast radius of any individual agent.

2. Cost at Scale

Running Claude Code at scale means paying for Anthropic API calls at premium rates, for every agent, on every task. AMI’s FRITO routing means you can run the same workloads across free-tier providers, self-hosted models, or whatever endpoint your infrastructure provides. In our benchmarks, the free-tier pool matched Claude Opus 4’s accuracy at zero API cost. Multiply that by hundreds of agents and the savings are enormous.

3. Operational Simplicity at Scale

One container image. One deployment model. Any LLM backend. No runtime downloads, no cold-start penalties, no vendor lock-in. The openshell-ami image works the same whether you’re running it in GitHub Actions, a Kubernetes cluster, an air-gapped datacenter, or a developer’s laptop. That operational uniformity is what makes fleet-scale deployment actually manageable.

Getting Started

Pull the image and run your first autonomous agent in under 30 seconds:

# With any API key
docker run --rm \
  --tmpfs /dev/shm:rw,nosuid,nodev,exec,size=2g \
  -e AI_API_KEY=your-key-here \
  -e AGENT_PROMPT="Create a Python script that calculates fibonacci numbers" \
  ghcr.io/superinference/openshell-ami

# With OpenShell CLI
openshell sandbox create --from ubi-ami \
  -e AI_API_KEY=your-key-here \
  -e AGENT_PROMPT="Fix the failing tests in src/auth/"

The image is published at ghcr.io/superinference/openshell-ami, and the source is at github.com/superinference/ami. The CI pipeline, test suites, and workflow configuration are at github.com/superinference/ci.

What’s Next

• Multi-architecture builds — ARM64 support for Apple Silicon and Graviton instances
• GPU passthrough — local inference inside the sandbox with NVIDIA GPU support (experimental in OpenShell)
• Signed SBOMs — software bill of materials for supply chain security compliance
• OpenShell Community contribution — submitting openshell-ami as an official community sandbox flavor

The future of autonomous agents isn’t about making them more powerful — it’s about making them safe enough to trust at scale. OpenShell provides the cage. AMI provides the intelligence. Together, they’re the foundation for the agent-driven workforce.

---

The openshell-ami container image is open source under the Apache 2.0 license. Try it at ghcr.io/superinference/openshell-ami.