An agent can be told to stay inside a boundary. The more interesting question is which component can stop it crossing that boundary.
NVIDIA's October 21 OpenShell announcement puts runtime enforcement at the center of that question. I followed the documented request path, then found a detail worth checking before copying a quickstart: omitting --policy does not prove that the restrictive default policy is active. [1][3] 🔍
Original conceptual diagram based on the pinned architecture documentation. This is a source explanation, not a captured deployment or penetration test.
Follow one request
Suppose an agent wants to call an external API. In OpenShell's documented architecture, the workload cannot simply open an unrestricted route to that service. Its network traffic passes through a protected channel to a supervisor outside the agent's trust boundary. The supervisor checks policy and opens an allowed connection. [2]
That separation is the useful idea. The program asking for access does not own the component that grants it.
A policy prover is another component: the docs say it checks proposed network changes for expanded access before approval. I would read that as a check on modeled policy changes, rather than a claim that every possible agent action has been formally proved safe. [2] 💡
The fallback is conditional
The default-policy reference is more specific than “a sandbox starts locked down.” Its restrictive fallback applies only when there is no active global policy, saved sandbox policy or policy supplied by the image. An image or configuration can supply policy even when the create command has no --policy flag. An invalid image policy blocks startup instead of silently choosing the fallback. [3]
The fallback itself has no outbound network rules. But attached providers can contribute rules to the effective policy. A description of the fallback therefore does not fully describe the permissions of a running sandbox. [3]
⚠️ This is an easy review mistake: looking at the command somebody typed and inferring the entire access boundary from the flags it omitted.
The question to ask is which policy was selected and what additional rules became effective. That is more useful than the label “default.”
Credentials also have a boundary
The documented sandbox path keeps real provider credentials out of the agent workload and supplies them only for allowed destinations. That reduces the need to place reusable keys directly in the agent's environment. [2]
There is an important scope detail in the provider reference. A privileged operator can retrieve selected runtime credentials through an explicit RPC. The docs warn that this exports values outside sandbox endpoint enforcement. Ordinary users and OIDC admins cannot call that RPC. [4]
So “the agent does not see the real key” describes the mediated workload path. It does not mean the platform has no privileged credential-export operation. Different actors have different powers. 🔐
What this changes in a deployment review
I would trace one allowed request and one denied request through the actual runtime, inspect the selected and effective policies, and check who can change them. I would also check provider attachments and operator privileges together; reviewing only the agent prompt misses those decisions.
Those are proposed verification steps, not tests I performed here. My work for this article was reading the architecture, fallback and provider references at commit bc4c8f0. I did not install OpenShell, test an escape or validate the hardware reference architecture.
The practical takeaway is modest: the enforced boundary is a composition of runtime isolation, selected policy, provider rules and privileged operations. The quickstart command is only the entrance. ✅
References
- NVIDIA AI's October 21 announcement.
- Pinned OpenShell architecture.
- Pinned default-policy reference.
- Pinned provider reference.
Asset credit: original explanatory diagram; documentation by NVIDIA, Apache-2.0.
AI disclosure
AI was used to draft the article.
Top comments (0)