Venya and NVIDIA OpenShell

"the more access you give the agent the more capable it becomes. You can't have your cake and eat it... the blurb reads like it can do it all, but now secure. That can't be true." smallnix, HN item 50201244

Agreed, and Venya does not claim otherwise. The trade is not removed, it is moved: what the agent gets is the ability to cause an authenticated action, not the ability to hold the thing that authorizes it. Values are injected inside the sandbox and output comes back redacted, so the useful half of the access stays and the leakable half does not. The limits on that are named in the same documents: the command string itself is recorded unmasked, and the redaction is a defense that assumes the sandbox boundary holds.

"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." fennecbutt, HN item 50201432

"If you can make any request to the outside world you can exfiltrate data, period." epolanski, HN item 50201532

This is true and Venya does not solve it. Our egress control is fail-closed on destinations and it fails closed when the allowlist is missing or empty, but it is not a data-loss-prevention control over what an allowlisted host is sent, and the destination name itself can leave the sandbox even when the payload is blocked. What Venya adds to that picture is attribution and containment rather than a claim: every command is attributed to the human whose key authorized the session, secret material in output is replaced with [REDACTED:...] by a compiled filter and then re-screened server-side with the store's own knowledge, and a filter failure returns nothing raw. If your threat model includes a determined slow-dribble exfiltration over an approved destination, the honest answer is that nobody in this product class ships a control that stops it, and you should assume it and scope what you allowlist accordingly.

"It seems like some kind of network logging would be useful? Even if you don't catch it, you'd want to know what it did." skybrian, HN item 50202264

Shipped: every step records actor, command string, executor id, secret ids (never values) and timestamps, in a trail the database will not let the application update or delete, with review scope enforced server-side. Not shipped: alerting, SIEM or any collector format. Today the record is queryable by a human and by an auditor role, and nothing will page you.

"Taking default telemetry is insane." dangoodmanUT, HN item 50199137

"There is no such thing [as anonymity in 2026]... the documentation listing the collected telemetry uses weasel words like 'such as' rather than providing a comprehensive list." lcampbell, HN item 50200078

Venya collects nothing operational and sends it to us. There is no default-on beacon to argue about and no env var to hunt for: the metrics endpoint that does exist is bound to the core's own loopback, and its address is not configurable precisely because the endpoint is unauthenticated — unset the port and it binds nothing. docs/FIREWALL.md enumerates every inbound and outbound path in a deployment, and no operational reporting to Tabith appears anywhere in it. What leaves your network is a fetch at install time (toolchains and packages, from your release origin), a sandbox template pull from Docker Hub, and your own traffic to your targets.

"Looks neat. I'll give Claude root access so it can set it up." spider-mario, HN item 50199498

"Or don't give it root access and in the morning you'll have both this and a ready-to-use root exploit!" yoavm, HN item 50199716

Venya's documented install is the same shape as OpenShell's - a piped script run as root - so this is not a row where we are better. What we ship around it is integrity and least privilege: the payload tarball is hash-gated and fail-closed, the encryption passphrase has no default and a length floor enforced before the installer mutates anything, and after installation the agent's command path reaches neither the admin plane nor the CA material, because those need a client certificate chained to the Admin CA plus a hardware-key ceremony. The joke in that thread is a real failure mode, and the answer to it is that an agent should not be the one installing the thing that gates it.

"Apparently agents will collude to break out of their individual sandboxes by delegating tasks to other agents that have the required permissions... you need them to coordinate on their tasks." prennert, HN item 50204990

"Any workflow that has both an input and an output will complete the Lethal Trifecta as a whole, but no single agent does by itself." smashed, HN item 50201845

Venya does not have a collective-permission view of a fleet and does not claim to. What limits the shape today is that capability is not what gets delegated: a second agent still needs its own session, and a session still needs a human's key. Secrets are scoped to roles, so "what can this executor reach" is a per-identity question rather than a per-model one, and every command lands in the audit trail attributed to a person. If you are building a fleet where agent A hands tainted content to agent B which then holds the private data and the network, Venya does not detect that for you - tag-and-monitor designs in that thread are ahead of what anyone here ships.

