Source: github.com/NVIDIA/OpenShell
OpenShell runs each agent in its own sandbox, and operators describe in a policy which files, system calls and network destinations that agent may use. Kernel controls restrict file access and system calls, and every outbound network connection is checked against the policy before it leaves the sandbox. Agents never receive real credentials directly, since OpenShell attaches them only to requests sent to approved endpoints.
Before a proposed policy change is applied, OpenShell uses formal verification to flag new risky access, such as a new host that would receive credentials or a new API method. Flagged changes wait for human review. The project's documentation describes this as part of its gateway, supervisor and sandbox architecture.
The installer sets up a command-line tool and a local gateway on Linux, macOS on Apple Silicon, or Windows through WSL 2, which is listed as experimental. Python, TypeScript, Go and Rust SDKs connect applications to a gateway. The project collects anonymous operational telemetry, which can be turned off with an environment variable, and the code is licensed under Apache 2.0.
Why it matters if you build agents
Teams running several agents can scope file, network and credential access for each one instead of relying on instructions in prompts. Because credentials are injected only at approved endpoints, agents do not handle raw secrets. Expect policy edits that add hosts or API methods to pause for review, so build that step into deployment workflows.
Get stories like this every weekday
One short email with the day's agent tooling news.