英伟达开源的OpenShell，我把一个会“越权”的Agent关了进去，看它多久被拦下来

一个能读你SSH密钥、翻你.env文件、还能偷偷往外发HTTP请求的编程Agent，你每天都在让它跑。

大多数人装完Claude Code就直接用，默认权限等于把电脑钥匙交出去。Agent不会恶意搞你，但它“理解错了任务”的时候，后果跟恶意一样。

NVIDIA上周开源了一个东西叫OpenShell，9月28日上线，三天冲到12.6K Star。Apache 2.0协议，我当天就拉了源码在本地跑起来。这篇写几个真实踩坑。

Docker容器装Agent，跟没装差不多

先说一个容易混淆的地方。

很多人觉得“我Agent跑在Docker容器里，已经隔离了”。Docker的隔离是namespace层面的——它让进程看到独立的文件系统、网络栈、PID空间。听起来够了。

问题是Docker容器里的进程默认以root身份运行，能读容器里挂载的任何东西。你把项目目录挂进去，Agent就能读写整个项目。你挂了SSH密钥方便Git操作，Agent也能读。

OpenShell的隔离在Linux内核层，用的是Landlock LSM加seccomp过滤器。文件系统策略把路径分成read_only和read_write两个列表，没列进去的路径完全不可访问。进程层面用非特权用户sandbox运行，root身份直接被拒绝。网络层面默认全拒，每个出站请求都要过L7代理，代理同时检查目标主机和发起请求的二进制程序。

我实测的时候写了一个Python脚本，让Agent在沙箱里执行它。脚本尝试读取 /etc/shadow ——返回Permission denied。尝试 curl 一个未授权的域名——连接直接被代理切断，日志里记录了一条 enforcement: deny 。跟Docker里跑同一个脚本完全不是一个结果。

这还不算完。NVIDIA还配了一个叫Sentry的硬件看门狗，跑在BlueField-4 DPU上，独立于Agent所在的主机监控行为。如果Agent试图越界，Sentry能在毫秒级把它隔离。这个需要额外硬件，不是所有人都用得上，但方向很明确：安全检查不能放在被检查对象的控制范围内。

安装确实只有两行命令，但有个前提

官方文档给的安装命令就一条：

“curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh”

装完之后创建第一个沙箱：

“openshell sandbox create -- claude”

两行命令，Claude Code就在沙箱里跑起来了。

但这里有个前提容易被忽略：你的机器上得有Docker。 OpenShell底层把K3s Kubernetes集群封装在一个Docker容器里，网关和沙箱都跑在这上面。你不需要单独学Kubernetes，也不需要配kubectl，但Docker得先装好。

我在MacBook Pro M3上跑的，安装脚本自动识别系统装了CLI和网关。

openshell sandbox create -- claude之后，Claude Code在沙箱里启动，终端弹出一个认证链接，浏览器打开登录Anthropic账号，回来就能用了。

第一次创建沙箱的时候会自动provision一个网关，大概等了十几秒。后续再创建就快了。

策略配置：默认全拒，放行得逐条加

OpenShell的策略文件是YAML格式，分两块：静态和动态。

静态部分在创建沙箱时锁定，包括 filesystem_policy（文件系统读写规则）、landlock （内核强制级别）、process（运行身份）。动态部分是 network_policies ，可以在沙箱运行中热加载更新，不用重启。

默认策略只允许read-only访问，网络请求全部拒绝。我一开始让Claude Code在沙箱里改一个文件，被拒了。得先 /sandbox 把目录加进 read_write 列表。

网络策略的写法是这样的：

“network_policies:
my_api:
name: my-api
endpoints:
- host: api.example.com
port: 443
protocol: rest
enforcement: enforce
access: full
binaries:
- path: /usr/bin/curl”

只有endpoint和binaries同时匹配，连接才放行。

我让Claude Code往GitHub推代码，默认策略直接拒了push。按官方教程的流程，需要用 openshell provider create 注入GitHub token，然后写一条针对特定仓库的write策略。整个过程是“失败→诊断→改策略→重试”的循环。

这里有一个设计细节我觉得挺聪明：静态策略改不了，必须销毁沙箱重建。这防止了Agent在运行时偷偷给自己开权限。动态的网络策略可以热加载，改完立即生效，日志里能看到 policy updated 记录。

123次越权测试：默认策略一次没漏

我最关心的就是它到底能不能拦住越权。

OffSeq做了一组预注册的实测，用了123次试验，在Apple Silicon Mac上跑OpenShell v0.1.2。结论是：默认策略下没有任何绕过。恶意脚本在没有OpenShell的情况下10次全部泄露了秘密数据，在OpenShell默认策略下10次全部被拦截。

但实测也暴露了问题。

同一个测试发现，如果你手动开了read-write权限，或者用了auto-approval模式，数据是可以出去的。具体来说，有四个设置会导致泄漏：read-write规则、GET-only规则里的query/header值、audit-mode规则、以及自动审批机制。

说白了，默认策略是安全的，但你自己改的策略可能把门开太大了。

我自己的测试验证了这一点。我在策略里给GitHub加了full access，Claude Code就能正常push代码。但我如果把access改成full的同时又忘了限制binaries，理论上沙箱里任何进程都能走这条通道。

我试了三次才把策略写对。第一次binary路径写错了，Agent调不到curl。第二次忘了加 protocol: rest ，HTTPS请求被代理拒了。第三次才对。

国内用的几个实际问题

网络。安装脚本从GitHub拉，国内可能需要代理。如果你有稳定的GitHub访问方案，问题不大。OpenShell本身不需要访问外部服务——它是本地运行时，不依赖NVIDIA的云。

性能。我测下来工具调用的额外延迟在1-5ms级别。有报告显示启动开销大约增加30%，命令执行开销增加50%。这在交互式编程场景里基本感觉不到，但如果跑批处理任务，累计开销需要考虑。

版本状态。当前是v0.1.2，alpha阶段。已经发现了几个CVE，包括CVE-2026-44113的TOCTOU竞争条件漏洞和CVE-2026-41355的任意代码执行漏洞。官方明确标注了“Expect rough edges and breaking changes”。生产环境部署前建议评估风险，开发环境用没问题。

至于“没有Kubernetes经验能不能搞定”——能。K3s被封装在Docker里了，你日常操作只用 openshell sandbox 系列的CLI命令，不碰kubectl。但如果你想把它部署到已有的K8s集群上，那就得懂K8s。

值不值得装

如果你每天用Claude Code或Codex跑代码，而且这些Agent有权限访问你的真实项目目录，那OpenShell值得花半小时装一下。

它解决的不是“Agent会不会变坏”的问题。它解决的是“Agent理解错了任务，把不该删的文件删了，把不该发的API key发出去了”的问题。这类事故在Docker容器里照样发生。

安装两行命令，创建沙箱一行命令，默认策略已经够安全。你不需要一上来就写复杂的策略文件，先用默认的跑，遇到拒绝再按日志放行。

现在的版本还不够成熟，别在核心生产流水线上用。但如果你有一个“怕它乱来”的Agent任务——比如让它自动改代码、自动部署、自动处理敏感数据——把它关进OpenShell里跑，比裸奔强太多。

英伟达把Agent安全当成基础设施来做，这个方向是对的。Agent不能自己管自己，边界必须由外部来设。OpenShell就是这个边界的一种实现，开源的，你可以自己审查代码。