OpenShell 深度拆解：英伟达如何用 Landlock 双边界给 AI Agent 防泄密

让 AI Agent 拥有执行 Shell 的权限，已经成为不少开发者的日常操作。

但真正把终端交出去那一刻，心里免不了犯嘀咕：放开权限，怕它遭遇 Prompt 注入 或恶意依赖投毒，把私有代码和本地密钥打包外泄；关死网络和文件，它连拉取文档、安装依赖都做不到，瞬间变成废铁。

这种“要么裸奔、要么坐牢”的局面，正是自主 Agent 走向生产环境的最大阻碍。NVIDIA 开源的 OpenShell，要解决的就是这个死结。

项目卡片

• 项目：OpenShell[1]
• 状态：v0.1.2 / 1.4 万+ Stars / 采用 Apache-2.0 协议
• 一句话判断：用 Linux 内核 Landlock、形式化验证与双边界凭据隔离，给自主 AI Agent 构建了一个既能自由执行代码又绝不失控的运行时沙箱。

关在容器里，为什么依然防不住它失控

不少人觉得，开一个普通 Docker 容器把 Agent 圈起来就够了。

但在真实工程里，普通容器防不住隐蔽外泄。只要容器还能连外网，一段混淆脚本就能把挂载的源码打包，伪装成正常的 HTTPS 请求送出去。

OpenShell 的解法是物理分离的双边界：不可信的 Sandbox 与完全受信任的 Supervisor。

Agent 运行在 Sandbox 内部，从启动起就受到 Linux 内核的多重约束：Landlock LSM 严格封锁文件读写路径，无特权身份杜绝提权；seccomp 在底层拦截危险系统调用。

更彻底的是，Sandbox 在网络层被执行全默认拒绝（Default-Deny），它根本没有直连外部互联网的网卡。

它唯一的出路，是一条通往外部 Supervisor 的私有受控信道：Docker 下是 Unix Socket，K8s 下是 mTLS 服务，MicroVM 下是 vsock。所有 TCP 连接与 DNS 解析，都必须经过 Supervisor 逐一审查，沙箱自己说了不算。

报错了怎么办？它用形式化证明做动态放行

网络全关虽然安全，但 Agent 干活时难免要访问 GitHub API，或者拉取依赖包。每次拦截都靠人工改配置，自动化基本就名存实亡了。

为此，OpenShell 引入了运行时提单机制 Policy Advisor。

当请求被内核阻断时，系统会自动提取程序路径、目标域名与端口，在沙箱内部暴露的本地接口 http://policy.local 上生成一份最小权限提案（Proposal）。

接着，网关内嵌的 Policy Prover 会介入。它基于 SMT 数学求解器做形式化推演，秒级排查几条关键红线：

• 是否尝试触碰云厂商核心元数据节点，例如 169.254.169.254
• 是否试图用 Git、SSH 等无法做深度 L7 审计的协议，连接附带凭证的主机
• 是否把已有凭证扩展到了未经授权的新域名
• 是否在只读端点上偷偷放开了 POST、PUT 等写入动作

确认没有越权风险后，系统在自动模式下可以无感放行，或者由开发者在终端里敲下 openshell rule approve 批准。规则通过后会动态热重载（Hot-Reload）地生效，容器无需重启，请求立刻畅通。

连 API Key 都不给 Agent，它怎么干活

让 Agent 调用模型，一直是密钥泄露的高发区。传统做法是往容器里塞环境变量，Agent 一旦打印环境变量或输出报错堆栈，密钥就会直接暴露。

OpenShell 实现的是凭据零暴露注入。

真实密钥由沙箱外部的 Provider Profiles 统一托管在宿主安全存储中。沙箱内部的 Agent 只能看到不透明的占位符，根本接触不到真实凭证。

完整调用链很简洁：

1. Agent 正常发起针对目标 API 的 HTTP 请求
2. 内核拦截并转交给宿主侧 Supervisor
3. Supervisor 依据策略校验二进制程序与端点白名单
4. Supervisor 在向外转发的瞬间，即时把真实的 Authorization 请求头拼入数据包

哪怕 Agent 被提示词注入攻击，或被恶意脚本全盘扫描，也拿不到任何有效密钥。钥匙始终在门外的守卫手里。

开发者上手也很简单，本地网关拉起后，一条命令就能带着免费模型开工：

# 导入模型提供商配置并创建 Provider
openshell profile import --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create --name openrouter --type openrouter --from-existing

# 启动受控 Agent 沙箱
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

实测用官方脚本安装网关不到一分钟，配合 OpenCode 镜像，终端交互几乎感受不到代理拦截带来的延迟。

哪些场景该用，哪些坑现在别踩

在自主 Agent 遍地开花的当下，OpenShell 给出了一个相对成熟的工程底座。

如果你符合以下任一场景，它的采用价值会很高：

• 常驻后台执行的 Coding Agent：需要自主拉库、改代码、提 PR，无法预知会执行哪些外部脚本
• 多 Agent 协作集群：企业并发运行几十个 Agent，必须保证沙箱之间以及与内网设施的完全隔离
• 敏感业务对接：需要严格的凭证管控与合规审计，原生支持 OCSF 安全日志导出

不过选型前也要看清它当前的边界。

首先，隔离边界存在时序限制。Landlock 的文件读写白名单与进程 UID/GID 必须在创建沙箱时就定死，启动后不可更改；只有网络规则和中间件支持运行时热更新。

其次，形式化验证目前主要覆盖 L4 TCP 与 RESTful。对于复杂的 WebSocket、GraphQL 或自定义 MCP 工具协议，Prover 还无法建立完整的数学模型来证明风险，仍然需要依赖人工静态声明。

最后是系统依赖。它深度依赖现代 Linux 内核的 Landlock 与 seccomp。Linux 与 Apple Silicon Mac 配合 Docker/Podman 体验极佳，Windows 目前仍处于 WSL 2 实验性阶段。

在给自主 Agent 放开系统权限之前，先在底层筑一道由内核和数学逻辑双重锁死的硬防线，远比事后排查密钥泄露省心得多。这类 Agent 安全与沙箱隔离的新方案，也值得在 云栈社区 继续跟踪讨论。

引用链接

[1] OpenShell: https://github.com/NVIDIA/OpenShell