An AI agent can have a read-only API rule and still send a request that breaks it. Superpower Daily’s bounded review of NVIDIA OpenShell 0.1.0 documentation finds that preventing disallowed HTTP writes requires request inspection and enforcement, not just the read-only label. This was a public-document review, not a runtime test or an audit of a deployed sandbox.
Three settings, three different jobs
OpenShell’s Network Rules guide describes two stages. First, it checks whether the destination host, port and connecting executable match an allowed rule. Without a match, it denies the connection before the API request. A successful connection check establishes permission to reach the service; request inspection supplies the separate check on what the client sends.
The protocol setting selects that inspection. For an HTTP API, protocol: rest enables checks on the request’s method, path and query parameters. Leaving protocol out applies no request rules and allows any HTTP method and path, subject to separate safety checks. The Policy Schema Reference says access and rules have no effect without protocol. The tcp protocol likewise supplies no request rules and rejects request-control fields such as access.
Next comes access. On an inspected REST endpoint, access: read-only permits GET, HEAD and OPTIONS. POST, PUT, PATCH and DELETE fall outside that preset. An operator needing finer restrictions can use explicit method-and-path rules instead, but an endpoint cannot combine those allow rules with an access preset.
The third setting, enforcement, determines what happens to a violation. Its default is audit: OpenShell logs a request that breaks the endpoint’s allow or deny rules and forwards it. Setting enforcement: enforce blocks the request instead; an HTTP client receives an OpenShell policy_denied response. NVIDIA recommends using audit to understand traffic, then switching to enforce after validating the rules. Audit does not disable every check: malformed requests and requests addressed to another host are still rejected.
The examples supply the missing switch
All five selected REST read-only configurations explicitly specify enforce: GitHub, PyPI, npm and an internal API in the network-rules guide, plus the first-network-policy tutorial. The sample counts configurations, not individual hosts; PyPI includes two download destinations. These examples illustrate preventive settings without changing the schema’s audit default.
network_policies:
github_api:
endpoints:
- host: api.github.com
port: 443
protocol: rest
enforcement: enforce
access: read-only
binaries:
- path: /usr/bin/curlThe npm example shows a practical cost of restricting methods. npm sends its security audit as a POST, which the read-only preset denies. NVIDIA offers two choices: run npm install --no-audit, or replace the preset with explicit rules that also permit the audit’s POST requests. The decision is whether to change the client’s workflow or widen the permitted requests.
One narrow rule is not the whole boundary
OpenShell’s rules are not an ordered firewall list. Matching rules contribute the access they allow, while a matching deny takes precedence. A second inspected rule can therefore add permission beyond a narrow read-only rule. If an inspected and uninspected rule match the same connection, however, inspection remains active and the uninspected rule adds no request access. Overlapping inspected endpoints that can match the same request must agree on enforcement.
Creating a sandbox without --policy does not establish that the restrictive default is active: a global, saved or image policy can supply its rules. The default policy itself defines no network access, but attached providers can contribute rules to the effective policy. NVIDIA’s Default Policy reference provides commands for inspecting the base and effective versions.
The executable entry deserves equal attention. OpenShell uses the real path of the executable opening the connection, rather than necessarily the command a person typed. A pip rule must identify the Python interpreter. A rule can also authorize processes launched by a listed executable; any Python program in the sandbox can use the PyPI example’s interpreter-based permission.
Network permission and credential permission remain separate. Allowing a destination does not authorize OpenShell to send a provider’s credentials there. That requires an approved provider-profile destination or an explicit credential binding. A failed credential check calls for correcting that binding, not automatically broadening network access.
Method and limits
This review compared OpenShell 0.1.0’s default-policy, network-rules, schema, security-guidance and tutorial documentation. The five-example count is a selected sample, not a documentation-wide survey. No runtime test or deployment audit was performed.
Reader comments
Newest comments first. Replies stay oldest first.