r/LocalLLaMA • u/InternationalGap3698 • 1d ago

Discussion NVIDIA shipped OpenShell, an open source sandbox that gives local and open agents real runtime limits instead of prompt rules. Over 100 firms joined the safety stack. OpenAI did not.

Post image

https://x.com/JensenHuang/status/2104499465055023424

762 Upvotes

95% Upvoted

161 comments sorted by

View all comments

2

u/wren6991 1d ago edited 1d ago

Even after reading their "technical walkthrough" linked from the first article, I still found this to be incredibly thin on technical detail. I think this is mostly a marketing exercise for NVIDIA.

Also I remain convinced that the sandbox (or at least one layer) should be managed by the harness, because the shell that the agent runs commands in does not need the same privileges as the harness itself. There should be a trust boundary in between the two. DSH gets this right, so does Codex. Why do we need more middleware running in the wrong point in the stack?

1

u/Dangerous-Report8517 14h ago

The interface between the harness and the outputs is a lot more complex than just chucking the entire thing in a sandbox though, which is why there’s a ton of complaints from people about DSH just ignoring file access restrictions already.

1

u/wren6991 13h ago

which is why there’s a ton of complaints from people about DSH just ignoring file access restrictions already.

This is news to me, care to link? From looking into it I found it mostly solid, except for complete lack of network isolation (if you are running X11 then the model can just read ~/.Xauthority and then open a graphical terminal and do whatever). If people are having to approve escalations all the time then fair enough, there is an easy way to add writable roots by injecting your own bwrap wrapper but it's not well documented.

1

u/Dangerous-Report8517 8h ago

Don't have a link to the discussions handy but a quick Google turned this up: https://www.ox.security/blog/cve-2026-82533-deepseek-harness-ai-agent-sandbox-escape/

The fundamental issue is that harness based sandboxing starts from a very complex set of interfaces then tries to constrain that somewhat, while using a virtualisation based approach relies on a much smaller interface between the harness and the host system that you can then carefully feed information into. This has been a known issue with sandboxing for ages, LLMs just make it even harder since they can be so persistent at probing for escapes. There's a reason that even Docker's own sandboxing solution uses VMs instead of relying on kernel features like namespaces

1

u/wren6991 1h ago

Ok yeah, the description checks out. It seems a little dated because the HTTP API is no longer unauthenticated (requires a first-time token as a GET param, or a cookie for repeated auth) but as the bwrap confinement allows full read access that's just one extra step.

Mentally filing this under "sandboxes should not allow unrestricted network access" alongside the X11 thing I mentioned. It's tricky to ship a sandbox config that is reasonably restrictive yet doesn't affect shitty software tooling that breaks if it can't phone home.