Every tutorial about building AI agents talks about sandboxing. Use Firecracker microVMs. Compile to WebAssembly. Spin up isolated containers. The message is clear: agents are dangerous, and you need to contain them.
I believed this too. Then I watched how my own agent actually works, and I started to wonder if we're solving the wrong problem.
The Fortress Mentality
Here's what the sandboxing advocates get right: AI agents can run code, access files, make network calls. In the wrong hands, that's a liability. If your agent is executing untrusted prompts from the outside world, you absolutely need isolation.
But here's what they miss: most agents aren't executing untrusted code. They're executing their own reasoning.
ZeroClaw, the agent I run, has full access to my filesystem. It can edit files, run git commands, search the web. Does that make me nervous? Not anymore. Here's why:
The Real Threat Model
When people design agent sandboxes, they're thinking about this scenario:
Attacker → sends malicious prompt → agent runs harmful code → system compromised
But that's not how my agent works. The threat model for a personal agent looks different:
Me → give agent a task → agent uses MY tools to accomplish MY goals → I review every action
The agent isn't a public-facing API. It's my assistant. And in that context, the question isn't "how do I stop the agent from doing bad things?" — it's "how do I make sure I can see what the agent is doing?"
What Actually Matters
After running agents in production for months, here's what I've learned matters:
1. Visibility over isolation. I can see every tool call my agent makes. When it reads a file, I know. When it runs a command, I see it. That visibility is worth more than any sandbox. A contained agent that does mysterious things is more dangerous than an open agent that tells me everything.
2. Commit over execute. My agent doesn't just run things — it commits them. Every file change, every post, every decision gets git commit. I can always roll back. The safety net isn't the sandbox; it's the audit trail.
3. Graduated trust. My agent can write blog posts freely. It needs my approval before touching sensitive configs. The permissions scale with the stakes, not with some arbitrary "untrusted code" boundary.
4. Human in the loop for the big stuff. Delete operations? Network calls that cost money? Anything that modifies production? My agent asks first. Not because it can't do those things — but because those are my decisions to make.
When Sandboxing Actually Makes Sense
I'm not saying sandboxes are never needed. They absolutely are — in these scenarios:
- Public-facing agents that accept arbitrary prompts from strangers
- Multi-tenant systems where one user's agent shouldn't access another's data
- High-security environments with strict compliance requirements
- Agents that run untrusted code as part of their function (like a code interpreter)
But notice: that's most SaaS agent products, not personal AI assistants.
The Simplicity Argument
There's another thing the sandbox folks miss: complexity is a vulnerability too.
Every layer of isolation adds:
- Latency (starting a microVM takes seconds)
- Cost (Firecracker isn't free)
- Debugging difficulty (what happened inside the sandbox?)
- Maintenance burden (keeping isolation up-to-date)
I've seen teams spend months building elaborate sandbox architectures, only to discover the real bugs were in their agent logic, not in their security boundary.
What I'd Build Instead
If I were designing a new agent system today, here's where I'd focus:
- Event observability — Every action logged, searchable, traceable
- Permission tiers — Fine-grained control over what the agent can do without asking
- Approval workflows — Easy way to say "yes" or "no" to pending actions
- Rollback capability — Git is your friend. Everything goes through version control.
That's it. No WASM compilation, no container orchestration. Just good tooling around the agent's actual behavior.
The Counter-Argument
I know what the sandbox advocates will say: "What if the agent is compromised? What if there's a prompt injection?"
Fair questions. But here's my answer: if your agent is compromised through prompt injection, the sandbox won't save you anyway. The attacker who can inject prompts can also bypass your sandbox boundaries. And if the agent itself is "compromised" — meaning it's acting in ways you didn't intend — the sandbox just makes it harder for you to see what's happening.
The real defense against prompt injection is:
- Input sanitization (handle with care)
- Output validation (check what the agent produces)
- Rate limiting (slow down abuse)
- Monitoring (know when something's wrong)
None of those require a fortress.
The Bottom Line
The best security is the security you understand. The best sandbox is the one that doesn't hide what's happening. And the best agent is one that works with you, not in a locked room where you can't see what it's doing.
Build visibility first. Add permissions when needed. And save the heavy-duty isolation for when you actually have untrusted code to run.
That's what I've learned from running agents in the real world. Your threat model probably looks more like mine than you think.