Sandboxing your agent isn't the hard part, keeping it cheap is

Every autonomous agent you drop on a cluster is a Linux process you agreed to babysit. Cute framing, until the bill lands. On the CNCF blog this week, Solo.io's Lin Sun, a CNCF Ambassador, put a version of that observation into a post called "Why sandboxing your agent is not enough" and pointed at two Kubernetes SIG Apps projects that carve the agent-hosting problem in half.

The provocation in the title is real. The gap it names is not the one you might expect.

What agent-sandbox already gives you

agent-sandbox is a Sandbox Custom Resource Definition and controller for Kubernetes, developed under SIG Apps. It hands each agent a strong identity, persistent storage that survives a restart, and lifecycle management. If you have ever watched a coding agent get pointed at a shell and then be tempted to (as Lin Sun puts it in the post) delete family photos or modify the wrong file, you understand the appeal of a namespace-flavoured cage with rules.

Nothing new underneath. Container primitives are exactly the tool for that job, and Kubernetes ships them by the load. agent-sandbox packages those primitives into a CRD whose knobs fit an agent's shape.

Where the real gap lives

Read the post carefully and the "not enough" in the title turns into a cost complaint, not a security one.

Two failure modes at scale. Keep every agent warm and idle in its own pod, and you rent CPU that watches paint dry. Spin a pod up on every invocation instead, and you pay a cold-start tax on every request. Neither mode holds when you go from one demo agent to a fleet.

The stance in the post: sandboxing addresses safety. It says nothing about the operational shape of an agent, which spends most of its life waiting between short bursts of tool calls.

What agent-substrate proposes

agent-substrate, the sibling project, decouples the worker pod from the agent "actor". You get a shared worker pool plus actor templates that describe agents as things that wake up, do a short piece of work, suspend, and resume later. Lin Sun demonstrates it wired to kagent for on-demand execution: dynamic wake on invocation, higher scale from shared infrastructure, lower latency than a full cold start.

If you have ever run a queue of ephemeral workers behind a build system, the pattern is familiar. Warm pool of runners, cheap scheduling on top, per-job isolation still enforced underneath. The novelty is the actor model applied to agents. The agent's identity and state now outlive the pod that happens to be executing it.

Why this matters if you own the pipeline

Two reasons.

First, if you are shipping AI agents into your CI/CD (for review, for triage, for anything that calls a tool), the cost curve of "one pod, always on, per agent" catches you quickly. Any team already running a shared runner fleet on Kubernetes has done this arithmetic once. You get to do it again for agents.

Second, splitting identity from compute changes your audit story. The agent has a persistent name and an audit trail. The pod is a rented seat. That reads as a cleaner boundary than "whatever container was executing when the incident hit," and it lines up better with how humans already show up in your logs.

Fair concession. agent-sandbox is a young Kubernetes SIG project. agent-substrate is younger. Neither is the only shape of this idea. Firecracker microVMs, per-tenant runners, and rootless containers all attack overlapping slices of the problem. Nobody has shipped the finished answer.

Verdict

Sandboxing keeps your agent from setting the house on fire. It does not keep you from paying rent on an empty house. If you plan to run more than a handful of agents on a cluster you actually pay for, the interesting engineering is one layer above the sandbox, and CNCF is publishing it in a project you can read. Worth the tab.