Agent Substrate: Zero-Trust Agent Sandboxes on Kubernetes

What Agent Substrate is

Agent Substrate is an Apache-2.0 runtime for running large numbers of sandboxed, stateful agents on Kubernetes. Its README describes it as a security-hardened, zero-trust runtime in which every agent gets isolated compute, identity, networking and storage, and in which sensitive credentials never enter the sandbox. It supports more than one sandbox technology, gVisor and microVMs among them, behind a single lifecycle and management model.

The problem it targets is specific. Agents spend most of their lives waiting: on a model response, a tool call or a human. Running each one in its own always-on sandboxed Pod wastes memory and CPU while it waits, and running many of them side by side on shared nodes raises hard isolation questions because the code inside is often untrusted. Agent Substrate's answer is to snapshot idle agents out of memory and restore them on demand, while keeping each one inside a VM-grade boundary. The audience is platform and infrastructure teams who host agents, coding sandboxes, MCP servers or other bursty, untrusted workloads for many users.

The project is explicit that it is "a low-opinion runtime, not an agent SDK". The workloads it runs do not have to be AI agents; autonomous, untrusted, mostly idle agents are simply the case its isolation and scheduling model is built for.

How it works

The core idea is a mapping of many "actors" onto fewer "workers". An actor is an instance of a stateful, agent-like workload. A worker is a pre-started sandboxed Pod waiting for work. When an actor goes idle, Substrate suspends it and frees the resources it held; when a request arrives for it, the actor is resumed onto any available worker in the pool. Because workers are already running, resuming an actor avoids a trip through the Kubernetes scheduler. The README describes snapshots that capture both working memory and filesystem state, so in-flight sessions and tool state survive hibernation.

Substrate runs on standard Kubernetes primitives (Pods, autoscaling, NetworkPolicies) and adds agent-specific scheduling, snapshotting, identity and network mediation. The repository is split into several commands:

• ateapi: the control-plane API server, exposing gRPC endpoints for actor and worker lifecycles.
• atelet: a node-level DaemonSet that supervises worker Pods, coordinates snapshotting and manages state transfers.
• atecontroller: a Kubernetes controller that reconciles WorkerPool custom resources.
• atenet: the networking controller providing Envoy routing and proxy sidecars, including the ingress router and egress gateway.
• ateworker-gvisor and ateworker-microvm: in-Pod helpers that run gVisor checkpoint/restore or Cloud Hypervisor VMs.
• ate-idp-server: serves the OpenID discovery document and key set used to verify actor JWTs.
• kubectl-ate: a CLI plugin for managing Substrate resources.

The architecture document frames the trade-off honestly: suspend and resume at scale turns an idle-resource problem into a data-management problem, because the state of very large numbers of actors has to be stored and located quickly. It lists data locality, observability of multiplexed actors and a production-grade control plane as hard problems the project has to solve.

Key features

• Always sandboxed: every actor runs in a dedicated gVisor (runsc) sandbox or Cloud Hypervisor microVM. Plain Linux containers are not supported.
• Per-agent identity: each active actor receives a short-lived SPIFFE X.509 certificate by default, and the egress gateway can mint per-actor JWTs when an egress policy calls for one.
• No credentials inside the sandbox: the egress gateway, atenet-egress, injects API keys and tokens into approved outbound requests outside the sandbox, so a prompt-injected or compromised agent has nothing to exfiltrate.
• Default-deny networking: actors start with a private network stack, no inbound path except through the ingress router, no lateral actor-to-actor or control-plane access, and outbound traffic restricted by the egress gateway.
• Pluggable policy: the egress gateway acts as a replaceable policy enforcement point, so authorization, DLP, prompt-injection scanning or cloud IAM engines can be attached without putting policy code in the sandbox.
• Oversubscription: the README describes 10x to 30x oversubscription of stateful actors onto a small pool of warm worker Pods, and its demo shows about 250 actors multiplexed across 8 Pods.
• Request parking: in an oversubscribed pool, the router can hold inbound requests until a worker frees up instead of returning 503.
• Framework agnostic: actors are standard OCI images, so agents built with ADK, LangChain, Claude Code, Codex or Antigravity, and MCP servers, run without SDK changes.

Performance figures are the project's own claims: the README states resume operations under 400 ms, more than 1,500 activations per second and roughly 10x higher density than standard containers.

