Per-fork egress

When you run untrusted or model-generated code, you want to control what it can reach. Collimate applies an egress policy per sandbox — and you can override it per create and per exec, so different branches of a rollout can have different network reach.

Where a policy applies

An egress policy resolves in this order, most specific wins:

1. Per exec — the egress field on an exec request, including the exec that drives a fork's rollout.
2. Per sandbox — the egress field on POST /v1/sandboxes (create).
3. Template default — the policy baked into the template.

Net templates only

Egress policy applies to network-capable (net/browser) templates. Pure code templates that never need outbound networking run on a fast in-guest-only path with no network surface at all — the tightest default.

Setting a policy

Pass an egress object on create (or per exec):

curl https://api.collimate.ai/v1/sandboxes \
  -H "Authorization: Bearer $COLLIMATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "template": "browser",
        "egress": { "allow": ["api.github.com", "pypi.org"] }
      }'

The policy is passed through to the sandbox, so a policy set on the parent carries to its execs; a per-exec override beats it for that call only.

The metadata endpoint is always blocked

Regardless of policy, sandbox egress to the cloud metadata endpoint (169.254.169.254) is blocked. That endpoint is the classic escape hatch for untrusted code to steal a node's cloud credentials; on Collimate it is closed by default and cannot be re-opened by a tenant policy.

Per-branch reach in a fork tree

Because egress is per-sandbox and per-exec, a fork tree can give each branch different reach: prepare a locked-down parent, then fork children that each get a narrow, task-specific allowlist. A rollout that must fetch one API gets exactly that host and nothing else.

Next steps

• Running code — the egress field on exec.
• Live fork — per-branch reach in a fork tree.