Why we built BentoBox

AI agents are no longer just generating text they're executing shell commands, running builds, editing repositories, calling APIs, and making decisions without human intervention. That changes the security model completely.

Most existing approaches rely on containers or virtual machines. They're powerful, but they also introduce startup latency, images to manage, and extra infrastructure. On the other end, interpreter-level sandboxes only restrict the language runtime, which can often be bypassed once native code or subprocesses come into play.

We built BentoBox around a different idea, let the operating system enforce the boundary.

Instead of trusting the agent, we trust the kernel. Every sandbox is isolated using native OS security mechanisms, with a deny-by-default policy. Agents can only access the files, directories, network, and resources they've explicitly been granted. Credentials like SSH keys, cloud configs, Git credentials, browser data, and keychains remain inaccessible unless you intentionally expose them.

Because BentoBox uses capabilities already built into the operating system, there's nothing extra to install, no daemon to keep running, and no heavyweight virtualization layer. Sandboxes start in milliseconds while still providing kernel-enforced isolation.

On top of that, BentoBox adds the primitives autonomous agents actually need: isolated compartments, per-task permissions, snapshots and rollback, network policies, credential proxying, output compression, and SDKs for both Python and TypeScript all powered by a single Rust core.

Our goal isn't to build another sandbox. It's to provide a secure execution runtime for autonomous AI agents that feels lightweight enough for everyday development while remaining safe by default.

We're excited to hear your thoughts, feedback, and ideas for where this should go next.

BentoBox

Sandbox any AI agent in seconds.

Sandbox any AI agent in seconds.