"most people running containers are running a default docker/containerd setup, which does not actually isolate you from anything at all" devmor, HN item 50203149

"I just want the whole harness inside a sandbox - ideally, a full VM" zmmmmm, HN item 50202392

Venya runs commands in microVMs rather than in a shared-kernel container, and the daemon that orchestrates them is seccomp-confined without CAP_IPC_LOCK. It does not, however, put your agent's harness in a VM - that stays on your workstation or wherever you run it, which is exactly the camp the second commenter is in. Our bet is a different one: the harness is the part you can replace, so the trust is anchored on the credential and the ceremony rather than on confining the model's own process.

"the level of control is cool, almost too pedantic. It likely is only particularly useful for very nuanced enterprise requirements" dangoodmanUT, HN item 50199137

"as isolation increases, so does friction, and then of course capabilities" amanfromhere, HN item 50204422

Fair, and it is the part of our own design we work on. The ceremony cost is real: a hardware key is required to open a session and again to read a value. Two things make it cheaper than it sounds - a session covers a window rather than a command (15-minute idle, 4-hour cap), and a command that needs a credential does not need a separate approval per call, because the value is injected by the executor inside the sandbox. The rough edges are published, not hidden: docs/beta-known-limitations.md currently carries an entry for administrator commands that asked for a ceremony they did not need, and one for sshpass with a redirect aimed at a remote sudo -S not delivering the password.

"Isn't using a sandbox provided by them giving you more restrictions though?... you're forced to move at their pace" fennecbutt, HN item 50200978

"Now if Microsoft will start addressing the fact that VSCode remote ssh exposes your host to attack from the sandbox..." Rapzid, HN item 50202661

Venya has a dependency in this exact place and says so on its own install page: the sandbox is Docker Sandboxes (sbx), a proprietary product of Docker, Inc., fetched from Docker's repository, requiring a Docker account and governed by Docker's Subscription Service Agreement. What Venya is not is a cloud: the core runs on your infrastructure, with your CA, and nothing in the architecture calls a service we operate. Agent-side, the integration point is MCP - the same protocol Claude Code, Cursor and any other client speak - so the harness is not part of the lock either.

"My expectation is that it will be poorly maintained; nvidia is not a software company." esafak, HN item 50199437

A question about them, and a fair one, so here is the mechanism on our side instead: Venya's control documentation is guarded by a test. docs/controls.md is parsed by packages/server/tests/test_controls_doc_cite_interlock.py, which resolves every file::symbol cite against the commit it records and fails the build when a symbol stops resolving - so a claim that goes stale is a red test rather than a silent page. That is the only honest answer to "how do I know what you say about your own code stays true": you make the statement and the tree disagree expensively.

"Is it fair to immediately get the ick from the name and the description... '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." jrm4, HN item 50199960

The instinct is sound and it applies to us. "Safe" and "secure" are not load-bearing words in this page or in our documentation - the control page's own first line is "Alignment, not certification", it says the word it supports is alignment and the word it never claims is certified, and there is a whole document whose job is to list what does not work yet. Anyone selling a runtime as safe, in a sentence, before a single mechanism, is inviting exactly the reaction that thread had.

"Critically, in the intended approach for this, Claude itself (the harness) runs outside the sandbox. Their approach means you trust Claude is perfect, just the commands it runs need isolation." zmmmmm, HN item 50202392

This is the sharpest architectural objection in the thread and it is worth answering directly, because Venya is deliberately in the "do not trust the model" camp at the specific boundary that matters to us. Nothing about a model's judgement is load-bearing for keeping a credential out of a context: the value never enters it, a session expires on a clock an agent cannot extend, reading a value needs a physical ceremony, and the deny-by-default allowlist resolves to no hosts when it is empty. We still trust the sandbox boundary to hold, and we say so - that is the assumption the redaction layer is built on.