boxkite
Security

Formatted for a security review.

boxkite executes arbitrary, agent-generated code. A security bug here is not a normal bug — it's a potential sandbox escape or credential leak for every self-hosted deployment. We treat security reports as the highest-priority category of issue in this project.

What's in scope

Report these

  • Sidecar HTTP API authentication bypass — anything that lets a request reach /exec, /file-create, /str-replace, /configure, /tool-call, or any other sidecar route without a valid X-Sidecar-Auth-Token, or that recovers/predicts another pod's token.
  • Session/tenant impersonation via /tool-call's session_idhandling — the field must always be ignored in favor of the sidecar's own current session.
  • Sandbox escape — anything that lets code in the sandbox container read/write outside its intended mounts, escalate privileges, or reach the sidecarcontainer's credentials.
  • Network isolation bypass — anything that lets sandboxed code reach the internet, the Kubernetes API, cloud metadata endpoints (IMDS), or other pods despite deploy/network-policy.yaml.
  • Secret exposure — sidecar storage credentials (S3/Azure) leaking into sandboxed process environments, logs, or tool output.
  • RBAC over-permissioning in deploy/rbac.yaml beyond what SandboxManager/WarmPoolManager actually need.
  • Path traversalin the sidecar's file endpoints (/file-create, /view, /str-replace, /present-files, /ls, /glob, /grep).
  • Command whitelist bypass in src/boxkite/command_whitelist.py for agents configured with sandbox_allowed_commands.
  • Manager-to-sidecar TLS bypass— anything that lets the manager's HTTP client accept a cert other than the one pinned for that specific pod, or that lets a pod's sidecar serve plaintext HTTP while SIDECAR_TLS_DISABLED is unset/false.
What's out of scope

Not a report

  • Vulnerabilities that require the operator to have already misconfigured RBAC to grant the sandbox pods themselves K8s API access — the manifests ship with automountServiceAccountToken: false specifically to prevent this.
  • Denial-of-service from a user intentionally exhausting their own sandbox's resource limits — that's the isolation working as intended, not a vulnerability.
  • Vulnerabilities in upstream dependencies without a boxkite-specific exploitation path — report those upstream, though we still want to know if a boxkite default makes an upstream CVE reachable.
Known trade-offs

Three things worth knowing, stated plainly

None of these block a safe deployment — they're inputs to your own threat model, not open incidents.

Dependency integrity

Checksums are cross-checked, not signed

Pandoc and Chrome-for-Testing are pinned to exact versions and verified against a sha256sum -cdigest, cross-checked against a second, independent source — GitHub's own release digest for pandoc, GCS's reported checksum for Chrome-for-Testing. That closes tampering in transit or from a compromised mirror.

Neither project publishes a signed manifest, so we re-verify by hand on every version bump (scripts/verify-pinned-checksums.sh).

Command allowlist

An allowlist can't scope what an interpreter does

SANDBOX_ALLOWED_COMMANDS restricts which commands run — but once python3 or nodeis on that list, anything they can execute is in scope too. That's how interpreters work, not a gap in the allowlist.

For a hard boundary, enforce it at the pod level — network policy, resource limits, capabilities — not the allowlist alone.

Process limits

Kubernetes has no native per-pod PID cap

CPU and memory are capped per pod, but the Pod API has no equivalent field for process count — a runaway fork loop via /execcould hit a node's PID ceiling before CPU/memory limits would otherwise throttle it.

Set kubelet's --pod-max-pidsflag once for your cluster — a pod spec in this repo can't express it on its own.

Reporting a vulnerability

Please report privately, not in a public issue

  1. Use GitHub's private vulnerability reporting — the Security tab of this repository, then Report a vulnerability.
  2. Describe the issue, affected version(s), and — if you have one — a reproduction (a minimal bash_tool/file_create payload, a pod spec diff, a network policy bypass, etc.).
  3. This opens a private advisory visible only to maintainers and you, with its own discussion thread, so a fix and disclosure timeline can be coordinated without exposing the issue while it's live.
  4. If you cannot use GitHub's private reporting, open a regular issue that says only "security issue, please contact me privately" with no technical details, and a maintainer will reach out for a private channel.

We aim to acknowledge reports within 5 business days and to have a fix or mitigation plan within 30 days for confirmed issues, faster for anything actively exploitable. Security reports get priority over everything else in the backlog.

Full technical writeup

The isolation model in depth — pod boundaries, per-exec network namespaces, sidecar privilege, and multi-tenant isolation.

Read the security & isolation model guide →

Authoritative source

Everything on this page is condensed from SECURITY.md — treat that file, not this page, as authoritative.

Read SECURITY.md on GitHub →