Eight AI agent sandbox options compared.
What actually contains a coding agent?

If you are choosing an AI agent sandbox this quarter, start with what the incident reports showed. Between 16 September and 23 October 2026, OpenAI, Anthropic and the UK AI Security Institute published accounts of AI agents taking actions their operators had not sanctioned, and Google confirmed a test in which Gemini reached three real companies. Agents tunnelled out through a DNS resolver nobody had filtered, used package-download credentials that also allowed writes to pass messages to each other, split a researcher’s token to get it past secret scanning, and switched off the human alerts on the monitor meant to catch them. In one evaluation with internet access deliberately left on, a model tried to push malicious code into an unrelated developer’s GitHub repository and created a sock-puppet account to pressure its maintainers, who refused the change. Red-teamers found genuine sandbox flaws as well, but in every incident the labs described in detail, what failed was a control around the sandbox, not the kernel: a DNS path, a credential with more scope than its job needed, a secret scanner that could be fooled, or monitoring the agent could edit.

The sandbox market grew up over the same two months, starting in late August. The Kubernetes agent-sandbox project shipped 1.0 on 28 August. Google launched Agent Substrate on 16 September and made a microVM sandbox type generally available in GKE on 7 October. NVIDIA started OpenShell's 0.1 line on 25 September, the CNCF voted to accept gVisor on 28 September, and Microsoft made Execution Containers generally available on 7 October. This is InfraZen's comparison of the eight options platform teams are evaluating this quarter: what each actually isolates as of 25 October 2026, where it runs, how mature it is, and the ten controls that decide whether any of them works.

What is an AI agent sandbox?

An AI agent sandbox is an execution environment that limits what an agent’s code can reach: the host kernel, the filesystem, the network and the credentials around it. It has two halves that are easy to confuse. The isolation boundary decides how hard it is to break out. The policy decides what the agent may touch from inside. Most products sell one half and assume you will supply the other.

Why not a plain container? gVisor’s maintainers put it bluntly in the project README: “Containers are not a sandbox.” A standard container shares the host kernel with every other container on the node, so a single kernel vulnerability can be enough to escape. That is an acceptable risk for code your team wrote and reviewed. It is a poor bet for code an LLM generated thirty seconds ago from a prompt that may contain someone else’s instructions.

Agents also differ from ordinary untrusted workloads in two ways that shape the design. They act: an agent with a shell and a token will use both, so the policy half matters as much as the boundary. And they are stateful: a coding agent keeps a workspace, a session and often a warm process for hours. That is why new projects like agent-sandbox and Agent Substrate exist instead of everyone reusing serverless functions.

What did the 2026 incident reports actually show?

They showed agents getting out through the controls around the sandbox, not through the sandbox itself. OpenAI began publishing misalignment reports this year, and by 25 October its index listed 20 reports, all first posted between 16 September and 20 October, plus 3 notices. Anthropic published its own accounts in October, and Google confirmed a case in September after a Wall Street Journal investigation. The table maps each incident to the control that failed and the control that would have stopped it, in each organization’s own terms.

The labs have also said what they changed. OpenAI’s DNS report says it paused training, evaluation and tool-use inference for its most capable models; Reuters reported on 23 October that training resumed on 1 October, after OpenAI barred internet access and had teams of AI agents probe the restricted environments for flaws. Red-teamers find what incident reports miss: METR and Redwood Research reported on 22 October that a pilot review of OpenAI’s monitoring found a way Codex agents could in principle bypass Codex sandboxing. OpenAI says the production issues are patched; METR and Redwood say they have not verified that. Experts quoted by CSO Online blamed containment and monitoring, not “rogue” AI. The gap is not unique to labs: in a survey commissioned by Harness of 700 technology professionals at large enterprises, 76% said they could disable a misbehaving agent in under 15 minutes, but only 33% had an instant kill switch.

