Deploying OpenClaw in a Kubernetes Sandbox

AI agents are fundamentally different from traditional containerized workloads. They execute model-generated code, install packages dynamically, interact with external services, and operate with a degree of autonomy that makes conventional container security insufficient. When an AI agent runs a package install suggested by a language model, or executes a shell command to process data, you are trusting that the arbitrary code will not escape its container boundary.

This post explores how to deploy OpenClaw  — an open-source agentic AI platform — on Amazon EKS running on AWS Graviton instances, with tiered runtime isolation using gVisor and Kata Containers. We leverage Agent Sandbox project from Kubernetes SIG Apps for declarative lifecycle management, and Karpenter for intelligent node autoscaling with AWS Graviton nodes.

Traditional container isolation relies on the Linux kernel's namespace and cgroup mechanisms. The container shares the host kernel — and a kernel vulnerability means a container escape affects every workload on that node.

For AI agents, this risk surface is amplified in several ways. Model-generated code is inherently unpredictable — you cannot audit it before execution. Agents may install compromised dependencies from the supply chain. Prompt injection attacks can trick agents into running malicious commands. And in multi-tenant environments, multiple agents from different users share the same underlying infrastructure.

A defense-in-depth approach layers multiple boundaries: network policies restrict egress to only approved destinations, runtime isolation (gVisor or Kata) interposes a kernel boundary that prevents syscalls from reaching the host, container security contexts drop all capabilities to prevent privilege escalation, and the host kernel itself becomes unreachable by the workload.

There are three isolation tiers that operators can assign based on their threat model:

Standard (runc) uses traditional Linux namespaces and cgroups. This is appropriate for trusted internal agents where the code being executed is well-understood and the blast radius of a compromise is limited.

Hardened (gVisor) interposes a user-space kernel called Sentry that re-implements Linux syscalls without passing them to the host kernel. For AI agents executing arbitrary code, this means that a kernel exploit in agent-generated code targets Sentry rather than the real kernel, and capabilities are meaningless inside the gVisor sandbox.

Maximum (Kata Containers) runs each pod inside a lightweight virtual machine using a Virtual Machine Monitor. Unlike gVisor's user-space kernel emulation, Kata provides a full hardware-enforced kernel boundary — each agent gets its own Linux kernel running in a micro-VM. This requires bare metal instances or instances that support nested virtualization, but provides the strongest possible isolation for hostile workloads or compliance-sensitive environments.

gVisor requires installing the runsc containerd shim on nodes at boot time. Kata Containers requires bare metal instances with the kata runtime installed. Standard EKS with Karpenter allows AL2023 user-data scripts to install gVisor or Kata at boot. Tainted nodes ensure only sandbox workloads land on isolation-capable nodes. gVisor runs on any instance type while Kata requires .metal instances for hardware virtualization.

The Agent Sandbox  project from Kubernetes SIG Apps provides a Kubernetes-native abstraction purpose-built for AI agent workloads. It introduces four custom resources:

Sandbox is a declarative, single-container environment with stable identity and persistent storage. Think of it as a "workspace" for an agent — it has a lifecycle that outlives individual requests.

SandboxTemplate defines reusable runtime configurations (runc, gVisor, or Kata) that decouple workload configuration from isolation policy. Platform teams define templates; application teams consume them without needing to understand the underlying runtime mechanics.

SandboxWarmPool pre-provisions sandbox pods so that when an agent needs to spin up, it claims an already-running instance rather than waiting for pod scheduling, image pulling, and container startup.

SandboxClaim is how an application requests a sandbox from a warm pool — it is the interface between the agent orchestrator and the pre-warmed infrastructure.

This is a better abstraction than raw Pods or Deployments for agent workloads because it handles lifecycle patterns unique to agents: creation on demand, warm pooling, session affinity, and graceful teardown.

The full guide with all manifests and step-by-step instructions is available on GitHub at aws-samples/graviton-developer-workshop/openclaw-eks-lab-guide . The architecture consists of three Karpenter NodePools, each tailored for a specific runtime:

A general node pool runs standard Graviton instances on spot for system workloads and runc-based agents. These are cost-effective and require no special configuration.

A gVisor node pool runs standard Graviton instances with AL2023 user-data that downloads and installs the runsc binary and containerd shim at boot. Nodes are tainted with runtime=gvisor so that only workloads using the gVisor RuntimeClass are scheduled there.

A Kata node pool runs bare metal instances with user-data that installs the Kata static release bundle and registers the Cloud Hypervisor runtime with containerd. These nodes are tainted with runtime=kata and only run on-demand (spot is unsuitable for .metal given limited availability).