Getting started

The development quickstart runs everything on a local kind cluster. It needs Go, kubectl and Docker; other dependencies, including kind, are managed through Go. From a clone of the repository:

# create cluster and local registry (IPv4; IP_FAMILY=dual|ipv6 overrides)
hack/create-kind-cluster.sh

# install ate, PostgreSQL, rustfs
hack/install-ate-kind.sh --deploy-ate-system --credential-provider='{"name":"k8s.io"}'

# install counter demo
hack/install-ate-kind.sh --deploy-demo-counter

# install kubectl-ate
go install ./cmd/kubectl-ate

Then create a counter actor from the demo template and expose the router locally:

kubectl ate create actor my-counter-1 -a ate-demo-counter --template counter

# port-forward the network router to bind to local port `8000`
kubectl port-forward -n ate-system svc/atenet-router 8000:80

In a separate terminal, send a request that wakes the actor and increments its counter:

curl -X POST \
   -H "ate-target-actor: ate-demo-counter/my-counter-1" \
   -i http://localhost:8000/

The bundled credential provider starts with an empty, default-deny namespace policy, so no secret can be injected into an actor's requests until its atespace (Substrate's namespace grouping) is granted the namespaces it may read. A GKE path is also documented: copy the environment template, provision the cluster, bucket and IAM bindings, then deploy the system.

cp hack/ate-dev-env.sh.example .ate-dev-env.sh

go run ./tools/setup-gcp bootstrap

./hack/install-ate.sh --deploy-ate-system --credential-provider='{"name":"k8s.io"}'

The README notes that a Linux host running more than about a thousand sandboxes needs larger kernel neighbour-table limits, and that some required Kubernetes beta APIs can only be enabled at cluster creation if you bring your own cluster.

Use cases

• Hosted coding agents: the Claude Code Multiplex demo oversubscribes hardware by multiplexing several Claude Code agents onto a limited pool of workers while keeping filesystem state between sessions.
• Sandboxed shells for agents: the Sandbox demo runs an Alpine Linux environment that allows arbitrary shell execution with state preserved across sessions.
• MCP server hosting: MCP servers can be deployed as actors with per-actor identity and egress controls.
• Agent platforms: Google's Agent Executor uses Substrate as the base for a distributed agent harness, and kagent, a CNCF Sandbox project, uses it to run sandboxed, stateful agent workloads.
• Mixed fleets: the multi-template demo shows two actor templates running different binaries sharing one worker pool, and another demo scales a pool with an HPA fed by prometheus-adapter.

How it compares

The natural baseline is one sandboxed Pod per agent on plain Kubernetes, using gVisor or a microVM runtime class. That gives isolation but keeps every idle agent's memory resident and puts each start through the scheduler. Substrate keeps the same sandbox technologies and adds the actor and worker split, snapshot-based suspend and resume, an agent-aware router and an egress gateway for credential injection. It is also not an agent framework in the sense of ADK or LangChain; those run inside it. Teams that only need a handful of long-lived sandboxes may find a plain gVisor or Kata setup simpler, while Substrate is aimed at large numbers of mostly idle, mutually untrusted tenants.

Things to know before adopting

• Very early: the project is pre-1.0 and makes no backward-compatibility guarantees; APIs and behaviour may still change significantly. The architecture document opens by saying much of the described architecture is aspirational and not yet implemented.
• Contribution focus: the maintainers say the project is very young and they may not merge contributions that do not align with building the core system and demos.
• Kubernetes support window: the aim is the latest stable Kubernetes release and the previous minor release.
• Roadmap items: the roadmap lists worker autoscaling, user authorization on the control plane, incremental snapshots, S3 support, audit logging and Prometheus metrics among upcoming work, so check what is implemented for the features you depend on.
• Operational dependencies: the quickstart installs PostgreSQL and rustfs alongside the system, and the GKE path uses Cloud Storage for snapshots.
• Licence: Apache-2.0, which permits commercial use and modification with attribution and a patent grant.

Project activity

As of October 2026 the repository has about 5,400 stars. It was created in May 2026, is written in Go and is licensed under Apache-2.0, with pushes as recent as mid-October 2026. The community runs a weekly meeting, an ate-dev Google Group and channels in the CNCF Slack. The source, docs and demos are at github.com/agent-substrate/substrate.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/agent-substrate?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)