Basic idea
OpenClaw is a local-first AI agent that runs on your machine, combining memory, file access, tool use, and community skills into a persistent assistant. Running it directly on your system means the agent can access your files, credentials, and network—creating real security risks.
NVIDIA OpenShell solves this problem. It is an open-source sandbox runtime that wraps the agent in kernel-level isolation with declarative YAML policies. OpenShell controls what the agent can read on disk, which network endpoints it can reach, and what privileges it has—without disabling the capabilities that make the agent useful.
By combining OpenClaw with OpenShell on DGX Station (with NVIDIA GB300 GPUs), you get the full power of a local AI agent backed by GPU memory for local models, while enforcing explicit controls over filesystem access, network egress, and credential handling.
Notice & Disclaimers
Quick Start Safety Check
Use a clean environment only. Run this playbook on a fresh device or VM with no personal data, confidential information, or sensitive credentials. Think of it like a sandbox—keep it isolated.
By installing this playbook, you're taking responsibility for all third-party components, including reviewing their licenses, terms, and security posture. Read and accept before you install or use.
What You're Getting
The playbook showcases experimental AI agent capabilities. Even with cutting-edge open-source tools like OpenShell in your toolkit, you need to layer in proper security measures for your specific threat model.
Key Risks with AI Agents
Be mindful of these risks with AI agents:
- Data leakage – Any materials the agent accesses could be exposed, leaked, or stolen.
- Malicious code execution – The agent or its connected tools could expose your system to malicious code or cyber-attacks.
- Unintended actions – The agent might modify or delete files, send messages, or access services without explicit approval.
- Prompt injection & manipulation – External inputs or connected content could hijack the agent's behavior in unexpected ways.
Security Best Practices
No system is perfect, but these practices help keep your information and systems safe:
- Isolate your environment – Run on a clean PC or isolated virtual machine. Only provision the specific data you want the agent to access.
- Never use real accounts – Don't connect personal, confidential, or production accounts. Create dedicated test accounts with minimal permissions.
- Vet your skills/plugins – Only enable skills from trusted sources that have been vetted by the community.
- Lock down access – Ensure your OpenClaw UI or messaging channels aren't accessible over the network without proper authentication.
- Restrict network access – Where feasible, limit the agent's internet connectivity.
- Clean up after yourself – When you're done, remove OpenClaw and revoke all credentials, API keys, and account access you granted.
What you'll accomplish
You will install the OpenShell CLI (openshell), deploy a gateway on your DGX Station, and launch OpenClaw inside a sandboxed environment using the pre-built OpenClaw community sandbox. The sandbox enforces filesystem, network, and process isolation by default. You will also configure local inference routing so OpenClaw uses a model running on your DGX Station via vLLM (NVIDIA NGC container on the host) without needing external API keys.
Popular use cases
- Secure agent experimentation: Test OpenClaw skills and integrations without exposing your main filesystem or credentials to the agent.
- Private enterprise development: Route all inference to a local model on DGX Station. No data leaves the machine unless you explicitly allow it in the policy.
- Auditable agent access: Version-control the policy YAML alongside your project. Review exactly what the agent can reach before granting access.
- Iterative policy tuning: Monitor denied connections in real time with
openshell term, then hot-reload updated policies without recreating the sandbox.
What to know before starting
- Comfort with the Linux terminal and SSH
- Basic understanding of Docker (OpenShell runs a k3s cluster inside Docker)
- Familiarity with Docker and local LLM serving (vLLM in this playbook)
- Awareness of the security model: OpenShell reduces risk through isolation but cannot eliminate all risk. Review the OpenShell overview and OpenClaw security guidance.
Prerequisites
Hardware Requirements:
- NVIDIA DGX Station with GB300 GPU(s)
- Sufficient GPU memory for your chosen model: we recommend Nemotron 3 Super in NVFP4 (
nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4) served by vLLM on GB300; smaller GPUs can use other Hugging Face models—check nvidia-smi and model requirements
Software Requirements:
- DGX OS or Ubuntu 24.04 (or compatible Linux)
- Docker Desktop or Docker Engine running:
docker info
- Python 3.12 or later:
python3 --version
uv package manager: uv --version (install with curl -LsSf https://astral.sh/uv/install.sh | sh)- NVIDIA Container Toolkit (for GPU-enabled Docker): configured per
instructions.md
- Network access to download Python packages from PyPI, the NGC vLLM image, and model weights from Hugging Face
Time & risk
- Estimated time: 20–30 minutes (plus model download time, which depends on model size and network speed).
- Risk level: Low to Medium
- OpenShell sandboxes enforce kernel-level isolation, significantly reducing the risk compared to running OpenClaw directly on the host.
- The sandbox default policy denies all outbound traffic not explicitly allowed. Misconfigured policies may block legitimate agent traffic; use
openshell logs to diagnose.
- Large model downloads may fail on unstable networks.
- Rollback: Delete the sandbox with
openshell sandbox delete dgx-demo (or your sandbox name), stop the gateway with openshell gateway stop, and optionally destroy it with openshell gateway destroy. Stop and remove the vLLM container and delete Hugging Face cache directories if you want to reclaim disk space (see instructions.md cleanup).
- Last Updated: 03/13/2026
