Skip to content
CONTROL THE AGENT'S REACH

Sandboxes for coding agents

Run Cursor, Claude, Codex or any agent you bring in a container that sees your project and reaches only the hosts you allow. Provider credentials stay outside the sandbox.

zsh — cautem
❯ cautem sandbox create \
--name codex-work --from codex \
--workspace "$PWD" --provider codex
pulling image · starting proxy · applying policy
✓ sandbox codex-work ready

After importing the codex-api profile and configuring the codex credential provider. --from codex selects the agent image; --provider codex attaches credentials. Status lines are illustrative; cautem term opens the TUI.

Why

Coding agents run shell commands, install packages and call APIs for you. Run them straight on your machine and they get your whole home directory, SSH keys, cloud credentials and an open internet connection. One bad prompt or poisoned package is enough to leak or break something.

cautem runs the agent in a container with a restricted workspace and policy-controlled network access. Credentials managed through providers stay outside the container.

  • Only the project


    Your folder is mounted at /workspace. No docker.sock, no ~/.ssh, no ~/.aws inside.

  • Default-deny network


    Nothing leaves the sandbox unless the policy allows the host — and for HTTPS, the method and path.

  • Secrets stay outside


    For configured providers, the agent sees placeholders. The proxy inserts real tokens only into allowed requests.

  • Live policy


    The agent proposes a narrow rule, you approve it, the proxy reloads in about a second — no rebuild.

  • Any agent


    Ready images for Cursor, Claude and Codex, or bring your own container.

  • Docker or Podman


    Same layout on both engines; Kubernetes and MicroVM are on the way.

How it works

sequenceDiagram
    autonumber
    actor You
    participant S as Sandbox (agent)
    participant P as Egress proxy
    participant U as Internet
    You->>S: cautem sandbox create
    S->>P: HTTPS request with a secret placeholder
    P->>P: Check host, method and path against the policy
    alt allowed
        P->>U: Forward with the real secret
        U-->>S: Response
    else blocked
        P-->>S: 403 + reason
        S->>You: Propose a narrow rule
        You->>P: cautem rule approve
    end
  1. Create. cautem sandbox create starts two containers on a private network: the sandbox with the agent and your workspace, and an egress proxy next to it.
  2. Every request goes through the proxy. The sandbox has no other way out, so all traffic is checked against your policy.
  3. Secrets are swapped on the way out. The agent only ever holds placeholders like cautem:resolve:env:GITHUB_TOKEN; the proxy puts the real token into requests the policy allows.
  4. Blocked means explained. A denied request gets a 403 with the reason, so the agent can ask for exactly the access it needs.
  5. You stay in control. Approve or reject the proposal; the new policy is live in about a second, without recreating the sandbox.

More detail: Architecture · Security.