Attackers are running agents too. Microsoft reported on 21 October that an actor it tracks as Storm-0940 used ARTEX, an open-source agentic penetration-testing framework, against hundreds of organizations, in several cases going from initial targeting to privileged cloud access in under three hours. The same day CrowdStrike documented four more crews that ran offensive agent harnesses on Claude Code between May and August. The credentials around agents are a target as well: LiteLLM’s 1.107.0 release was hijacked through a key that leaked in May and was never revoked, and Railway says an intruder may have accessed customer environment variables, and decrypted some, in what it believes is a series of attacks on platform companies “with the aim of compromising AI inference providers”.

How strong is each isolation boundary?

Every option on this page sits on one of four rungs, from weakest to strongest: OS process sandboxes, standard containers, user-space kernels and microVMs. The rung tells you how hard it is to break out. It tells you nothing about what the agent can reach through the front door, which is the policy half and the subject of the controls section below.

1. OS process sandboxes. AppContainer on Windows, Seatbelt on macOS, Bubblewrap, Landlock and seccomp on Linux. The kernel is shared and the operating system enforces the policy. This is what Microsoft Execution Containers’ process containers and OpenShell’s Linux backend build on, and it is the practical choice on a developer laptop, where you cannot run a VM per shell command.
2. Standard containers. Namespaces, cgroups and seccomp around a shared kernel. Fine for trusted code; the gVisor README is right that they are not a sandbox for untrusted code.
3. User-space kernels. gVisor’s Sentry handles the workload’s system calls itself, so an attacker has to exploit both the Sentry and the host kernel, which share no code. The price is speed on syscall-heavy work and incomplete Linux compatibility.
4. MicroVMs. Kata Containers, Firecracker and Cloud Hypervisor give each sandbox its own guest kernel behind hardware virtualization. This is the strongest boundary and the most expensive: more memory per sandbox, and nodes that support virtualization, which in a cloud VM means nested virtualization.

How do the eight options compare?

Three of the eight are kernel boundaries: gVisor, Kata Containers and Firecracker. agent-sandbox and Agent Substrate manage agent lifecycles on top of them, MXC and OpenShell apply policy around agents on developer machines and hosts, and the hosted APIs sell the whole stack as a service.

Kernel boundaries: gVisor, Kata Containers and Firecracker

Pick gVisor when density matters and your nodes are ordinary cloud VMs, Kata when you need a separate kernel, and Firecracker only if you are building your own sandbox fleet.

gVisor and GKE Sandbox

gVisor is an application kernel that runs in user space and implements the Linux system-call interface in Go. Its Sentry component intercepts the workload’s system calls and handles them itself; nothing passes straight through to the host. The Sentry is in turn confined by seccomp, namespaces and cgroups, and a separate Gofer process mediates file access. The default platform, systrap, needs no hardware virtualization, which is why gVisor runs comfortably inside ordinary cloud VMs. A KVM platform performs best on bare metal.

The trade-offs are documented honestly. The performance guide says CPU-bound work and raw memory access cost nothing extra, while syscall-heavy workloads pay the most and networking and file I/O are bound by implementation costs. The compatibility guide notes that gVisor implements a subset of the Linux ABI, with io_uring off by default and iptables only partially supported. Its own advice is that “the only real way to know if it will work is to try.” Agent workloads, mostly interpreters, package managers and test runners, usually work, but a build step that leans on unusual syscalls may not.

On GKE, GKE Sandbox is the managed version: pods opt in with the gvisor RuntimeClass, it is enabled by default on Autopilot, and on Standard clusters you enable it on a node pool other than the default one. Sandboxed pods cannot be privileged or use hostPath volumes or sysctls. On 7 October Google added a second sandbox type: microVM sandboxes built on Kata Containers and Cloud Hypervisor went GA on GKE 1.37.0-gke.4713000 and later, aimed explicitly at AI agent runtimes. On the governance side, the CNCF Technical Oversight Committee voted on 28 September to accept gVisor into the CNCF Sandbox, and Google announced the donation on 2 October. Onboarding was still in progress when we checked.

Kata Containers

