Sandboxing for AI Agents

[wsmoak]

My goal for a while has been to take all the stuff running on my laptop, run it in the cloud, run more than one of them, and make it safe to run with --dangerously-skip-permissions. All the source code and the running applications that talk to each other, and their databases plus the AI agents (Claude Code, Codex) so they can fix things, diagnose problems, click around and take screenshots, reach the issue tracker, etc.

Each container has its own mitmproxy instance configured to inject credentials -- it can't exfiltrate what it never possesses.

I've got it working in K8s with the proxy in a sidecar for now, but it's a lot of bespoke kubectl scripting at the moment, definitely not ready for production.

Is anyone doing anything similar?

(Thanks again for rescuing the abandoned DevPod project and continuing it as Devsy!)

[vishalhabib99]

Yes. The "inject credentials at a proxy so the agent never holds them" pattern is becoming the standard shape for this, so you're in good company. Some prior art to compare your sidecar against:

• nono (nolabs-ai/nono) has proxy-based credential injection as a built-in feature (--credential). The agent sends plain HTTP to localhost:<port>/<service>/... and the proxy adds the real key and forwards over TLS. It's local-process sandboxing (Landlock/Seatbelt) rather than K8s, but the credential model is the same as yours and their docs cover the edge cases (streaming, MCP Streamable HTTP).
• Anthropic's reference dev container for Claude Code (anthropics/claude-code/.devcontainer) pairs --dangerously-skip-permissions with a default-deny egress firewall (init-firewall.sh). It has no credential injection, but its egress allowlist is the other half of what you're building.

Gaps worth checking in your setup, since they're where these designs usually leak:

1. The agent's own model credential. Claude Code's OAuth token lives in ~/.claude inside the container. Anthropic's docs warn about exactly this: under --dangerously-skip-permissions a malicious repo can exfiltrate anything in the container, "including the Claude Code credentials stored in ~/.claude". To close it, route the model traffic through your proxy too (ANTHROPIC_BASE_URL pointing at mitmproxy, which injects an API key), so nothing reusable lives in the container.
2. Credential injection prevents theft, not misuse. The agent can't read the GitHub token, but it can still use it through the proxy, including posting your source code into an issue comment. Scope each container's tokens narrowly (fine-grained, per-repo, short-lived), attach each credential only to its own host in the mitmproxy rules, and consider method/path rules (for example read-only for the issue tracker unless the task needs writes).
3. Egress allowlist alongside the proxy. If the container can reach arbitrary hosts directly, data can leave without touching mitmproxy. A NetworkPolicy that only allows egress to the sidecar makes the proxy the single exit, and gives you a complete request log per container for free.
4. Per-container identity in the logs. Once you run several agents, being able to answer "which agent made this call, on which task" from proxy logs is what makes post-incident review possible. Tag requests with the pod/task id at the proxy.

On the bespoke kubectl scripting: a devcontainer.json that declares the sidecar, plus a NetworkPolicy template per workspace, seems like the natural thing for Devsy to generate. It would be a nice feature request if the maintainers are interested.