Agent sandboxes and MCP

Status: work in progress. What is described below runs today; the parts marked open are not resolved.

What runs

• The agent-sandbox controller (agents.x-k8s.io) creates a pod from a SandboxTemplate; a SandboxClaim asks for one. A devbox is a pod with a devcontainer inside, not a VM.
• An SSH gateway brokers connections to those sandboxes. It authorises through Zitadel, mints a short-lived credential per session, and is exposed as a TCP route on the gateway instead of a NodePort.
• MCP servers run as ordinary workloads and are reachable through agentgateway, with policy applied at the gateway rather than inside each server.

What is open

• Model serving. The GPU node has three cards; what runs on them is still being decided between a single serving stack with quotas and per-workload jobs.
• Identity for agents. Sandboxes authenticate as Kubernetes workloads today. Whether an agent gets its own Zitadel client or borrows the caller's is unresolved.
• GPU sharing. A card is currently allocated whole; sharing between sandboxes is not solved here.

Why the page exists anyway

Because the alternative is a page describing an architecture nobody has run. The constraint underneath: an agent platform that cannot sandbox its own tools is a liability, and one that sandboxes them badly is unusable. The shape above is the part that works.