KubeCon 2026: Agent Sandboxes and the Production Context They Need
KubeCon 2026 gave AI agents secure sandboxes on Kubernetes. Production work also needs live context, memory of every fix, and approval gates.
KubeCon + CloudNativeCon North America 2026 made sandboxing the standard way to run AI agents on Kubernetes: Google donated Agent Substrate and gVisor to the CNCF, and NVIDIA's OpenShell joined them the same week. A sandbox answers where an agent can run safely. An agent that changes production also needs to know what is happening there, so teams putting agents near production should pair a sandbox with live production context, memory of past fixes, and approval gates on every change, so an agent can catch the next outage before the page as well as resolve the current one.
The show ran November 9 to 12 in Salt Lake City and, for the first time, gave AI inference and autonomous agents a programming track of their own. I work on the production side of that shift at NeuBird, the AI SRE that isolates root cause in under 5 minutes at 94% accuracy, prevents the next outage before the page, and remembers every fix. This year's announcements point directly at the layer production work needs next.
What is Agent Substrate, and why does it exist?
Agent Substrate is an open source runtime for running large numbers of AI agents on Kubernetes securely and cheaply. It pauses an idle agent, saves its state, and restores it onto a pre-warmed sandbox in under 500 milliseconds when work arrives. It exists because agents spend most of their time waiting, and keeping a dedicated pod running for every waiting agent is expensive.
Google donated Agent Substrate, gVisor and OpenRL to the CNCF on November 5, and Agent Substrate reached 1.0 at the same time. An interactive agent spends 90% to 95% of its time waiting on model inference, external APIs or human review, according to Google's engineering write-up. The agent holds state the whole time it waits: a language runtime, a cloned repo, uncommitted edits. Platform teams have had to choose between keeping a dedicated pod running around the clock and scaling to zero, which costs a wake-up of 20+ seconds while the agent re-clones and reinstalls everything.
Agent Substrate splits an agent's state from its compute. An "Actor" holds one agent session's files, memory and network rules, and a "Worker" is a pre-warmed sandbox from a shared pool. The Actor is snapshotted to storage and its Worker freed at the end of each turn, then restored onto any free Worker in under 500 milliseconds when the next request arrives. Agent Substrate reuses the same warm pods instead of creating and deleting a pod for every agent, so thousands of agents can suspend and resume every second without flooding the Kubernetes API server and etcd with pod changes.
1 · Request
A request arrives
The router holds it while the agent is suspended.
2 · Restore
Actor restored onto a warm Worker
Files, memory and edits are back in under 500 ms.
3 · Run
The turn runs in a sandbox
gVisor or a microVM isolates the agent from the host.
4 · Suspend
Snapshot saved, Worker freed
The agent uses no compute while it waits.
Repeats every turn. An interactive agent spends 90% to 95% of its time waiting.
The sandbox matters because agents execute model-generated code, shell commands and tool calls that nobody reviewed in advance. A standard Linux container shares the host kernel, which Google's engineers describe as an unacceptable risk on multi-tenant nodes. gVisor puts a user-space kernel between the agent and the host and intercepts system calls, so agent code never talks to the host kernel directly. Agent Substrate can swap in microVMs for workloads that need a hardware boundary.
Agent Substrate makes idle AI agents cheap to keep: it snapshots each agent's files and memory when a turn ends and restores them onto a warm sandbox in under 500 milliseconds.
How does OpenShell fit in?
NVIDIA's OpenShell joined the CNCF the same week, with 380 contributing organizations since its first commit in January. OpenShell layers isolation from a hardened container up to microVMs and enforces policy on what each agent can reach. NVIDIA's Justin Boitano summed up the approach: "We can't simply ask agents to follow the rules; the infrastructure must enforce them." NVIDIA and Google plan to integrate the two projects.
OpenShell is the project aimed most directly at agents that touch production. The CNCF's platform engineering guide recommends it when agents "hold real credentials and reach production systems." Outbound traffic is denied by default, and policy can allow traffic per binary, host, port and HTTP method, so the same agent can read GitHub issues without being able to create one. Agents see only placeholders for API keys, and the real credential is injected only for approved endpoints.
OpenShell decides which calls an agent may make, down to the binary, host and HTTP method, and keeps real credentials out of the agent's hands.
What else defined KubeCon 2026?
- Inference is now a core Kubernetes workload. llm-d shipped 1.0 under CNCF governance with session-aware routing and multi-tenant quality-of-service controls. The CNCF's 2026 survey found that 82% of container users run Kubernetes in production, and 66% of organizations hosting generative AI use it for some or all of their inference.
- Agents are moving inside the perimeter. Several vendors, including a frontier model lab, launched self-hosted versions of their agent platforms so credentials and data stay in the customer's own cloud account or data center. Swissquote described plans to run agents on-premises for 1,500 employees.
- Agent identity is the next problem to solve. Kubernetes workload identity issues one credential per service account, so every pod under that account looks the same. Agents each build up their own context, tool history and reasoning, and the infrastructure cannot yet tell you which agent took an action or on whose behalf, TechTimes reported. Proposals for per-agent identity are under discussion.
All three point the same way for teams planning to run agents: agents will run inside your boundary, on infrastructure you control, and you will need a record of what each one did.
Kubernetes now runs inference for 66% of organizations hosting generative AI, according to the CNCF's 2026 survey.
What does a sandboxed agent need to work on production?
A sandbox limits the blast radius of what an agent does: it answers where code can run without affecting anything else on the node. Deciding what the agent should change is a separate job. Picture an agent running in a gVisor sandbox with a scoped credential and network policy during a 2 AM incident. The sandbox and its policy make sure the agent takes only allowed actions, and choosing the right one, such as which service to restart or which deploy to roll back, depends on knowing the system.
That knowledge is production context: which services depend on which, what changed in the last hour, what the telemetry across every tool shows, and what fixed this failure the last time it happened. A sandbox runtime keeps an agent's own session state and leaves production context to the agent. Agent Substrate, for example, drops database and MCP connections when an agent suspends, which keeps idle agents cheap and means each agent reconnects and rebuilds its view of production when it wakes.
Context also changes when an agent acts. A sandbox runtime wakes an agent when a request arrives, and in operations that request is usually an alert that has already fired. Every deploy and security patch introduces drift, and an agent that knows how each service normally behaves against its dependencies can flag that drift before any threshold trips, while there is still time to roll back calmly.
| Agent sandboxes and runtimes | An AI SRE | |
|---|---|---|
| Question it answers | Where can an agent run safely and cheaply? | What is happening in production, why, and what should change? |
| When it acts | When a request arrives | Before the page, during the incident and between incidents |
| What it protects | The host, the node and other tenants | The production service and its customers |
| What it keeps | One agent's session state: files, memory, edits | Verified root causes, fixes and engineer corrections |
| How it governs | Isolation, egress policy and credential scoping | Evidence-backed recommendations and approval gates on production changes |
A sandbox controls which actions an agent can take. Production context decides which of those actions is the right one.
How do NeuBird and sandboxed agents work together?
NeuBird is the AI SRE, and it works with the sandboxed agents your teams already run instead of replacing them. NeuBird's own AI SRE works production incidents end to end: it connects across 50+ integrations, finds the root cause, and stages the fix behind configurable human approval gates. Your own sandboxed agents plug into the same platform, so a command NeuBird suggests can run first in an isolated environment on Agent Substrate or OpenShell, where it is tested before anything touches production.
- NeuBird investigates. The AI SRE queries 15+ sources in parallel, including Kubernetes, Datadog, Splunk, AWS and GitHub, isolates the causal chain in under 5 minutes at 94% accuracy, and suggests a fix with the evidence cited.
- Your sandboxed agent tests the fix. The suggested command runs in an isolated environment on the runtime your team already uses, so the team sees what the change does before production does.
- An engineer approves. The tested fix goes through configurable human approval gates along the Suggest, Recommend, Act dial, set per action, and every action is audited and policy-gated. That record shows who approved what while per-agent identity matures.
- NeuBird remembers. The verified root cause and fix go into a live context graph inside your perimeter, holding conclusions rather than copies of your logs, metrics or traces, with no bulk telemetry stored. No team solves the same incident twice.
Sandbox and runtime
Where can the agent run safely?
Production context from NeuBird
What should the agent change?
The same AI SRE covers the whole reliability lifecycle from where on-call teams already work: Slack, Teams, Jira, ServiceNow and PagerDuty.
- Resolve, when systems break. NeuBird isolates the causal chain and the offending change in under 5 minutes at 94% accuracy and stages a verified fix or rollback, so the engineer gets a completed investigation instead of a raw alert.
- Prevent, before the page. NeuBird continuously compares service behavior against its dependencies and catches silent drift and capacity bottlenecks 30 to 60 minutes before alerts fire. Every deploy and security patch introduces drift, so NeuBird flags the risk, surfaces coverage gaps and recommends missing SLOs before customers feel it. A Global Automotive OEM detected blue-screen risk 30+ minutes prior to kernel failure during live migration.
- Operate, between incidents. NeuBird tunes noisy alerts, detects runbook drift and tracks recurring cross-service patterns.
- Inside your perimeter. NeuBird deploys in your VPC, on-prem or air-gapped in under an hour, is SOC 2 Type II and HIPAA Ready, and cuts token spend by roughly 90%.
NeuBird is a platform, and that is what makes the better-together model work. It provides governed access to telemetry and models, compounding memory, and guardrails, and it serves the same context to people and to the agents they build. Agents running on Agent Substrate or OpenShell connect to NeuBird over MCP and inherit live production context, memory and approval gates instead of rebuilding them. We cover that model in NeuBird vs. in-house agents and in why AI SRE agents need a platform.
NeuBird and sandboxed agents work better together: NeuBird's AI SRE finds the root cause and suggests the fix, your sandboxed agent tests it in isolation, and an engineer approves it through a configurable gate.
What should platform teams do after KubeCon?
Run agents in sandboxes. Agent Substrate has a 1.0 release, OpenShell has CNCF backing and a reference architecture, and together they make a sound default for running untrusted agent code on Kubernetes. Then connect those agents to NeuBird, so the AI SRE supplies production context, memory of every fix and approval gates, your sandboxed agents test its suggested fixes in isolation, and the next outage gets caught before the page instead of after it. NeuBird is the AI SRE that answers the page, then keeps production running, and it brings that context to every agent your teams run.
Sources: Google Cloud: Open infrastructure for autonomous agents comes to CNCF · Google Open Source Blog: Sandboxing untrusted AI agents at scale · Beri: Agent Substrate 1.0 on GKE · TechTarget: Nvidia, Google agent sandboxes meet within CNCF · CNCF: OpenShell on Kubernetes, a guide for platform engineers · SiliconANGLE: Red Hat's AI agent infrastructure strategy · TechTimes: Why Kubernetes cannot tell which AI agent took action · TechTimes: KubeCon Salt Lake City closes with a clear signal
