网心技术 | NemoClaw 深度解析，企业级 AI 运行时

NVIDIA 在 GTC 2026 上发布的 NemoClaw不是又一个 AI 框架而是 Agent 时代缺失的那块“操作系统级安全基座”。本文将从源码出发拆解它的本质、架构与设计哲学。引言Agent 越强企业越怕2026 年AI Agent 彻底出圈。从技术大佬到创业玩家从美国硅谷到深圳龙岗人人都在拥抱 Agent 浪潮。OpenClaw 以超过 33万 GitHub 星标的速度成为有史以来增长最快的开源项目NVIDIA CEO 黄仁勋在 GTC 2026 上直言Mac 和 Windows 是个人电脑的操作系统而 OpenClaw 则是个人 AI 的操作系统。但这句话的背后藏着一个巨大的隐患 ——操作系统意味着 Agent 拥有和人类一样的系统控制权。正如《网心技术 | AI Agent 上岗从能用 → 敢用》一文提到 OpenClaw 能根据你的需求自行搭建环境、写代码、做测试、交付结果。从这个视角理解Agent 至少具备了以下核心能力但能力越强边界越模糊权限越大风险也就越显性。正是在这样的背景下NVIDIA 在 GTC 2026 上发布了NemoClaw——一个给 AI Agent 的企业级运行时。本文将从源码级别深度拆解 NemoClaw 到底是什么、解决什么问题、如何解决以及它的未来走向。NemoClaw 到底是什么NemoClaw 是 NVIDIA 开源的、企业级 OpenClaw 安全运行环境参考方案Reference Stack。用更通俗的话说NemoClaw OpenShell 安全沙箱运行时 Nemotron 开源模型 声明式安全策略 一条命令搞定一切的 CLI。它不是一个 AI 框架不是一个模型更不是 Agent 的替代品。它是 Agent 的运行环境Runtime Environment就像 Docker 是应用的运行环境、JVM 是 Java 的运行环境一样。从 NemoClaw 项目的 README.md 的第一行就能看出它的定位NVIDIA NemoClaw: Reference Stack for Running OpenClaw in OpenShell这里有三个关键词需要拆解✅Reference StackNemoClaw 不是一个最终产品而是一个参考实现。它展示了如何正确地、安全地运行 AI Agent的最佳实践。企业可以直接使用它也可以基于它二次开发自己的 Agent 运行环境。这个定位非常重要 —— 它意味着 NemoClaw 的价值不在于代码本身而在于它定义了一种模式和标准。✅OpenClawOpenClaw 是当前最流行的开源 AI Agent 平台由 Peter Steinberger 创建。它本质上是一个会用电脑的 AI 助手拥有技能系统Skills、通道系统Channels、工作流Workflows等完整的 Agent 基础设施。但它本身没有安全沙箱而是直接运行在操作系统上拥有和你一样的全部权限。✅OpenShellOpenShell 是 NVIDIA Agent Toolkit 的一部分是一个安全运行时。它利用 Linux 内核的 Landlock LSM、seccomp BPF 和网络命名空间namespace等技术在操作系统层面为 Agent 提供沙箱隔离。OpenShell 才是 NemoClaw 的核心引擎NemoClaw 是 OpenShell 在 OpenClaw 场景下的开箱即用封装。我们用一张图来表达它们的关系为什么需要 NemoClaw要理解 NemoClaw 为何诞生必须先回顾 2026 年初 AI 安全领域的几起标志性事件。⚠️ ClawHavoc2026 年 1 月底至 2 月安全公司 Koi Security 在 ClawHubOpenClaw 的官方技能市场中发现了一场名为 ClawHavoc 的大规模供应链攻击1,184 个恶意 Skills 被注入 ClawHub单个攻击者 hightower6eu 上传了 354 个恶意包另一个 sakaen736jih 提交了 199 个频率高达每分钟一个 —— 明显是自动化操作所有恶意 Skill 使用同一套手法伪装成前置安装步骤静默部署 Atomic macOS Stealer (AMOS)窃取密码、浏览器 Cookie、加密钱包和 macOS 钥匙串数据截至 2 月 16 日恶意 Skill 数量已增长到 824 个占整个生态约 20%更触目惊心的是安全研究人员发现超过 135,000 个暴露在公网上的 OpenClaw 实例使用了不安全的默认配置其中超过 12,800 个可直接被远程代码执行漏洞利用大量 API 密钥、聊天记录和账户凭证在裸奔。⚠️ CVE 漏洞群除了供应链攻击OpenClaw 本身也暴露出一系列严重漏洞工信部 NVDB 发布的安全预警更是直接指出ClawHub 中 36.8% 的 Skill 至少存在一项安全漏洞。⚠️ MCP 协议的安全困境MCPModel Context Protocol本是 AI Agent 的USB-C 标准接口但安全设计的缺失使其成为新的攻击面。数据显示部署 10 个 MCP 插件的被利用概率达 92%3 个互连服务器的风险即超 50%数百个 MCP 服务器在公网裸奔且无认证这些事件揭示了一个根本性的矛盾Agent 的核心价值自主执行能力恰恰是安全风险的根源。引用微软在 2026 年 2 月 19 日发布的安全指南OpenClaw 应被视为不可信代码执行环境且拥有持久化凭证。建议完全隔离 —— 专用虚拟机、非特权凭证、仅访问非敏感数据。但“专用虚拟机”的方案在企业大规模部署时成本极高操作复杂。企业需要的是一种既能保持 Agent 生产力、又能系统性控制风险的解决方案—— 这就是 NemoClaw 诞生的直接原因。NemoClaw 的核心架构从源码分析NemoClaw 的架构可以清晰地分为四个层次第一层CLI Plugin命令行插件层目录结构来自 docs/reference/architecture.md ​​​​​​​这一层使用 TypeScript 编写是用户与 NemoClaw 交互的入口。设计原则是 Thin Plugin轻量插件 —— 它只负责用户交互和命令分发不包含核心编排逻辑。从 index.ts 中可以看到插件启动时做三件事注册 /nemoclaw 命令支持 status、eject、onboard 子命令注册 NVIDIA 推理提供者Inference Provider打印配置 Banner显示当前 Endpoint、Provider 和 Modelexport default function register(api: OpenClawPluginApi): void {// 1. Register /nemoclaw slash command (chat interface)api.registerCommand({name: nemoclaw,description: NemoClaw sandbox management (status, eject).,acceptsArgs: true,handler: (ctx) handleSlashCommand(ctx, api),});// 2. Register nvidia-nim provider — use onboard config if availableconst onboardCfg loadOnboardConfig();api.registerProvider(registeredProviderForConfig(onboardCfg, providerCredentialEnv));第二层Blueprint蓝图编排层Blueprint 是 NemoClaw 架构中最精妙的设计之一。它包含所有沙箱创建、策略应用和推理配置的逻辑。目录结构nemoclaw-blueprint/├── blueprint.yaml 清单 — 版本、配置档案、兼容性约束├── orchestrator/│ └── runner.py CLI 执行器 — plan / apply / status / rollback├── policies/│ ├── openclaw-sandbox.yaml 默认网络 文件系统策略│ └── presets/ 预置策略Slack、Jira、PyPI、Docker Hub 等blueprint.yaml 定义了整个部署的元数据​​​​​​​Blueprint 生命周期遵循五个阶段Resolve解析 → Verify验证摘要 → Plan规划 → Apply应用 → Status报告这种设计模式借鉴了 Plan/Apply 模型 —— 先声明目标状态再计算差异最后执行变更。这确保了部署的可预测性和可重复性。从runner.py的 action_apply函数可以看到实际执行步骤​​​​​​​def action_apply(profile, blueprint, ...):# Step 1: 创建 OpenShell 沙箱run_cmd([openshell, sandbox, create, --from, sandbox_image, ...])# Step 2: 配置推理提供者run_cmd([openshell, provider, create, --name, provider_name, ...])# Step 3: 设置推理路由run_cmd([openshell, inference, set, --provider, provider_name, ...])# Step 4: 保存运行状态(state_dir / plan.json).write_text(json.dumps({...}))为什么要把 Plugin 和 Blueprint 分开源码中的设计原则写得很清楚Plugin 保持轻量和稳定。编排逻辑存在于 Blueprint 中可以独立发布和演进。这样就可以保证安全策略的更新不需要升级整个 NemoClaw只需要更新 Blueprint 即可 —— 对于企业安全运维来说这个设计很关键。第三层OpenShell Sandbox安全沙箱层这是 NemoClaw 的安全核心。OpenShell 是一个独立的开源项目它提供了操作系统级别的 Agent 隔离能力。从 Dockerfile 中可以看到沙箱镜像的构建过程​​​​​​​# 创建沙箱用户匹配 OpenShell 约定RUN groupadd -r sandbox useradd -r -g sandbox -d /sandbox -s /bin/bash sandbox# 将 .openclaw 分为不可变配置目录 可写状态目录# Landlock 策略将 /sandbox/.openclaw 设为只读Agent 无法# 修改 openclaw.json、认证令牌或 CORS 设置RUN mkdir -p /sandbox/.openclaw-data/agents/main/agent \ ln -s /sandbox/.openclaw-data/agents /sandbox/.openclaw/agents \...# 锁定 openclaw.jsonchown 给 rootsandbox 用户无法运行时修改USER rootRUN chown root:root /sandbox/.openclaw \ chmod 444 /sandbox/.openclaw/openclaw.jsonUSER sandboxOpenShell 沙箱提供了四层保护从默认安全策略文件 openclaw-sandbox.yaml 中可以看到具体的安全规则​​​​​​​注意 binaries 字段 —— 这意味着即使网络白名单放行了某个域名也只有指定的二进制文件才能访问。比如integrate.api.nvidia.com只允许 openclaw 进程访问沙箱内的其他进程无法连接。这种细粒度的控制提供了强有力的安全保障。第四层Inference Routing推理路由层推理路由是 NemoClaw 解决隐私与推理能力矛盾的关键设计。核心原则Agent 的推理请求永远不会直接离开沙箱。Agent (沙箱内) ──▶ OpenShell Gateway ──▶ NVIDIA Endpoint (build.nvidia.com)当 Agent 需要调用大模型时它以为自己在调用 https://inference.local/v1 —— 这实际上是沙箱内的一个虚拟域名。OpenShell Gateway 拦截这个请求在沙箱外部将其路由到真正的推理后端NVIDIA API、本地 vLLM、Ollama 等。从 Dockerfile 中的配置生成逻辑可以看到这一机制​​​​​​​​​​​​​​这个设计有三个关键好处API Key 不进沙箱推理服务的真实 API Key 存储在 OpenShell Gateway 层沙箱内的 Agent 无法获取模型可热切换运维可以在不重启沙箱的情况下切换推理后端隐私路由器Gateway 可以在将请求转发到外部 API 之前对敏感字段进行脱敏处理NemoClaw 当前支持多种推理配置档案源码深度走读从 nemoclaw onboard 到沙箱运行让我们沿着一条完整的用户旅程从源码层面跟踪 NemoClaw 的全部工作流程。✅安装阶段用户执行install.sh 执行以下步骤检测环境确认 Node.js 20、容器运行时Docker/Colima/Docker Desktop安装 OpenShell调用 scripts/install-openshell.sh 安装 openshell CLI安装 NemoClaw通过 npm install -g nemoclaw 全局安装安装完成后运行 nemoclaw onboard 进入引导式向导。✅Onboard 阶段nemoclaw onboard 触发 Blueprint 生命周期Step 1: Resolve解析Plugin从OCI注册表(ghcr.io/nvidia/nemoclaw-blueprint)下载 Blueprint检查版本兼容性Step 2: Verify验证校验 Blueprint 工件的摘要digest确保供应链安全 —— 防止下载到被篡改的 Blueprint。Step 3: Plan规划runner.py的action_plan函数分析当前环境生成部署计划​​​​​​​​​​​​​​值得注意的是 validate_endpoint_url 函数实现了 SSRF 防护​​​​​​​def validate_endpoint_url(url):# 只允许 http/httpsif parsed.scheme not in (https, http):raise ValueError(...)# DNS 解析并检查是否为私有地址addr_infos socket.getaddrinfo(hostname, None, protosocket.IPPROTO_TCP)for _, _, _, _, sockaddr in addr_infos:if is_private_ip(str(sockaddr[0])):raise ValueError(Connections to internal networks are not allowed.)这个细节体现了 NemoClaw 团队的安全意识 —— 即使是在内部工具中也防范了 SSRF服务端请求伪造攻击。攻击者无法通过提供一个解析到内网 IP 的域名来访问内部服务。Step 4: Apply应用执行实际部署操作创建沙箱、配置推理提供者、设置推理路由。Step 5: Status报告确认部署状态生成总结信息。✅Docker 镜像构建nemoclaw onboard使用 Dockerfile 构建沙箱镜像。这个过程包含几个安全关键步骤多阶段构建Stage 1 编译 TypeScript 插件Stage 2 只包含运行时依赖安全敏感环境变量处理不可变配置openclaw.json 在构建时生成运行时通过 DAC自主访问控制锁定为 root 所有 只读每次构建唯一认证令牌secrets.token_hex(32) 确保每个镜像有唯一令牌✅沙箱启动scripts/nemoclaw-start.sh 是沙箱的入口脚本写入认证配置auth-profiles.json启动 OpenClaw Gatewayopenclaw gateway run启动自动配对 Watcher监听浏览器连接请求并自动批准打印 Dashboard URL包含 auth token✅运行时连接用户执行 nemoclaw my-assistant connect 进入沙箱交互式 Shell然后openclaw tui启动交互式聊天界面openclaw agent --agent main --local -m hello发送消息给 Agent此时Agent 运行在沙箱内部所有操作都受安全策略约束。安全设计哲学为什么是进程外强制执行NemoClaw / OpenShell 的安全设计遵循一个核心原则这也是它与其他方案最本质的区别✅进程外强制执行传统的 Agent 安全方案通常采用进程内方式 —— 在 Agent 代码中嵌入安全检查、权限控制、审计日志等。但这种方式有一个致命缺陷如果攻击者获得了 Agent 进程内的任意代码执行权所有安全控制都形同虚设。ClawHavoc 事件完美证明了这一点 —— 恶意 Skill 在 Agent 进程内执行拥有和 Agent 一样的全部权限。OpenShell 采用了完全不同的思路安全层运行在完全独立的进程中在操作系统层面强制执行。即使 Agent 进程被完全攻陷 —— 攻击者在沙箱内拥有任意代码执行能力 —— 也无法修改约束自己的策略因为策略引擎位于不同的信任边界。用一个类比来理解✅ 默认拒绝从安全策略文件可以看到NemoClaw 遵循默认拒绝一切显式允许所需的原则网络默认拒绝所有出站连接只允许白名单中的域名和端口文件系统默认只读只有 /sandbox 和 /tmp进程默认非 root禁止提权当 Agent 试图访问未在白名单中的网络时请求被阻止并在 TUI 中通知运维人员进行实时审批。这实现了一种Human-in-the-Loop的安全模式。✅ 不可变基础设施NemoClaw 沙箱采用了不可变基础设施的理念核心配置文件openclaw.json构建时生成运行时只读Agent 的可写状态与不可变配置通过符号链接分离每次部署从相同的 Blueprint 重新创建沙箱确保可重复性✅ 对应前文博客的安全四层框架如果将 NemoClaw 的安全能力映射到企业 Agent 安全的四层框架可以说NemoClaw 是前文博客所描述的Agent 安全运行环境理念的一个具体工程实现。它把应该怎么做变成了一条命令就能做到。与现有方案的对比Docker Sandboxes、VM 隔离等NemoClaw 并非唯一的 Agent 安全方案。让我们对比几种主流选择✅原生 Docker 隔离Docker 提供了容器级别的隔离但Docker 的网络隔离是全有或全无 —— 要么能访问网络要么不能。缺乏细粒度的域名级白名单没有内置的推理路由 —— API Key 必须传入容器没有运维实时审批机制容器逃逸仍是已知攻击面✅Docker Desktop 的 NanoClaw 沙箱Docker 为 NanoClawOpenClaw 的某精简版提供了沙箱支持使用 microVM 隔离microVM 比容器更安全硬件级隔离但只支持 NanoClaw不支持完整的 OpenClaw缺乏声明式策略系统没有推理路由和隐私保护✅虚拟机VM隔离微软建议的方案 —— 专用 VM隔离最彻底但成本高、部署复杂、不适合大规模没有标准化的策略管理缺乏 Agent 专属的安全原语推理路由、网络审批等✅NemoClaw 与其他方案的差异化NemoClaw 的核心差异在于它不只是隔离Agent而是理解 Agent 的行为模式针对 Agent 的特定需求推理调用、工具执行、网络访问设计了专属的安全原语。NemoClaw 的未来从 OpenClaw 专属到通用 Agent 安全层✅当前状态NemoClaw 于 2026 年 3 月 16 日在 GTC 上发布目前处于 Alpha 早期预览 阶段官方明确标注此软件尚未达到生产就绪状态。接口、API 和行为可能在没有通知的情况下发生变化。从源码版本号 0.1.0 也能看出这一点。NemoClaw 的核心代码库并不庞大 —— 几千行 TypeScript Python主要工作由底层的 OpenShell 承担。✅已知局限未经独立安全审计对于一个以安全为核心价值的产品缺乏第三方审计是最大的风险Linux 优先macOS 上的 Podman 尚不支持Windows 依赖 WSL可观测性不足行业分析师指出生产环境还需要更完善的可观测性、回滚和审计追踪能力仅支持 OpenClaw当前版本针对 OpenClaw 设计不支持其他 Agent 框架✅OpenShell 的 Agent 无关性NemoClaw 背后的OpenShell 运行时本身是 Agent 无关的。OpenShell 的文档明确指出它可以运行任何 Agent —— Claude Code、Codex、LangChain 自定义 Agent 等。NemoClaw 只是 OpenShell 在 OpenClaw 场景下的第一个参考实现。这意味着 NVIDIA 的长期战略很可能是​​​​​​​✅NVIDIA 的战略意图黄仁勋在 GTC 上说过一句意味深长的话NemoClaw 是免费的 —— 产品是平台。这句话揭示了 NVIDIA 的真实战略NemoClaw 不是要卖软件而是要定义 Agent 时代的基础设施标准。就像 CUDA 定义了 GPU 计算标准一样NVIDIA 希望 OpenShell 成为 Agent 安全运行时的事实标准。从商业角度看这个逻辑很清晰免费的 NemoClaw 推动 Agent 大规模安全部署Agent 需要推理能力 → 推动 NVIDIA GPU 和 Nemotron 模型的需求企业需要更强的推理性能 → 推动 DGX Spark、DGX Station 等硬件销售Agent 运行时标准化 → 锁定生态位构建护城河✅行业影响与未来方向NemoClaw 的出现标志着一个重要的行业趋势Agent 安全正在从附加功能变成基础设施。就像 Web 应用需要 HTTPS、容器化应用需要 Kubernetes 一样Agent 应用将需要专属的安全运行时。而这个运行时需要解决的核心问题包括沙箱隔离Agent 不能无限制地访问宿主机资源网络控制Agent 的出站连接必须可审计、可控制推理隐私企业数据不能无保护地发送到外部 API策略管理安全规则必须是声明式的、可版本化的、可审计的操作员控制人类必须保留对 Agent 行为的最终控制权NemoClaw 目前只覆盖了这些问题的基础部分但它的架构设计为未来的扩展留下了充足的空间。未来可能的演进方向包括多 Agent 编排的安全协调当多个 Agent 需要协作时如何管理它们之间的信任关系和权限传递策略即代码Policy as Code的深化与 GitOps 工作流集成实现安全策略的版本控制和自动化部署AI 驱动的异常检测用 AI 来监控 Agent 行为识别异常模式合规性框架集成与 SOC 2、ISO 27001 等企业合规框架对接跨 Agent 框架支持从 OpenClaw 扩展到 Claude Code、Codex、自定义 Agent 等实战体验从零到安全运行的全流程为了让读者更直观地理解 NemoClaw 的工作方式让我们走一遍完整的实战流程。✅ 环境准备NemoClaw 的硬件要求并不苛刻沙箱镜像压缩后约 2.4 GB。在镜像推送过程中Docker 守护进程、k3s 和 OpenShell 网关会同时运行如果内存不足 8 GB可能触发 OOM Killer。配置 8 GB 交换空间可以缓解此问题。软件依赖LinuxUbuntu 22.04或 macOSApple Silicon需 Colima 或 Docker DesktopNode.js 20容器运行时Docker、Colima 或 Docker DesktopOpenShell由安装脚本自动安装对于 NVIDIA DGX Spark 用户项目提供了专门的 spark-install.md 指南涵盖 cgroup v2 和 Docker 配置等 Spark 特有的前置条件。✅ 一键安装与引导安装过程简化到了极致curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash安装脚本会自动完成三个步骤检测并安装 Node.js如未安装安装 OpenShell 运行时运行引导式向导配置沙箱名称、推理提供者、API Key 等安装完成后终端会显示一个总结这里的Landlock seccomp netns标识直接告诉你沙箱启用了哪些内核级安全机制。✅ 沙箱内的日常交互连接到沙箱后你进入的是一个受限的 Linux 环境。在这个环境中你可以正常使用 openclaw tui 或 CLI 与 Agent 对话Agent 可以执行开发任务、写代码、运行测试但 Agent 的所有网络访问都受策略控制文件写入只能在 /sandbox 和 /tmp 目录当 Agent 尝试访问白名单以外的网络端点时运维人员会在 OpenShell TUI通过 openshell term 启动中收到实时审批请求。这种按需审批的模式在实际使用中非常实用 —— 你不需要预先知道 Agent 需要访问哪些服务只需在它请求时做出判断。✅ 策略定制NemoClaw 预置了多种策略文件覆盖常见的企业集成场景你可以将这些预置策略组合使用构建适合自己企业的 Agent 安全配置。例如一个内部开发 Agent 可能只需要 PyPI npm GitHub 策略一个客服 Agent 可能需要 Slack Jira Outlook 策略。策略可以通过两种方式应用静态方式编辑 openclaw-sandbox.yaml 后重新运行 nemoclaw onboard动态方式运行 openshell policy set policy-file 在运行中的沙箱上临时应用✅ 卸载与清理NemoClaw 提供了干净的卸载方式curl -fsSL https://raw.githubusercontent.com/NVIDIA/NemoClaw/refs/heads/main/uninstall.sh | bash卸载脚本会移除沙箱、NemoClaw 网关提供者、相关 Docker 镜像和容器、本地状态目录以及全局 npm 包。但不会移除 Docker、Node.js、npm 或 Ollama 等共享系统工具。结语Agent 时代的安全范式转移回到最初的问题NemoClaw 到底是什么从软件角度NemoClaw 是一个轻量级的参考方案由一个 TypeScript CLI 插件和一个 Python Blueprint 编排器组成核心安全能力由底层的 OpenShell 运行时提供。它的代码量不大但它定义的模式意义深远。从问题角度NemoClaw 解决的是 Agent 时代最根本的信任问题 —— 当 AI Agent 拥有和人类一样的系统控制权时如何确保它即便出错也不失控。从方案角度NemoClaw 给出了一个工程上可行的答案操作系统级沙箱隔离而非进程内安全检查声明式安全策略而非手动配置防火墙规则推理隐私路由而非将 API Key 暴露给 Agent操作员实时控制而非事后审计一条命令部署而非复杂的手动安全加固NemoClaw 当前还处于 Alpha 阶段距离生产就绪还有不少路要走。但它代表了一种重要的范式转移从信任 Agent 不会犯错到假设 Agent 必然被攻陷确保攻陷后损失可控。这就像 Web 安全从信任输入演进到永不信任输入的零信任范式一样Agent 安全也需要同样的思维转变。NVIDIA 选择在这个时间点推出 NemoClaw并将其完全开源、芯片无关是一步深思熟虑的战略棋。它不仅是对 ClawHavoc 事件的回应更是在定义一个新的基础设施品类 ——Agent 安全运行时。就像黄仁勋说的Claude Code 和 OpenClaw 点燃了 Agent 拐点 —— 将 AI 从生成和推理延伸到行动。而 NemoClaw则是确保这些行动不会失控的那道安全闸门。参考资料https://github.com/NVIDIA/NemoClawhttps://nvidianews.nvidia.com/news/nvidia-announces-nemoclawhttps://www.nvidia.com/en-us/ai/nemoclaw/https://developer.nvidia.com/blog/run-autonomous-self-evolving-agents-more-safely-with-nvidia-openshell/https://github.com/NVIDIA/OpenShellhttps://docs.nvidia.com/nemoclaw/latest/reference/architecture.htmlhttps://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184-malicious-skills/https://thenextweb.com/news/nvidia-nemoclaw-openclaw-enterprise-securityhttps://earezki.com/ai-news/2026-03-19-nvidia-openshell-and-the-rise-of-agent-sandboxes-in-agentic-devops/https://www.cio.com/article/4146545/nvidia-nemoclaw-promises-to-run-openclaw-agents-securely.html