---
title: Agent sandboxes and MCP
description: Agent devboxes as Kubernetes Sandboxes behind a gateway, and the MCP servers exposed to them. Partial by design.
weight: 10
icons: [kubernetes, nvidia, zitadel]
tags: [agents, sandbox, mcp, agentgateway]
---

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.