crackbox

a sandbox proxy for untrusted code · ← hub

Run an AI agent, a CI script, or any other untrusted command with a tight allowlist of hosts it can reach. Everything else is silently blocked.

why

Agents and build scripts want the network. You want them to reach github.com and api.anthropic.com — not your internal services, not crypto miners shipped in a compromised npm package, not whoever a prompt injection points them at.

Browser permission prompts don’t fit. Per-process iptables is fiddly. Network-level egress firewalls don’t know which process is calling. crackbox is a small proxy you put in front of the workload and tell what hosts are allowed.

show me

# build the image once (from the arizuko repo root, not crackbox/)
git clone https://github.com/kronael/arizuko && cd arizuko
docker build -t crackbox:latest -f crackbox/Dockerfile .

# allowed -> 200
crackbox run --allow github.com -- curl -s -o /dev/null -w '%{http_code}\n' https://github.com

# unlisted -> blocked
crackbox run --allow github.com -- curl -s -o /dev/null -w '%{http_code}\n' https://example.com

# python image, install one package, nothing else reachable
crackbox run --image python:3 --allow pypi.org,files.pythonhosted.org -- pip install requests

Subdomains match the parent (--allow github.com covers api.github.com). Comma-separated for multiple hosts. --allow is required and must be non-empty; pass an unreachable placeholder like --allow none.invalid to block everything.

good for

• AI agents. An agent that can curl the open internet is one prompt injection away from talking to whoever the attacker wants.
• CI & build steps. “npm install only talks to the registry” is a sentence you can mean.
• Unfamiliar binaries. Tutorial repos, LLM-generated scripts, vendor blobs — whatever they do, they can’t exfiltrate to anywhere unexpected.

where do I start

For one-off runs, crackbox run --allow X -- <cmd> is the whole interface. It spins up a private Docker network, runs the proxy on it, runs your workload, tears everything down on exit.

For service deployments where short-lived workloads come and go, run the proxy as a long-lived daemon and register each workload with it as it starts. The reference covers the daemon, admin API, config file, env vars, and threat model.