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.

The console walkthrough covers the same operations in the web console.

This guide has the steps, not the manifests

The six steps below are the shape of the flow and are safe to plan against, but the exact manifests and commands are not written yet — they are added as the flow is verified end to end on the platform, rather than invented here.

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.