Skip to content

Run a sandboxed agent

By the end of this tutorial you will be able to run agent-generated code in an isolated, ephemeral environment — no service account token, no mounted secrets, default-deny egress, and hard resource limits.

Prefer clicking through the console instead? See the console walkthrough.

Scaffold status

The step structure below is agreed and stable. Exact commands, manifests and captured output are added as this flow is verified end to end on the live platform — this page deliberately shows no invented output.

Prerequisites

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

The threat model

Agent-generated code is unreviewed code. Assume it may try to read credentials, reach the network, or consume everything it is given. The sandbox is what makes that acceptable rather than dangerous.

flowchart TB
    AGENT["Agent"] -->|code| SB
    subgraph SB["Sandbox namespace"]
        POD["Ephemeral pod<br/>automountServiceAccountToken: false"]
        VOL["Ephemeral volume"]
    end
    SB -->|results only| AGENT
    SB -.->|default deny| NET(["Network"])

Steps

1. Create a dedicated sandbox project

With a ResourceQuota sized so that a runaway sandbox cannot starve anything else.

2. Disable the service account token

automountServiceAccountToken: false on the pod spec. Without this, code inside the sandbox can talk to the Kubernetes API as your service account.

3. Apply default-deny egress

Then allow only what the sandbox genuinely needs — usually DNS and a package registry, and nothing more.

4. Set resource limits and a deadline

CPU, memory and an activeDeadlineSeconds so the pod dies on its own rather than running forever.

5. Mount an ephemeral volume

emptyDir for the working directory. It is discarded with the pod.

6. Run and collect results

Submit the code, capture stdout, stderr and any produced artifacts, and return them to the agent.

Verify

Confirm all four boundaries hold before you trust the sandbox with anything real:

# 1. No service account token
oc exec <pod> -n <sandbox-project> -- \
  cat /var/run/secrets/kubernetes.io/serviceaccount/token \
  || echo "no token, as expected"

# 2. Egress is denied
oc exec <pod> -n <sandbox-project> -- \
  curl -sS --max-time 5 https://example.com || echo "blocked, as expected"

# 3. Limits are enforced
oc describe pod <pod> -n <sandbox-project> | grep -A4 Limits

# 4. Nothing survives
oc delete pod <pod> -n <sandbox-project>

An open sandbox is not a sandbox

The isolation is only as good as the egress policy. A sandbox that can reach the internet can send anything it has been given anywhere. Allow hosts by name, one at a time, and review the list.

Clean up

Remove everything this tutorial created, in reverse order:

oc delete -k . -n <project>          # or delete the project outright
oc delete project <project>

Next

You have finished the bootstrap path. Go deeper in Architecture, or see Operations for running this in production.