How NVIDIA OpenShell Handles Network Access

This article is translated by AI, if have any corrections please let me know.

Over the weekend I spent some time reading how NVIDIA’s newly released OpenShell achieves network security for its Sandbox. The Managed Agents offered by Anthropic and OpenAI have similar features, but their source code isn’t available, so all we can do is guess which techniques they might use.

What surprised me is that the OpenShell documentation lets you ask an AI questions. Without reading the source code, I was able to verify my assumptions quickly and get a rough idea of how it currently solves the Credentials problem.

Opaque Credentials

Most AI applications may go through the cloud, which means data that can authenticate an identity, such as an API Key, must never be reachable by the Agent. Even putting it in environment variables is dangerous. But for the goal of being AI Native, this is a serious obstacle to autonomy, so making credentials “Opaque” is important.

OpenShell’s approach didn’t surprise me much; what matters is how carefully it is handled. In terms of opaque credentials alone, it is similar to how I handle it in Kobako, where I provide a mechanism similar to Handle inside the sandbox. What you see inside is some kind of “Placeholder” that is only converted back to the original content after leaving the sandbox, so at most the Agent sees a string like <apiKey:1> and never knows the original value.

The conversion is handled centrally by the Supervisor, a service running outside the sandbox, and all traffic is routed to this service. The sandbox itself has its network removed (the Container has networking turned off, the Virtual Machine has no network device), and then the Linux Kernel’s seccomp intercepts TCP connections and DNS queries and forwards them to the Supervisor, so nothing slips through.

This technique has a limitation, though. It only works at L7 (Layer 7, the application layer), meaning opaque credentials are only usable for things like HTTP requests. If you want to handle L4 (Layer 4, the transport layer), you are limited, which is an expected limitation.

Networking

Since we can intercept traffic, why can we only handle L7 and not L4? The reason is simple: L4 is TCP and UDP, and we have no way of knowing what protocol the user is speaking. Inspecting every packet to find and replace the matching placeholder could seriously slow things down and has a higher error rate.

L7, on the other hand, is relatively simple. We only need to handle HTTP requests, and most credentials live in places like the query string and headers. We just need to provide an HTTP Proxy service to replace them quickly. This also explains why remote access on Claude and ChatGPT is controlled by allowing specific Domains. Basically, inside these sandboxes, the only viable way to carry credentials is an HTTP request.

So is L4 itself safe? OpenShell also handles many common security problems, such as connecting to the local network. For example, say I want to escape the servers the sandbox lets me connect to. I first send ARP requests across every IP range in the local network to find reachable devices, and then I only need to find some vulnerability to break through the restriction.

That’s why OpenShell blocks requests to local network addresses like 10.x and 192.168.x by default, so they can’t be sent in the first place. Since it can restrict where requests go, the ability to configure allowed_ips follows naturally, which ensures the Agent inside the sandbox can only send requests to allowed locations.

Besides that, I think its defense against DNS attacks is the cleverest part. Suppose the Agent finds an https://hacker.com/api endpoint online and wants to call it, but this endpoint secretly changes where its DNS resolves to (a DNS Rebinding attack). The Agent may then mistakenly send requests to the local network or to the wrong server, which is risky.

Since the IP ranges used by local networks are unusable anyway, OpenShell makes good use of them to strengthen protection. When it intercepts a query, it answers with its own DNS server and remembers both the resolved address and a private address. For example, when blog.aotoki.me resolves to 172.67.195.165, the sandbox gets 172.31.1.64, and the Supervisor records sandbox:1,172.67.195.165,172.31.1.64 as the mapping (illustrative). When the Agent connects to 172.31.1.64, the connection is intercepted and relayed by the Supervisor. As long as the Supervisor itself isn’t affected by this kind of attack, the network security of every sandbox is guaranteed.

This kind of handling is very detailed, but it is also something we rarely think through carefully in ordinary situations. I think it’s well worth spending more time studying, and the official documentation lets you discuss it directly with AI.

Plans for Kobako

The reason I looked into OpenShell’s mechanisms is that I’m currently developing Filesystem support for Kobako. Once that’s done, I’ll move on to the Networking feature. Adding networking on top of a Filesystem isn’t hard; what’s really hard are the mechanisms OpenShell has designed.

If you look closely at OpenShell’s defenses and approach, it feels quite “heavy,” requiring DNS and Proxy servers. I think it suits larger-scale deployments, and it also needs a dedicated service like the Supervisor to be present. For small projects, or Homelab hobbyists like me, it’s not really worth it.

Kobako takes a different route: an environment as lightweight and minimal as possible. That’s also why only being able to run mruby by default is a big limitation. For scenarios like running a Coding Agent, you still have to go back to relying on a container environment. But for other kinds of tasks that need simple memory and API calling, these lightweight constraints turn out to be surprisingly useful.

I think “how to run Agents safely” will be one of next year’s main themes. This is no longer just a Harness problem; it has expanded into an environment problem. If the environment is hostile or poorly protected, things will eventually become hard to control.

As for what role a sandbox like Kobako, which bets on WebAssembly, should play, that’s still well worth thinking about.