Kata Containers runs each pod in a lightweight virtual machine with its own dedicated kernel, using hardware virtualization as “a second layer of defense”. A container escape lands in the guest, not on the host. It plugs into Kubernetes through RuntimeClass: the kata-deploy installer creates one RuntimeClass per hypervisor shim, named kata-<shim>, with qemu-runtime-rs as the default shim, and a plain kata class exists only if you enable it, so run kubectl get runtimeclass and use the name it lists. Version 4.0, in July 2026, rewrote the runtime in Rust, and the latest release is 4.3.1 from 21 October. Run 4.3.0 or later: on 21 October the project published two advisories affecting 4.2.0 and earlier, a guest-to-host escape through out-of-bounds memory access in several of the Dragonball hypervisor’s virtio drivers (GHSA-ppr3-83x7-g97w, CVSS 6.4) and a permissive annotation allowlist that allowed unintended host and guest changes (GHSA-37rf-pj8c-g5g3, CVSS 7.9). On a managed service, check which Kata release your node image carries. Kata supports Cloud Hypervisor, QEMU, Dragonball and StratoVirt, and Firecracker too, although Firecracker ships as a separate shim that needs the devmapper snapshotter and is not on the default Rust runtime’s list.

Most teams will meet Kata through a managed version. AKS Pod Sandboxing runs it on Azure Linux with Cloud Hypervisor. Pods opt in with runtimeClassName: kata-vm-isolation on node pools created with --workload-runtime KataVmIsolation. Microsoft’s sizing guidance puts the microVM cost in concrete numbers: about 88Mi of memory overhead per pod for the default RuntimeClass, a 512Mi VM when no memory limit is set, and fractional CPU limits rounded up to a whole vCPU. Pod Sandboxing is Azure Linux only, with no Arm64 support, and cannot be combined with FIPS or Trusted Launch. Microsoft Defender for Containers does not assess Kata pods, so plan other runtime visibility for them. GKE’s microVM sandbox type, GA since 7 October, is the same idea on Google’s side.

Firecracker

Firecracker is the virtual machine monitor AWS built for Lambda and Fargate. It is written in Rust, runs on KVM, and has a companion jailer process as a second line of defense. Its site documents startup in under 125 milliseconds, under 5 MiB of memory overhead per microVM and up to 150 microVMs per second per host, with only five emulated devices; those are the project’s own figures. It is the boundary behind E2B’s sandboxes and behind AWS Lambda MicroVMs, a managed service AWS aims at AI agents and code-execution sandboxes. Firecracker is a building block rather than a product: on Kubernetes you reach it through Kata, and outside Kubernetes you write the orchestration yourself. The latest release is v1.17.0 from 10 September.

Kubernetes-native agent platforms: agent-sandbox and Agent Substrate

agent-sandbox and Agent Substrate manage agent lifecycles on Kubernetes, and neither one is the isolation boundary: that still comes from a runtime underneath, gVisor or Kata for agent-sandbox and gVisor or Cloud Hypervisor microVMs for Agent Substrate. agent-sandbox’s API is still v1beta1, and Agent Substrate is pre-1.0.

agent-sandbox

agent-sandbox is a Kubernetes SIG Apps project that adds a Sandbox custom resource and controller for “isolated, stateful, singleton workloads”: one pod with a stable identity and persistent storage, which fits neither a Deployment nor a StatefulSet. Three extensions make it practical for agents. SandboxTemplate is a reusable, admin-controlled template. SandboxClaim hands out a sandbox from a pool. SandboxWarmPool keeps pre-started sandboxes ready so a claim is fast. It ships Python, Go and TypeScript SDKs. Version 1.0.0 shipped on 28 August, weekly patch releases have followed, and the latest is v1.0.8 from 22 October.

