alt Hacker NewsOpenShell – A safe, private runtime for fleets of autonomous AI agents
Comments
I've been using iron proxy recently for a project I just started, it does network restrictions by domain etc with plenty of options, credential swapping and more.
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"...
> Agents are most useful when they can read files, install packages, call APIs, and use credentials. OpenShell gives them that capability without giving them unrestricted access to your data, secrets, or network.
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.
If you haven’t already been running your agents in containers, you’re crazy. That said, this looks like a great way to manage those containers.
I tried to vibecode something similar last weekend. Got tripped up by Claude's safety classifier. It wouldn't let me build any features that track/audit process executions , not through custom kernel hooks nor even using off the shelf software for it.
We've been using OpenShell for a while - now enabling ourselves and other teams do this in a batteries-included kinda way. I've been working on a layer above it that also manages team policies, safe git usage (in case you don't want your agent to always have the same access as your user account), and SCA/SAST built in. Curious to see how others are dealing with these issues. The agent traces I've seen are wild and goal seeking without a boundary is real.
Just came back from GTC Europe and a significant part of the demos used that.
I had never heard about it before.
>OpenShell collects anonymous telemetry, limited to operational categories and counts, to help improve the project.
>To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm installs.
Agent runtime - actually a good name for what is called today coding agent or agent harness.
Taking default telemetry is insane.
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.
Nvidia Openshell is absolutely awesome, great bundle of features in one spot. Im happy to see Nvidia seems to have accelerated on support here, I was kinda worried that as competing projects have popped up in the last 6mo that openshell would get google'd
Question, why not force ai agents thru something like warpgate? I like it because it allows you to bring your own tool, so why can't we coexist with agents inside warpgate? Or Teleport if you have the coin.
What are people actually doing with fleets of agents?
In this vein, Anthropic's sandbox-runtime [0] has struck a good balance between security and convenience. Simple config, filesystem and network restrictions, and credential masking make me comfortable running Pi in YOLO mode.
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).
Lots of improvements in the sandboxing space.
Now if Microsoft will start addressing the fact that VSCode remote ssh exposes your host to attack from the sandbox...
I asked last week if anyone had any info on agent security/hardening, this seems very interesting !
Open and Nvidia in one sentence is a nice oxymoron.
It's funny that it takes checks notes a video game card manufacturer to make a good sandbox for AI agents and not the AI companies themselves...
I prefer to read it this way: Nvidia Opens Hell
Unhelpful, I know
I fantasize about a day when I no longer hear the phrase "fleet of ai agents".
How does it compare to docker sandbox? (That relies on microVMs)
Does anyone know how it compares to all the other sandboxes? Any distinguishing features? My expectation is that it will be poorly maintained; nvidia is not a software company.
Looks neat. I’ll give Claude root access so it can set it up.
Is it fair to immediately get the ick from the name and the description (OpenShell is the safe, private runtime for autonomous AI agents) without knowing anything about what it does?
"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.
Why are we reinventing virtualization & containerisation with AI flavour?
Can MXC JSON be used for configuration of OS-portable sandboxing policies with OpenShell, too?
"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.
NOOOOOOOO not AI in the heckin start menu!!!1!
This sandbox is finally secure! I know it, I have followed many!
Not to be confused with https://open-shell.github.io/Open-Shell-Menu/.
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[flagged]
From the top of AGENTS.md:
> 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
Well, I guess its time to shamelessly plug my agent sandbox, egzo.ai [1]
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/
From the pitch at GTC, the idea is not just to limit what each individual agent can do, but to also to ensure that the collective permissions do not exceed what you want agents to do.
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.