Don't Trust the Sandbox Claim — Verify It Against Your Own CNI

"It's sandboxed" is not a security sign-off. If you're the one responsible for approving multi-tenant agent code execution on your own infrastructure, the question isn't whether a vendor says network access is denied by default — it's exactly which mechanism enforces that, and whether you can check it yourself on the cluster you actually operate.

"It's sandboxed" isn't sufficient for a sign-off

Every code-execution sandbox claims isolation. The claim that actually matters to a security review is more specific: what kernel or platform primitive is doing the enforcing, at what layer, and what happens if one layer is misconfigured. boxkite's network-dark-by-default posture rests on two independent mechanisms, not one — and being self-hostable means both are things you can check directly, on your own cluster, instead of taking on faith.

Layer one: a fresh network namespace per exec, by default

In boxkite's Kubernetes runtime mode, each exec call is designed to run inside a fresh, empty Linux network namespace by default — meaning the executed process starts with no network interfaces configured at all, not even a loopback route to the rest of the pod's networking. There's no interface for it to send traffic through in the first place, independent of any firewall rule deciding whether that traffic would be allowed. This is controlled by a config flag (default on); if it's ever turned off for a specific workflow, this layer disappears and the NetworkPolicy below becomes the only backstop — which is exactly why the second layer matters independently, not just as redundant belt-and-suspenders.

Layer two: a default-deny egress NetworkPolicy

Independent of the namespace, boxkite's deployment manifests ship a default-deny egress NetworkPolicy (see deploy/network-policy.yaml) applied at the pod level. This is the same kind of Kubernetes-native primitive a platform team already uses to restrict traffic between any two workloads on the cluster — it's not a boxkite-specific mechanism layered on top of unfamiliar infrastructure, it's the standard tool, applied.

Why the distinction matters even if one layer were misconfigured

Defense-in-depth means neither layer is a single point of failure for the other. If a network namespace were somehow set up incorrectly and left with an interface present, the pod's NetworkPolicy would still deny the egress. If the NetworkPolicy were misapplied or the CNI didn't enforce it correctly, the exec call would still have no interface to route traffic through. A review that only checks one of these has checked half the boundary.

The concrete verification step

The specific, well-known check worth running yourself: from inside a session, attempt to reach the cloud metadata endpoint most cloud providers expose at 169.254.169.254 — a classic target for exfiltrating credentials from a compromised workload. On a correctly isolated pod, this should simply fail to connect, not time out ambiguously or partially succeed.

# Run from inside a boxkite session (e.g. via bash_tool).
# On a correctly isolated pod this should fail fast with no route/connection,
# not hang indefinitely -- an ambiguous hang is itself worth investigating.
curl --max-time 3 -sS http://169.254.169.254/latest/meta-data/ ; echo "exit: $?"

This is a check you can only meaningfully run yourself if you operate the cluster the pod is running on — a hosted vendor telling you their sandbox passes this test is a claim; running it against your own deployment is a verification.

What being self-hostable buys a security team

The difference isn't that self-hosted infrastructure is inherently safer than a hosted product — it's that a security sign-off on self-hosted infrastructure can be based on tests you ran yourself, against manifests you can read, rather than a vendor's attestation you have no way to independently check.