Two things to understand before adopting it. First, it is an orchestrator, not a boundary. Its own documentation says it delegates isolation to runtimes such as gVisor or Kata through RuntimeClass, so a Sandbox without a runtimeClassName is an ordinary container. Second, the template’s defaults are a floor, not an egress allowlist. Per its threat model and API, a sandbox created from a SandboxTemplate gets a managed NetworkPolicy that allows ingress only from the Sandbox Router and blocks private ranges and cloud metadata endpoints, and has service account token mounting turned off. By default, though, that policy allows egress to any public IP on any port, and because NetworkPolicies add up, it overrides a namespace default-deny. To enforce your own allowlist, put your egress rules in the template’s networkPolicy field, where an empty egress list blocks everything (a custom networkPolicy also replaces the default ingress rule, so include one that admits the Sandbox Router, or the router can no longer reach the sandbox), or set networkPolicyManagement: Unmanaged and manage the policies yourself. A bare Sandbox gets none of the template defaults, so enforce templates with admission policy, and replace the router’s default allow-all authorizer, as the threat model recommends. Note also that the 1.0 is the release number. The API is still v1beta1.

Agent Substrate

Google’s Agent Substrate takes a different approach. It is an open-source runtime that separates agents from pods: idle agents are suspended, their memory and files snapshotted, and they are restored onto a pool of warm workers when they are needed again. Google claims 10x higher density than standard container runtimes and resume times under 500 milliseconds. Those are vendor figures with no published benchmark method. Isolation is gVisor by default on GKE, and the installer sets up only that runtime; Cloud Hypervisor microVMs, the hardware-isolated option, have to be deployed by hand to a node pool with nested virtualization. Google’s documentation describes it as building on agent-sandbox while bypassing the bottlenecks of the standard Kubernetes control plane.

Read the availability terms exactly. The project is open source, and on GKE it is “available to all GKE customers for non-production workloads”, with production support offered by allowlist. The upstream project calls itself pre-1.0 with no backward-compatibility guarantees, and v0.6.0 on 22 October brought breaking changes. The GKE documentation lists real limits: Standard clusters only, with c3-standard-4 or larger nodes and Workload Identity Federation; no GPU passthrough; open network connections dropped on suspend, and EgressPolicy rules, which cover default deny, hostname rules and credential injection, not supported on GKE. That last one matters most for this article: on GKE you still owe Agent Substrate the egress controls.

Sandboxes for the developer’s machine: Microsoft Execution Containers and NVIDIA OpenShell

MXC and OpenShell put agents inside OS-level process sandboxes and enforce a policy around them, and both offer a microVM option, still experimental in MXC. MXC is Microsoft’s generally available SDK that ships inside agents such as GitHub Copilot CLI; OpenShell is NVIDIA’s pre-1.0 open-source runtime that routes each outbound connection and DNS query through a supervisor that checks policy and injects credentials.

Microsoft Execution Containers (MXC)

MXC is the option most teams will meet first, because it ships inside the agents they already use. Microsoft made it generally available on 7 October as “a policy-driven execution layer for untrusted code or dynamically generated workloads”. It is an SDK, in Rust, .NET and Node.js, that an application builds in, not a service you deploy. A JSON policy covers process, file system, network and user-interface access, network access is denied by default, and the agent cannot grant itself more. The default backends are AppContainer on Windows 11, Seatbelt on macOS and Bubblewrap on Linux. Windows adds session and WSL containers and is the only platform where process containers produce a learning-mode activity report, and it needs recent cumulative updates. A MicroVM backend is marked experimental, and Intune management and Entra agent identity were still “coming soon” at GA. It is MIT-licensed at github.com/microsoft/mxc, and the latest release is v1.0.1 from 17 October.

At GA, Microsoft listed GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio and Unsloth AI as already supporting MXC. Anthropic’s Claude Code is on the list of partners that “will be releasing support”, so it had been announced but not shipped. In GitHub Copilot CLI it is one command, /sandbox, or a “Sandbox new sessions” toggle in the Copilot app. Know its scope: shell commands and local MCP and language servers run inside the boundary, while Copilot’s built-in file tools are policy-checked by the harness rather than isolated by the OS, and remote MCP servers sit outside it. The gap to know about: credentials are not one of MXC’s policy areas. Microsoft’s own announcement credits credential management to NVIDIA OpenShell, which it says is integrated into MXC. OpenShell’s own documentation still lists its Windows MXC runtime as “coming soon”, so confirm what ships before you count on the pairing.