On top of these node pools sit the Agent Sandbox resources: three SandboxTemplates (one per tier) and three SandboxWarmPools that keep pre-provisioned sandboxes ready. The warm pools are especially critical for Kata — they pre-boot micro-VMs so that claiming a sandbox is instant despite the one-to-three second VM boot time.

OpenClaw is configured to use Amazon Bedrock as its model provider, specifically Claude Sonnet via a global inference profile. Pod Identity provides keyless access to Amazon Bedrock. Rather than storing API keys in environment variables, the agent pod's service account is associated with an IAM role that grants bedrock:InvokeModel permission scoped to specific model ARNs. Credentials are injected automatically and rotated transparently. The platform's configuration is declarative — you define which model to use, which channels to enable, and how agents should behave in a single JSON configuration file that gets mounted into the container as a ConfigMap.

Each sandbox gets its own encrypted persistent volume as persistent workspace storage so that agent state, downloaded files, and generated artifacts survive pod restarts.

gVisor sits between the containerized application and the host kernel. Every system call the agent makes — file I/O, network operations, process management — is intercepted by Sentry, which re-implements that syscall in user space. The host kernel only sees a handful of carefully audited syscalls from the Sentry process itself.

For AI agents, this matters in many ways:

If agent-generated code runs a kernel exploit (like a dirty pipe attack), the syscalls never reach the real kernel. The exploit targets Sentry's user-space implementation, which has a minimal attack surface.

If a compromised dependency attempts privilege escalation through capability manipulation, those capabilities are meaningless inside the gVisor sandbox — they map to Sentry's constrained environment, not real kernel capabilities.

Where gVisor emulates a kernel in user space, Kata Containers provides a full Linux kernel running inside a micro-VM powered by Cloud Hypervisor. The agent process runs inside this VM, and its kernel is completely separate from the host kernel.

This means that even a zero-day kernel exploit inside the agent's VM cannot reach the host. The blast radius is contained to that single micro-VM. The agent sees a full Linux boot sequence in its dmesg output and has access to the complete syscall interface — there is no compatibility concern as there can be with gVisor's subset implementation.

The trade-off is cost and infrastructure requirements. Kata requires bare metal instances or instances with nested virtualization because it needs hardware virtualization support (KVM). This is where warm pools become essential — you pre-boot the micro-VMs on a shared .metal node, and when an agent claims a sandbox, it gets an already-running VM instantly.

Runtime isolation protects against container escape, but a compromised agent can still exfiltrate data over the network. Network policies provide the final layer: a default-deny rule blocks all egress, and an explicit allowlist permits only DNS resolution (UDP/TCP port 53 to kube-system) and HTTPS (TCP port 443 to any destination).

This means agents can reach Amazon Bedrock, download packages from registries, and access approved APIs — but cannot probe internal services, connect to databases, or exfiltrate data over non-standard ports. In production, you would further scope the HTTPS allowlist to specific CIDR ranges or use AWS PrivateLink endpoints.

Size your warm pools based on traffic patterns. Monitor claim latency and pool utilization. If agents frequently wait for sandbox availability, increase pool replicas. If warm sandboxes sit idle for long periods, reduce them.

Scope Bedrock permissions tightly. Limit Pod Identity roles to specific model ARNs rather than blanket bedrock:* permissions. This contains the blast radius if an agent's credentials are somehow exposed.

Set termination grace periods. gVisor's Sentry intercepts SIGTERM, and some applications (like Node.js) may not handle it cleanly inside the sandbox. A ten-second grace period ensures stuck pods are force-killed promptly rather than hanging in Terminating state.

Monitor with Container Insights. Track sandbox creation latency, warm pool utilization rate, and Karpenter node provisioning time. These three metrics tell you whether your isolation infrastructure is keeping pace with demand.

Encrypt everything at rest. Use a StorageClass with encryption enabled for agent workspace volumes. Agent state may contain sensitive data — model responses, user inputs, generated code — that warrants encryption.

AI agents executing model-generated code require isolation guarantees beyond what traditional container runtimes provide. By combining Agent Sandbox for Kubernetes-native lifecycle management, gVisor for user-space kernel isolation, Kata Containers for hardware VM boundaries, Karpenter for right-sized node provisioning, AWS Graviton for price-performance benefits, Pod Identity for keyless cloud access, and network policies for egress control, you get a production-ready, multi-tier security architecture that adapts to your threat model while keeping agent interactions instant via warm pools.

The complete lab guide with all Kubernetes manifests, Karpenter node pool configurations, and step-by-step deployment instructions is available at aws-samples/graviton-developer-workshop/openclaw-eks-lab-guide .