I'd be pretty keen to actually hear more about the Unikraft setup and other deeper details about the agent sandboxes regarding the tradeoffs and optimizations made. All the components are there but has someone open-sourced a more plug-and-play setup like this?
We haven't open-sourced the control plane glue yet but it's something we're thinking about. browser-use itself is open source. The sandbox infra on top is the proprietary part for now.
https://github.com/unikraft/cli
Feedback is very much appreciated, we're listening! :)
Essentially it’s just: remove .py files an execute del os.environ[“SESSION_TOKEN“]? This doesn’t really sound very secure, there are a number of ways to bypass both of these.
It’s just security through obscurity
The actual security model is the architecture itself: the sandbox runs in its own VM inside a private VPC. It has no AWS keys, no database credentials, no LLM API tokens. The only thing it can do is talk to the control plane, which validates every request and scopes every operation to that one session.
So even if you bypass all three hardening steps, you get a session token that only works inside that VPC, talking to a control plane that only lets you do things scoped to your own session. There's nothing to escalate to.
The bytecode removal, privilege drop, and env stripping are just there to make the agent's life harder if it tries to inspect its own runtime. Not the security boundary.
The problem is not what the LLM shouldn't have access to, it's what it does have access to.
The usefulness of LLMs is severely limited while they lack the ability to separate instructions and data, or as Yann LeCun said, predict the consequences of their actions.
Of all the problems in agent security, sandboxing solves the easiest problem.
The missing layer is pre-installation scanning. Runtime isolation + supply chain vetting together is the real answer.
