Skip to content

Agent sandboxes

You want an agent to run the code it writes - to analyse a file, transform some data, check its own work - without that code having the access your other workloads have.

Treat agent-generated code as unreviewed code from an untrusted author. This is not because models are malicious, but because what a model writes is steered by what it has read, and it reads things you did not write. A sandbox is what makes running that code a routine operation.

Prerequisites

  • A project and CLI access - see Get started
  • An agent that produces code to execute - usually talking to your LLM gateway

The step-by-step guide and the console walkthrough cover the operations. The rest of this page explains how it fits together.

The four boundaries

flowchart TB
    AGENT["agent"] -->|code| SB
    subgraph SB["sandbox project - its own namespace and quota"]
        direction TB
        POD["ephemeral pod<br/>no service account token<br/>CPU, memory and deadline set"]
        VOL["emptyDir - discarded with the pod"]
        POD --- VOL
    end
    SB -->|"stdout, stderr, artifacts"| AGENT
    SB -.->|default deny| NET(["network"])

Each boundary answers a different question, and a sandbox missing any one of them is not a sandbox.

Boundary Without it Control
Identity code talks to the Kubernetes API as your service account automountServiceAccountToken: false
Network anything the code was given can be sent anywhere default-deny egress, then a named allow-list
Resources one run starves everything else on the node CPU and memory limits, activeDeadlineSeconds
Persistence one run leaves things behind for the next ephemeral volume, pod deleted after the run

The identity boundary is the one most often missed, because nothing looks wrong when it is absent. A pod with a mounted service account token can list secrets, create workloads and read the state of your project - and code that finds a token will use it.

An open sandbox is not a sandbox

The isolation is only as strong as the egress policy. A sandbox that can reach the internet can send anything it was given anywhere, and "it only needs to install packages" is how a general internet allowance gets added. Allow hosts by name, one at a time, and review the list as you would a firewall rule.

What the sandbox does not protect

Being clear about the limits, because a boundary you overestimate is worse than one you know is absent.

  • Whatever you put in. If the input file contains secrets, the sandbox is holding secrets. It bounds what the code can reach on its own, not what you hand it.
  • The results you return. Output goes back to the model and into its context. Code cannot exfiltrate through a blocked network, but it can write to stdout, and stdout is read by something that talks to the outside world.
  • Your allow-list. A package registry you allow is a place from which arbitrary code arrives - that is what a package registry is.
  • Cost. Resource limits bound one run. Nothing here stops an agent starting a thousand.

Sandboxes are ephemeral by default

Each run gets a new pod and a new volume, and both are discarded when it finishes. This is deliberate. A long-lived sandbox accumulates state from every previous run, and that state is how one run reaches another.

Where a run genuinely needs to keep something, write it out as a returned artifact rather than leaving it in the sandbox for next time.

What is fixed after creation

Changeable
The egress allow-list yes
Resource limits and the deadline yes
The project's quota yes
Whether a completed run can be inspected no - the pod and its volume are gone

There is no platform sandbox service yet

The threat model and the four boundaries above are settled and safe to design against, and you can build them yourself from ordinary project, policy and quota objects. What the platform does not offer today is a sandbox service that runs them for you, or isolation stronger than a namespace boundary.