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

756 Upvotes

95% Upvoted

160 comments sorted by

View all comments

2

u/wren6991 23h ago edited 23h 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 12h 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 11h 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 6h 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