the credential injection via MITM proxy is the most interesting part to me. the standard approach for agents is environment variables, which means the agent process can read them directly. having the sandbox intercept network calls and swap in credentials at the proxy layer means the agent code has a placeholder and never sees the real value -- useful when running less-trusted agent code or third-party tools.

the deny-by-default network policy also matters specifically for agent use: without it there is nothing stopping a tool call from exfiltrating context window contents to an arbitrary endpoint. most sandboxes focus on filesystem isolation and treat network as an afterthought.

This is the right direction. Running AI coding agents in production, the scariest moment is when an agent needs API access to do its job but you can't trust what it'll do with those credentials. We ended up with a simpler version of this: each agent runs in an isolated git worktree with only the env vars it specifically needs, and network access restricted to localhost + our API. No MITM proxy, just a stripped-down environment.

The deny-by-default model is correct. The question is how granular you need to be. For AI agents, I'd argue coarse-grained is better — network yes/no, filesystem scoped to one directory, no credential access. Fine-grained permissions add complexity the agent will just work around anyway.

Thanks and agreed! Zerobox uses the Deno sandboxing policy and also the same pattern for cred injection (placeholders as env vars, replaced at network call time).

Real secrets are never readable by any processes inside the sandbox:

```

zerobox -- echo $OPENAI_API_KEY

ZEROBOX_SECRET_a1b2c3d4e5...

```