nono lands in the Kubernetes agent-sandbox

There is now an official nono example in agent-sandbox, the Kubernetes SIG Apps project that gives AI agent runtimes a first-class primitive: a Sandbox custom resource that manages an isolated, stateful, singleton pod, with templates, claims, and warm pools built on top.

The example answers a question we get a lot: if my agent already runs in a container or a microVM, why would I add nono?

Because they protect different boundaries. A container runtime or microVM isolates the pod from the node, the cluster, and neighboring workloads. It says nothing about what the agent may do within its own walls. nono limits what the agent and each delegated tool can access inside that pod: files, credentials, network destinations, API paths, and command arguments.

If the agent is exploited, the runtime contains the untrusted code within the pod while nono limits the authority available to the compromised process. The layers complement each other rather than competing, and many nono users already run it this way. The example just makes the pattern official, reproducible, and testable in Kubernetes.

The scenario is a small incident-response workflow. An agent runs inside a Sandbox, alongside a disposable Grafana Loki service seeded with a synthetic payments incident. The agent delegates to LogCLI to retrieve the incident logs.

Every boundary in that flow is enforced:

• Agent filesystem: the workspace and bundled workload, nothing else. Mounted secrets and protected audit state are unreachable.
• Agent network: the approved LLM endpoint only. Other hosts, methods, and paths are denied at layer 7.
• Agent credential: a session-scoped phantom. The supervisor injects the real provider key only on approved requests, so the raw key never enters the agent process.
• LogCLI: runs in its own tool-scoped micro-sandbox with a narrower policy than the agent. It can execute one fixed incident query; changed flags, altered queries, and management commands are denied before execution. Its network policy allows only the Loki query-range endpoint, and it receives a tool-scoped Loki address and phantom token the agent never sees.

The test proves command policy and network policy independently. A successful run ends with:

[tool-ok] exact LogCLI incident query returned the seeded Loki log
[tool-ok] L7 policy blocked LogCLI from the labels endpoint
[tool-ok] invocation policy blocked altered LogCLI arguments
[tool-ok] invocation policy blocked LogCLI deletion management
[audit-ok] event chain, Merkle root, and audit ledger verified
[audit-ok] DSSE signature matched the pinned public key

Those last two lines are the part I like most. The demo does not just enforce policy; it records every network decision, command-policy decision, executable identity, and session lifecycle event, commits the stream with Merkle roots, and signs the completed session with a short-lived P-256 key held only by the trusted supervisor. The run exports a portable audit bundle you can verify offline with nono audit verify and the pinned public key. Denials are not log lines you take on faith; they are entries in a tamper-evident ledger.

nono's enforcement builds on Landlock, so the guest kernel matters more than any runtime:

• runc / containerd: supported on nodes with Landlock enabled (Linux 5.13+).
• Kata Containers: supported out of the box. Kata adds a hypervisor boundary for the pod while nono keeps constraining the agent and tools inside the guest — the same stack Red Hat wrote up in Multi-Layer Sandboxing of AI Workloads in Kubernetes, and the architecture behind Kubefence.
• Firecracker: supported when the guest kernel enables Landlock.
• gVisor: not yet — its Sentry lacks the required Landlock syscalls, and we are working with the gVisor team to change that (google/gvisor#13439).

Where Landlock is missing, nono fails closed rather than running without filesystem enforcement.

With Docker, kind, and kubectl installed, the whole thing is one script from the example directory:

KIND_CLUSTER_NAME=agent-sandbox ./run-test-kind.sh

It builds the agent image, generates short-lived TLS and audit identities, seeds the incident, creates the Sandbox, runs the policy checks, and verifies the signed audit session. No real API keys required — the checked-in secrets are non-functional placeholders that exercise the same phantom-credential flow you would use in production.

• OS Sandbox — the kernel-level confinement nono applies inside the pod
• Credential Injection — the phantom-token pattern the agent and LogCLI both ride on
• Audit Trail — how sessions become hash-chained, Merkle-committed, signed records
• Why Containers Aren't Enough for AI Agents in Kubernetes — the Kata + seccomp + nono reference architecture