Securing Autonomous Agents: Policies, Networks, and Access Controls | Nemotron Labs

In last week’s livestream we covered getting started with NVIDIA NemoClaw for building long-running agents—and the most common question by far was: "How do I actually control what my agent can do?" Before we can answer that, it helps to know which layer of the stack is doing what — because NemoClaw, OpenShell, and OpenClaw each contribute a distinct piece of the picture, and that distinction matters when you're configuring security. This session cuts through the confusion and goes hands-on with NVIDIA OpenShell's policy system as it operates inside a NemoClaw deployment. What you'll learn: - What each layer actually does — OpenClaw is the agent, OpenShell is the runtime that enforces sandbox boundaries (network, filesystem, process) out-of-process so policies hold even if the model misbehaves, and NemoClaw is the distribution that wires them together with onboarding, inference routing, and the hardened blueprint that ships your policy YAML. - How to read, write, and apply OpenShell network policies — walk through the deny-by-default model, how to allow specific hosts and API paths per binary, how unlisted destinations get surfaced to the operator in real time for approval, and how to hot-reload a policy mid-session without restarting the sandbox. - How to configure filesystem and process restrictions — understand capability drops, the least-privilege Dockerfile, and blueprint digest verification so you have a reproducible, auditable baseline and know exactly what your agent can and can't touch on the host. Join us live, bring your questions about securing agents, and follow along as we walk through securing an agent deployment together in real time.