OpenShell – A safe, private runtime for fleets of autonomous AI agents
382 points - yesterday at 5:44 PM
SourceComments
Apparently agents will collude to break out of their individual sandboxes by delegating tasks to other agents that have the required permissions. This is a problem with agent fleets, because you need them to coordinate on their tasks. So you need to them to communicate.
A naive approach to prevent agents from doing something you dont want to do is a separation of powers, which individual permissions limited to each agents task. Say one agent to find and extract raw data, one to process it and write a report and one to publish it. If one of the agent decides that needs to publish the raw data, then chances are that they will collude to make that happen, even though no single agent has the permissions to achieve that goal.
OpenShell tries to fix this by monitoring the collective permissions set of the agent fleet, and by maintaining very granular permissions for each agent.
This was presented together with Sentry, which is something like a on-chip hardware firewall (BlueField) that sits between the chip agent run-time runs on, and the host. This improves safety by removing the ability of agents to modify their own OpenShell policies.
I have no affiliation with it, but it solved most of what I need in one go when I was stressing out about it.
Only real problem remaining if you truly want to be able to trust agents is how to prevent data (in my case codebases the agent works on) exfiltration a la HF incident.
We can restrict network to trusted domains, but there's always a chance an agent could be extra slippery especially if prompt injected and doing something like pushing data out a few characters at a time.
In my case I'm also giving it gh access and having to deeply check things like: can it manage to fork public repos and embarrass us by submitting prs, could it open issues, etc.
But that's kind of solved by proxying the heck out of gh rather than giving it direct (or wrapping it or whatever) for additional controls that gh themselves don't provide.
I'm still musing over the "it could send data to an allowed domain in a way we don't expect that exfiltrates something"...
To me this obfuscates an oxymoron: the more access you give the agent the more capable it becomes. You can't have you cake and eat it, this tool allows to strike a balance I guess. But the blurp reads like it can do it all, but now secure. That can't be true.
I had never heard about it before.
>To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm installs.
That aside, the level of control is cool, almost too pedantic. It likely is only particularly useful for very nuanced enterprise requirements (probably what it's targeting). Most companies can be much more coarse with their permissions, and I think the agentic industry is moving away from k8s as a deployment platform.
Though I'm often running into frustrating (albeit intentional) sandbox restrictions with common workflows e.g. xcode/swift and Docker access.
Would love suggestions for how to give agents access to those kinds of tooling inside the sandbox, either with srt or an alternative (with similar convenience characteristics).
Now if Microsoft will start addressing the fact that VSCode remote ssh exposes your host to attack from the sandbox...
Unhelpful, I know
"Open" and "Shell" and just calling something private and safe out the box genuinely makes me think it's likely to fail at all of those claims.
"feat(ai-sandbox): accept MXC policy JSON for protected execution · westurner/sandbox@7538c33" https://github.com/westurner/sandbox/commit/7538c3386af8cb62...
"bwrap: Add the option to skip the procfs mount · Pull Request #1508 · microsoft/mxc" https://github.com/microsoft/mxc/pull/1508
"Manage Sandboxes | NVIDIA OpenShell" https://docs.nvidia.com/openshell/latest/how-it-works/sandbo...
To sandbox LSP servers in sphinxdocrs with bwrap in rootless containers, we needed to add a --no-procfs-mount CLI arg (and MXC JSON) to sandboxes, because you can't mount /proc in a rootless container.
> We design systems and use agents to implement them — this is not vibe coding.
Lol, what is even the point of such a statement, and who are they to define what vibe codig is or isn't :D
Spyware
Looking at the complexity of OpenShell and the simplicity of just building on top of docker, in a whitelist only mode.. I don't quite get the use-case of OpenShell. May be for large orgs where there is so much legacy and difficulty in organizing access to tools, OpenShell can simply re-use whatever you already have access to on your corporate account.
I chose to build straight on top of docker and agents are simply fully sandboxed by default. All data and network access must be granted in a simple project file, docker-compose style.
The web-ui connects to the docker socket and lets you spawn agents, and connect terminals. I'm having lots of fun with it and it allows me to cleanly organize and isolate my projects.
End-goal is to monitor for the Lethal Trifecta [2], ensuring all individual agents are properly isolated. Not quite there yet.
1: https://github.com/egzo-ai/egzo 2: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/