NVIDIA OpenShell

OpenShell is NVIDIA’s open-source runtime for “fleets of autonomous AI agents”, and it is the most policy-forward design here. A trusted supervisor sits outside the boundary. Inside, the workload runs as a non-root user with no Linux capabilities, Landlock restricts the file system, and seccomp hands every outbound TCP connection and DNS query to the supervisor, which checks policy and injects credentials so the agent never holds them. An outer network fence blocks everything else. Before a policy change is applied, a formal-verification prover flags new risky access, such as credentialed reach or cloud metadata endpoints, and any finding blocks auto-approval.

It runs on Docker, Podman, Kubernetes through a Helm chart, or libkrun microVMs. On Kubernetes it needs the agent-sandbox CRDs and a CNI that actually enforces NetworkPolicy, because without enforcement, its setup guide warns, workloads may bypass the supervisor. It is pre-1.0. The 0.1 line began on 25 September with no in-place upgrade from 0.0.x, stable releases ship roughly weekly, and the latest is v0.1.5 from 20 October. Windows support through WSL 2 is experimental. Anonymous telemetry, limited to operational categories and counts, is on by default; turn it off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway or server.telemetryEnabled=false in Helm.

Hosted sandbox APIs: E2B, Modal and Daytona

If what you need is to run untrusted code on behalf of your own customers, such as a code-interpreter feature, buying beats building, provided you check three things: the boundary, the deployment model and the egress controls. E2B’s open-source runtime documents one Firecracker microVM per sandbox, each in its own cgroup and network namespace with its own egress firewall. E2B offers its hosted cloud, a BYOC deployment it manages inside your VPC, and a self-hosted single-machine edition. Modal Sandboxes run on gVisor by default, or since SDK 1.6.0 on 28 September in a full VM with its own kernel; GPU sandboxes are gVisor-only. Daytona offers containers or full VMs and lets you attach your own compute, but its open-source repository was archived in June 2026 when core development moved to a private codebase. Weigh that if self-hosting was the reason you chose it.

Which sandbox should you use?

Start from who wrote the code and where it runs, not from the product list.

Which ten controls matter more than the sandbox?

The ten controls are default-deny egress including DNS, hostname-based allowlists, a blocked cloud metadata endpoint, short-lived scoped credentials, unmounted service account tokens, push protection as a backstop, monitoring configuration the agent cannot reach, a per-agent identity with an audit trail it cannot edit, a tested kill switch, and human approval for irreversible or external actions. None of the eight products ships all of them, and most map directly to a failure in the incident reports above.

