Here's the case that convinced me a static allowlist isn't enough for coding agents.
An agent reads a .env file. Ten minutes later, in the same session, it runs a curl to a host it hasn't talked to before, and part of the request body happens to match a value from that file. Every individual step looks fine. Reading config is normal. Curl is normal. The problem is the combination, and the combination only exists across time.
What a sandbox sees
A sandbox sees a process making a network call and checks whether that's allowed. It doesn't know what the process read earlier. It can't, that isn't its job. So the same curl command gets the same answer every time, and if outbound network is allowed at all, the secret leaves.
This is what Simon Willison calls the lethal trifecta: private data, untrusted content, and a path to exfiltrate. A coding agent on your laptop usually has all three at once. You can't remove any of them and still get work done, so the decision has to happen per action, with the session's history in view.
What Doberman does instead
Doberman keeps session state. When the agent reads something secret-shaped, the session gets a raised floor on outbound actions. Nothing is blocked yet, but the bar for the next network call goes up. When an outbound value matches something the session already read, that's a hard BLOCK, and the reason code says why: secret-egress taint from the earlier read.
Same curl, two verdicts. Fine in a clean session, blocked in one that just touched a secret. That's taint tracking, not an allowlist, and it's the part sandboxing alone can't do.
What it doesn't do
I'll say the limits before someone else does. The match is on shape and value, not intent. An agent that encodes the secret first, or splits it across two calls, is a different attack, and the benchmark corpus has a category for encoded exfiltration precisely because it's harder. The numbers for that category are in docs/BENCHMARKS.md, misses first.
The log never stores the secret either. It stores an HMAC-SHA256 fingerprint of what was involved, so you can prove "a secret-shaped thing was present and this happened" without the log becoming a second copy of the secret.
Run both
Sandboxes limit where the damage lands. Something still has to decide whether the action happens at all. I run both, and I mean that every time I say it.
pip install doberman-core, doberman setup, then doberman demo to watch the .env-then-curl case get blocked on your own machine.
https://github.com/DobermanCore/Doberman-Core
What's the one action in your agent's session you'd want judged by what came before it?
Top comments (1)
The core issue with stateless sandboxing for coding agents is treating security verification as a Markovian process. Evaluating each shell execution or network call in isolation assumes the risk of an egress call at step t is independent of the read operations performed across the earlier session history.
That assumption fails the moment an agent interacts with local configuration. The marginal risk of a curl command is conditional on the session's prior state. Once an agent loads a token or credential into working memory, every subsequent network hop carries an unhedged exfiltration exposure that static allowlists cannot price. Tying egress authorization to stateful taint tracking bounds that blast radius without forcing engineers to lock down outbound network access entirely.