Agent Substrate: the core system

★ 6,333⑂ 712👁 30⑃ 2,453● 1,263▤ 11◈ 1
GoApache-2.0Created 2026-05-13ate.dev/
6,333
stars
+78+308+1,991
712
forks
30
watchers
2,453
prs
1,263
issues
11
releases
1
discussions

README

Agent Substrate

Zero-trust sandboxing for millions of agents on Kubernetes.









Quickstart · Security · Architecture · Contributing


  




 What is Agent Substrate?

Agent Substrate is a security-hardened, zero-trust runtime for sandboxed agents, engineered to safely run millions of agents and tools with 10x higher density than standard containers. Purpose-built for the era of autonomous agents, Substrate delivers fast resume operations in less than 500ms, with more than 500 activations per second. Agents get isolated compute, identity, networking, and storage. Sensitive credentials are kept out of reach from untrusted code. It supports multiple sandbox technologies, including microVMs and gVisor, while enabling a consistent lifecycle and management of all sandboxes.

At its core, Agent Substrate maps a larger set of “actors” (stateful workloads such as agents) onto a smaller pool of ready “workers”. Because agents spend most of their lives waiting on models, tools, or humans, Substrate snapshots idle actors out of memory and restores them when a request arrives.

Substrate is a low-opinion runtime, not an agent SDK. The workloads it runs do not have to be AI agents, though autonomous, untrusted, mostly-idle agents are the target for its isolation and scheduling model. It runs on standard Kubernetes: Pods, autoscaling, NetworkPolicies. It adds agent-specific scheduling, snapshotting, identity, and network mediation. This allows agentic, inference, training, and reinforcement learning workloads to share one infrastructure plane.

 Security Model

Substrate treats every actor as untrusted and mutually hostile, so tenants can share physical nodes without sharing a security boundary. Every control operates within the cold-start and resume budget. See the Security Guide for the full list of security principles and threat model.

 Always sandboxed, VM-grade boundaries: Every actor runs inside a dedicated gVisor (runsc) or Cloud Hypervisor microVM sandbox with segregated compute, network, and storage. Plain Linux containers are not supported.
 Per-agent cryptographic identity: Every active actor receives a short-lived SPIFFE X.509 certificate by default, and the egress gateway can mint per-actor JWTs on demand when an egress policy calls for one. Both carry the actor identity and atespace (the Substrate namespace grouping), and are designed to federate with external identity systems.
 Zero credentials in the sandbox: Actors never hold actor identity JWTs/certs, API keys, or cloud tokens. The built-in egress gateway (atenet-egress) injects credentials 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 (atenet-router), no lateral actor-to-actor or control-plane access, and outbound traffic restricted by the egress gateway.
 Pluggable policy at the edge: The egr

Top issues

Discussions

Latest release

v1.0.0 - "Fully armed and operational" v1.0.0 2026-11-05
Now witness the power of this fully armed and operational ... system for managing agents and agent-like workloads securely at scale.

Thank you to our MANY contributors who helped get us here! We couldn't have done it without you. :heart:

 What's Changed
 ⚠️ Breaking Changes
 Envoy moves to v1.39.5, micro-VM assets to kata 4.3.1, kind and CSI images pinned by digest by @dims in https://github.com/agent-substrate/substrate/pull/3181
 WorkerPools with similar long names no longer share a NetworkPolicy by @yufan-su in https://github.com/agent-substrate/substrate/pull/3130
 MicroVM guests

Snapshot: 2026-11-10T09:35:25Z · Data license Apache-2.0 · JSON