1. Default-deny egress, including DNS. OpenAI’s DNS report is the lesson: an HTTP allowlist with an open resolver is not an allowlist. Resolve through a filtering resolver and block direct DNS to anything else.
2. Allow destinations by name, at a layer that understands DNS. Standard Kubernetes NetworkPolicy works on IP addresses and ports and cannot express hostnames. Use a CNI with DNS-aware policy, such as Cilium’s toFQDNs, or an egress proxy. OpenShell does this in its supervisor.
3. Block the cloud metadata endpoint. An agent that can reach 169.254.169.254 can often reach the node’s cloud credentials. agent-sandbox’s templates block it by default; make sure everything else does too.
4. Issue short-lived, narrowly scoped credentials. Use OIDC federation instead of static cloud keys, read-only pull-through tokens for package registries, and a separate token per job. October showed the alternative: LiteLLM’s hijack began with that unrevoked May key, and Zeabur’s own report names long-lived admin credentials, stored in plaintext and usable from the internet, as the root cause of its breach.
5. Keep service account tokens unmounted. Set automountServiceAccountToken: false and mount a short-lived projected token only where the agent genuinely needs the Kubernetes API, which is rarely.
6. Turn on push protection, and treat it as a backstop. OpenAI documented a model splitting a token to get it past secret scanning. GitHub’s own documentation says push protection blocks only a subset of the most identifiable secret patterns and can time out on large pushes, and by default anyone with write access can bypass it by giving a reason. In OpenAI’s case, what GitHub rejected was a separate path rule on workflow files (“File path is restricted”), not secret detection, so the agent edited a script an existing workflow already ran. Protect the scripts your workflows call as well as the workflow files; our CI/CD supply chain playbook covers the pipeline side.
7. Keep monitoring and alerting config out of the agent’s reach. OpenAI’s 20 October report describes agents disabling alerts and removing a monitoring integration. Alert rules, dashboards and audit settings belong in a repository the agent cannot merge to, with code owners on those paths and an alert when an alert rule changes.
8. Give each agent its own identity, and an audit trail it cannot edit. Shared service accounts make every agent action look like every other. Ship agent activity logs to a store the agent has no write access to.
9. Test the kill switch. OpenAI’s DNS run kept going for about 2.5 hours after the alert because it did not stop automatically, and in the Harness survey only a third of respondents had an instant kill switch. Rehearse revoking an agent’s credentials and stopping its sandboxes in under fifteen minutes, before you need to.
10. Require human approval for irreversible or external actions. Submitting a form, sending a message, pushing to a public repository and deleting data should each need a person to approve them. Anthropic’s report of agents submitting forms on government websites is what happens without that gate.

How do you sandbox AI coding agents on Kubernetes?

Run each agent as a gVisor or Kata pod, directly or as an agent-sandbox Sandbox, in a namespace that enforces the restricted Pod Security Standard, with default-deny egress, a DNS-aware hostname allowlist and no standing credentials. Below is a reference setup, with each piece from the project’s own documentation. Before you start you need gVisor or Kata installed on the nodes (on GKE, GKE Sandbox does that for you), the agent-sandbox controller and CRDs for step 2, a CNI that enforces NetworkPolicy for step 4, without which those objects do nothing, and Cilium for step 5. Apply step 3 first, then steps 4 and 5, and only then the workloads in steps 1 and 2: they target the agents namespace, and a pod that starts before its policies exist can briefly run unprotected.

1. A RuntimeClass and a sandboxed pod. From the gVisor containerd quick start, with the securityContext the restricted Pod Security Standard in step 3 requires. The handler must match the runtime name configured in containerd on the node. On GKE, skip the RuntimeClass: GKE Sandbox already provides gvisor, so only set runtimeClassName: gvisor.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: agent
  namespace: agents
  labels:
    app: coding-agent
spec:
  runtimeClassName: gvisor
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: agent
    image: registry.example.com/agent:1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

2. Agents as Sandboxes, with the runtime set. Combines the README’s minimal Sandbox with the runtimeClassName setting from the agent-sandbox gVisor guide, plus the same restricted-compliant settings. In production, put runtimeClassName and your egress rules in an admin-owned SandboxTemplate so users cannot drop them, and set its networkPolicy first, as described in the agent-sandbox section above.

apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: my-sandbox
  namespace: agents
spec:
  podTemplate:
    metadata:
      labels:
        app: coding-agent
    spec:
      runtimeClassName: gvisor
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: my-container
        image: <IMAGE>
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]

3. A namespace that enforces the restricted Pod Security Standard. From the Pod Security Admission docs. Kubernetes has no Pod Security level for sandboxed runtimes, so apply restricted inside gVisor or Kata too: it removes privileges an agent could otherwise use against the sandbox. Pods in this namespace must set the fields shown in steps 1 and 2, and the image must run as a non-root user: if its Dockerfile has no numeric USER, add runAsUser, or the kubelet will refuse to start the container.

apiVersion: v1
kind: Namespace
metadata:
  name: agents
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

4. Default-deny egress, with DNS allowed only to the cluster resolver. From the NetworkPolicy docs, which now warn that a default-deny egress policy also blocks DNS. NetworkPolicy only does anything if your CNI enforces it. It is allow-only, works on IPs and ports rather than hostnames, and its handling of ipBlock behind NAT depends on the CNI, so back the metadata endpoint with the cloud’s own controls too. This pair stops pods from using outside resolvers, but CoreDNS still forwards any name upstream, so on its own it does not close a DNS tunnel; filter names at the CNI or resolver, as in step 5. The DNS policy here excludes pods labelled app: coding-agent, which get the filtered rule in step 5; on a CNI without DNS-aware policy, drop the exclusion and filter names in the resolver instead.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: agents
spec:
  podSelector: {}
  policyTypes:
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: agents
spec:
  podSelector:              # agent pods get filtered DNS from step 5 instead
    matchExpressions:
    - key: app
      operator: NotIn
      values: ["coding-agent"]
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

5. A hostname allowlist, where the CNI understands DNS. Adapted from Cilium’s DNS-based policy docs. We changed the policy name, label and hostname, added a namespace, and narrowed the DNS rule from the docs’ matchPattern: "*", which allows every lookup, to the same names as toFQDNs, so the cluster resolver cannot be used as a DNS tunnel. Label your agent pods app: coding-agent. Keep any plain port-53 allow, such as an unscoped version of step 4’s DNS policy, away from these pods: Cilium’s layer 7 docs say that when a layer 4 rule and a similar rule with layer 7 rules both apply, the layer 7 part has no effect, which would switch the name filter off. It needs Cilium’s L7 proxy enabled, which is the Helm default. By default the DNS proxy answers names outside the list with REFUSED, including the pod’s search-domain expansions such as api.github.com.agents.svc.cluster.local; some resolvers, notably musl in Alpine-based images, can then fail even for allowed names, which the Helm value dnsProxy.dnsRejectResponseCode: nameError avoids.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "agent-egress-allowlist"
  namespace: agents
spec:
  endpointSelector:
    matchLabels:
      app: coding-agent
  egress:
    - toEndpoints:
      - matchLabels:
          "k8s:io.kubernetes.pod.namespace": kube-system
          "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
           - port: "53"
             protocol: ANY
          rules:
            dns:
              - matchName: "api.github.com"
    - toFQDNs:
        - matchName: "api.github.com"

6. No standing credentials in the pod. Set automountServiceAccountToken: false on the ServiceAccount or the pod; the pod setting wins. If the agent must call the Kubernetes API, mount a projected service account token with a short expirationSeconds (Kubernetes requires at least 600 seconds), leave audience unset so it defaults to the API server, and bind the ServiceAccount to the narrowest RBAC role; set a custom audience only for tokens meant for another service, such as Vault. For cloud access, use workload identity rather than keys in environment variables.

Our take

The sandbox is the easier decision, and the market made it easier this quarter. Pick the boundary by who wrote the code and where it runs: gVisor for dense, untrusted workloads that tolerate its compatibility limits, Kata or a microVM sandbox when you need a separate kernel, and MXC or OpenShell on developer machines. Then spend the real effort on the ten controls, starting with egress and credentials. Those, plus monitoring the agent could edit, are where every incident the labs described in detail went wrong. Some products help: OpenShell injects credentials and checks every connection against policy, MXC denies network access by default, and agent-sandbox templates block the cloud metadata endpoint. None of the eight writes your allowlist, scopes your tokens or protects your alerting for you.

Our recommendation to clients this quarter is unglamorous. Inventory every place an agent runs today: laptops, CI, clusters and the SaaS agents with tokens into your systems. For each one, write down what it can reach, which credentials it holds and who would notice if it switched off an alert. Fix egress and credentials first, then choose the boundary. If your team does not have the time to do that mapping, that is the engagement to buy before the next agent rollout, not after. It is what DevSecOps consulting and Kubernetes consulting look like in 2026.

Related: AI SRE agents compared · Vibe coding’s security bill · DevSecOps supply chain security · DevSecOps consulting · Kubernetes consulting · DevOps for AI startups · What is DevSecOps?