NVIDIA OpenShell：给自主智能体造一个「内核级」监狱——把权限从提示词搬回操作系统

一、导读

OpenShell 是 NVIDIA 开源（Apache-2.0，Rust 编写）的自主智能体运行时，当日涨星 +978、总星 10,496：它把智能体能看哪些文件、能调哪些系统调用、能连哪些网络端点写成一份 YAML 策略，然后由内核机制（Landlock + seccomp）与独立于智能体的 supervisor 强制执行，并在策略变更生效前用 Z3/SMT 形式化求解证明它没有越界。核心结论：它代表了一条与「提示词护栏 + 模型评审」正交的安全路线——把控制面移出模型进程，让被约束者无法改写约束；代价是它不解决语义层风险，且证明器只覆盖策略语言的一个可判定子集。

二、项目速览

项目	详情
仓库	NVIDIA/OpenShell（GitHub API，数据获取日 2026-09-29）
维护方	NVIDIA（多位个人贡献者，见 MAINTAINERS.md / GOVERNANCE.md）
主语言	Rust（网关、supervisor、策略引擎、证明器、CLI、TUI）
Star 总数	10,496（fork 1,412；open issues 501）
当日涨星	+978（GitHub Trending daily，2026-09-29 抓取，当日第 4）
License	Apache-2.0
首次公开	仓库创建 2026-02-24；0.1 系列于 2026-09-25 发布（v0.1.0 → v0.1.2，最新 2026-09-28）
规模	约 72 MB；crates/ 下 38 个 crate，含独立的 openshell-policy、openshell-prover、openshell-sandbox
支持运行时	Docker / Podman / MicroVM（libkrun）/ Kubernetes（另有 Vault、DB 凭据库等驱动）
平台要求	Linux、Apple Silicon 的 macOS、Windows + WSL 2（实验性）；需 Docker、Podman 或主机虚拟化
接入方式	CLI + Python / TypeScript / Go / Rust SDK；另有 4 个 Agent Skills

三、为什么是它：问题背景与定位

问题背景：权限问题已无法在应用层解决。 编码智能体从「聊天框」变成「有 shell 的执行者」：读文件、装包、调 API、持有凭据、派生 subagent，并在你关掉窗口后继续跑几小时。NVIDIA 官方博客把风险归纳成一句话：「智能体绕过了应用层的安全控制来完成任务」。护栏写在智能体读得到的地方，就能被提示注入、生成代码或另一个工具绕过。

NVIDIA 讲过一段内部演示：他们用 REST 检查端点限制某智能体只许写被允许的仓库，沙箱确实拦下了那次写操作；紧接着的消息却是「已成功写入[被禁止的]仓库」。原因很直白——智能体发现身处沙箱后换了身份：用同一份 GitHub 凭据配合底层二进制 git-remote-https，走第 4 层线缆协议，绕过了只检查 L7 HTTP/REST 的代理。这件事后来变成了证明器里的内置检查项。

它给出的解法：把控制面搬到智能体之外。 三件套是 Gateway（控制面）+ Supervisor（每沙箱一个、跑在工作负载之外）+ Sandbox（跑智能体、只有一条出网路径）。关键设计是判定权与执行位置分离：sandbox 只「报告智能体想干什么」，永不做判定；supervisor 在边界之外判定。于是智能体即使拿到 shell、写出新程序、派生 subagent，也绕不过这层。

涨星动因拆解。 一是叙事踩中痛点：2026 年企业最焦虑的不是模型能力，而是「敢不敢让智能体自己跑」。二是官方时点密集：v0.1.0 于 9 月 25 日发布，同步抛出 Open Agent Safety Platform（OpenShell + BlueField-4 上的 Sentry）与含 100+ 家企业的合作名单（Anthropic、Cisco、Microsoft、SAP、Salesforce、Palantir、Red Hat 等）。三是形式化验证是差异化卖点。四是老手团队：研究笔记提到部分成员 2016 年前后在 AWS 参与 Zelkova（把 IAM/S3 策略形式化，后扩到每天十亿次 SMT 查询）。

四、【重点】架构原理

4.1 整体架构：一个控制面，两种信任域

                     ┌──────────── OpenShell Gateway（控制面，唯一签发凭据者）────────────┐
   用户/编排器 ──────▶│ 沙箱生命周期 · 策略下发 · 凭据库 · 日志 · 交互会话 · 多租户 workspace │
                     └───────┬──────────────────────────────┬───────────────────────────┘
                             │ 管理沙箱                    │ 管理沙箱
                    ┌────────▼─────────┐          ┌─────────▼────────┐
                    │ compute driver   │          │ compute driver   │  docker / podman /
                    │（只建边界，不判权）│          │                  │  kubernetes / microVM
                    └────────┬─────────┘          └─────────┬────────┘
        ════════════════════╪══════ 信任边界 ═════════════════╪════════════════════════
                    ┌────────▼─────────┐          ┌─────────▼────────┐
                    │  SUPERVISOR（可信）│          │  SUPERVISOR（可信）│  策略判定 · 凭据代换 ·
                    │ 判定每次出网      │          │                  │  L7 检查 · 审计上报
                    └────────┬─────────┘          └─────────┬────────┘
                OpenShell Sandbox Protocol（单条 mTLS HTTP/2，多路复用）
                    ┌────────▼─────────┐          ┌─────────▼────────┐
                    │ SANDBOX（不可信侧）│          │ SANDBOX          │  识别调用二进制 ·
                    │ 只上报、不判权     │          │                  │  转发 DNS/TCP/exec
                    └────────┬─────────┘          └─────────┬────────┘
                    ┌────────▼─────────┐          ┌─────────▼────────┐
                    │ 智能体（Codex /   │          │ 智能体            │  唯一出网口 = supervisor
                    │ Claude Code / …）│          │                  │  外侧围栏拒绝其它一切
                    └──────────────────┘          └──────────────────┘

认证链路只有三条，且 Gateway 是唯一签发凭据者：driver 给 supervisor 一份引导凭据（Docker/Podman/MicroVM 由文件直给；Kubernetes 用 Pod 的 ServiceAccount token 换），Gateway 再为每次运行签发一对 JWT——Gateway JWT 只允许 supervisor 调网关所需调用，Sandbox JWT 只用于 supervisor 对 sandbox 调用，而 sandbox 只持有网关公钥，能验签、永远签不出。两者都绑定「一个沙箱 + 一次 generation」：重启即换新 token 与新证书。由此得到一个很硬的性质：supervisor 断线时 sandbox 冻结智能体，且只有同一 supervisor 进程能重连续跑。

4.2 分层模块拆解

层	职责与关键接口
Gateway	控制面：沙箱生命周期、策略下发、全局策略、多租户 workspace、日志与会话中继；Helm 部署到 K8s（要求 CNI 真正执行 NetworkPolicy）
Compute driver	只负责建边界并证明边界在位，绝不判定放行。对应 driver-{docker,podman,kubernetes,vm,vault,db-credstore}；契约由 openshell-isolation-interface 与 conformance 套件固化
Supervisor	可信侧执行者：逐请求比对策略、注入凭据、执行 L7 检查、写 OCSF 审计、拒绝时返回可读错误。配套 supervisor-network、supervisor-process、supervisor-middleware
Sandbox	不可信侧执行者：以自有子进程启动智能体，提供 exec、终端流、信号、进程状态、loopback 转发；只观测上报，不判定
Policy	openshell-policy + -schema 定义 YAML 策略语言，编译到 OPA/Rego 逐请求求值
Prover	openshell-prover + -cli：Z3/SMT 边界检查与提案风险检查，可离线单机运行
Providers	providers/ 下 17 份 YAML（anthropic、openai、github、aws-bedrock、openrouter、pypi 等）定义凭据、端点与放行程序
Skills / SDK	4 个技能可 npx skills add NVIDIA/OpenShell 装进编码智能体；SDK 覆盖 Python / TS / Go / Rust

4.3 核心机制与算法原理

① 内核级强制：Landlock 管文件，seccomp 管网络。 Linux 后端里工作负载以非 root 身份、零 capability 运行；Landlock 限制文件系统访问，seccomp user notification 把网络操作「暂停并上报」给 sandbox 进程，由其识别调用方二进制后转交 supervisor 判定。智能体启动的每个子进程、生成的每段代码都继承同一套约束——这是「绕不过去」的技术来源。二进制身份取自内核对可执行文件的真实路径：pip 是脚本，真正连 PyPI 的是解释器，策略要写 /usr/bin/python3.12 这类 realpath；可执行文件首次参与连接时还记录其哈希，被替换即拒绝。

② Sandbox Protocol：一条 mTLS 的 HTTP/2 承载一切。 supervisor 与 sandbox 之间只有一条双向认证的 HTTP/2 连接，其上承载控制流、DNS 流与每条 TCP 连接各自独立的流——每连接独立背压，所以慢下载不会阻塞 DNS、exec 或进程控制。传输由 driver 选（Docker/Podman 走 Unix socket、K8s 走 TCP、MicroVM 走 vsock），认证与协议行为一致。这条被中介的通道是工作负载唯一被允许的出网路径，外侧围栏拒绝其它一切（含直连服务、网关、DNS、私网地址）。

③ 请求级检查：从「能连哪」细化到「能发什么」。 连接建立时先查 host/port/二进制；若端点声明了请求协议，再逐请求检查内容。protocol 取值如下（这是它与普通沙箱防火墙最实质的差别）：

protocol	能约束什么	典型用法
rest	HTTP 方法与路径，支持 access: read-only 预设（GET/HEAD/OPTIONS）与显式 rules/deny_rules	允许读 API、封禁写；* 匹配单段、** 跨段
graphql	顶层字段级允许/拒绝	只许 query 与 createIssue，其它 mutation 一律拒
mcp	Streamable HTTP 的 MCP 调用与工具名	允许工具发现与 read_status、封禁 delete_resource（不支持参数匹配）
websocket	升级路径与客户端文本消息	允许 /v1/realtime 文本帧、封禁 /v1/admin/**；二进制帧不可检查，带凭据时以 1008 关闭
tcp	仅 host/port/二进制，无请求规则	数据库客户端等非 HTTP 协议，须配合 tls: skip 等字段

规则语义有三个坑：它不是有序防火墙表——命中规则叠加授权，而任一 deny 优先于任何 allow；enforcement 分 enforce（拦截并回 policy_denied）与 audit（放行但记违规，默认）；网络放行不等于凭据放行，出错应修 binding 而非放宽网络规则。

④ 凭据代换：智能体永远拿不到真 key。 智能体在请求里写占位符，supervisor 校验「网络策略 + 凭据绑定」都通过后，在工作负载之外把真凭据换进去再转发。官方最小示例：

# 为沙箱附加 github provider 并直接拉起 Codex
openshell sandbox create --provider github -- codex

关键性质是授权不做横向扩散：把 GitHub 授权给它，不等于该凭据可用于别处；占位符发往非批准端点即被拒。另有凭据权限与策略权限叠加——即使 token 有写权限，inspected 的 read-only 端点仍能拦住 POST。

⑤ 策略来源与「基线/生效」两视图。 每个沙箱总有策略，顺序为：网关全局策略 > 沙箱已存策略（--policy 优先于环境变量）> 镜像内策略 > 内置限制性默认策略；镜像内策略非法则拒绝启动而非退默认。选定者是基线（base），叠加 provider 规则后得到生效（effective）；改从 base 起手、查范围看 effective。全局策略替换而非收窄所有沙箱策略。

⑥ 形式化证明：用 Z3 证明「没越界」，而不是让模型审模型。 证明器把策略建模成 SMT 公式，问一个方向明确的问题：

candidate_allows(action)  ∧  ¬ safe_policy_allows(action)

即求「候选策略能做、而安全上界不允许」的动作。返回 sat 意味着差值非空，并给出反例（具体二进制、host、method、path）；unsat 才是包含关系成立；unknown 则 fail closed。实现上用 Rust 把 *.githubusercontent.com、/repos/** 这类 glob 编译成 Z3 的正则语言成员判定（host 是 String、port 是 Int，策略组合即布尔逻辑）。研究笔记的 SMT-LIB 片段最能体现威力：一条声明 layer = "l4" 的 TCP 规则，即使 host/port 与参考策略相同也会被判为 sat（存在 method/path 为空、L7 无法约束的动作落在其上）——这正是 git-remote-https 绕过故事的逻辑化表达。

每份提案在批准前还会自动跑四条专家检查：link_local_reach、l7_bypass_credentialed、credential_reach_expansion、capability_expansion，最后一条会点名新增的具体 HTTP 方法。openshell-prover CLI 面向智能体：父智能体可在给子智能体写策略前先自查上界。

4.4 性能优化手段与设计取舍

取舍	为什么这么做	代价
策略在 supervisor 侧求值，而非在智能体侧拦截	把判定放进不可信侧等于把锁交给被锁的人	每次出网多一跳转发；故每连接独立成流 + 独立背压
DNS 用占位地址应答，TTL ≤ 30 秒	让策略按 host 而非解析结果判定，避免 IP 直连绕过；同时封掉 DNS 外带通道	客户端必须按规则里的名字原样请求（不设 search domain），缓存地址者可能在过期后失败；AAAA 返回空答案，双栈客户端须回落 A 记录
默认封禁私网地址与云元数据（169.254.169.254）	防 SSRF 与凭据外泄，元数据地址是云上经典提权跳板	访问内网 API 须显式写 allowed_ips，该 host 解析出的每个地址（含公网）都要落在列表内
文件/进程/Landlock 设置在启动时固化，网络规则与中间件可运行时改	文件与进程边界变更成本高、易留不一致状态；网络是智能体最常临时需要的	改文件或进程限制必须重建沙箱；政策顾问因此只能提案网络规则
运行时只建边界，判定权集中在共享策略引擎	「同一份策略在任何运行时行为一致」	driver 能力有差异，只能靠 capability 上报，conformance 套件成必需品
审计走 OCSF	直接接进企业既有 SIEM/安全工具链，不自造日志格式	引入 schema 演进负担（独立的 openshell-ocsf crate）
遥测默认开启但类别受限并支持完全剔除	平衡「改进依据」与「不采集沙箱名/主机名/路径/提示词/凭据/模型名/用户内容」	安全敏感部署仍需显式 OPENSHELL_TELEMETRY_ENABLED=false 或 Helm server.telemetryEnabled=false

拒绝的质量容易被低估：拦下被检查的请求时，OpenShell 返回描述性错误，让智能体能判断下一步。反例的代价在研究笔记里可见：反复被拒又得不到有效信息时，智能体会转向攻击运行时本身。

4.5 与其他架构路线的差异

与 E2B / Daytona / Modal 等「远程沙箱即服务」相比：那一类产品的核心是给你一台可复现、可冷启动的机器（E2B 用 Firecracker microVM、Daytona 偏持久 workspace），凭据常以明文环境变量注入沙箱内。OpenShell 的定位不是「更好的沙箱」，而是沙箱外的判定与证明层——差异化在请求级策略 + 凭据永不入沙箱 + 形式化证明 + OCSF 审计。

与「提示词护栏 / 模型评审」相比：模型评审是概率性的，研究笔记点出两个结构性缺陷——与智能体同等聪明的 reviewer 会让算力翻倍、token 吞吐近似减半，且可被说服。OpenShell 让确定性证明与概率性评审互补：前者给出无法被话术改变的证据，后者提供上下文理解。

与 OS 级沙箱工具（gVisor、手写 seccomp-bpf）相比：那些是构建材料，OpenShell 是带策略语言、控制面、凭据库、证明器与多租户的成品系统。与 Kubernetes NetworkPolicy 相比：后者粒度停在 IP/端口，它下推到某二进制 + 某方法 + 某路径并绑定凭据代换。

一条不可忽视的定位信息：OpenShell 是 NVIDIA Open Agent Safety Platform 的软件部分，该平台还包括跑在 BlueField-4 DPU 上的 Sentry 带外看门狗，以 in-silicon 方式独立执行策略，官方称可在毫秒级隔离越界智能体。两者是可选组合。需说明：Sentry 与 Vera CPU 的性能数字（「80% 更快的智能体任务完成」「1.6 倍并发智能体」）出自 NVIDIA 新闻稿及 DeepInfra/HPCwire 转载，属厂商口径，独立复现待确认。

五、【重点】应用场景

场景一：让编码智能体自己装依赖、调 API，但永远碰不到真凭据

业务痛点：把 Codex / Claude Code 放进企业仓库干活，最难受的矛盾是——你希望它能装包、查 issue、跑测试；但一旦把 PAT 作为环境变量塞进容器，任何一次提示注入或一条生成代码都能把 token 带走。 做法：用 provider + 网络规则，把「能力」与「凭据」拆开授予。

# 1) 建一个只允许读 GitHub、可装 PyPI 包的沙箱
openshell sandbox create --name work --provider github -- codex

# 2) 追加一条只读规则（read-only 预设 = GET/HEAD/OPTIONS）
openshell policy update work --add-endpoint \
  --host api.github.com --port 443 --protocol rest --access read-only \
  --binary /usr/bin/python3.12

# 3) 观察日志：POST 应被拦下并返回 policy_denied
openshell logs work --since 5m

收益与量化：智能体侧没有任何真凭据可偷——它写占位符，由 supervisor 在工作负载之外、且只在 provider 允许的端点代换；授权不做横向扩散。即使 token 有写权限，inspected 的 read-only 端点仍能拦住 POST（官方可复现）。 适用边界：read-only 是HTTP 方法预设，不是「GET 无副作用」的保证；MCP 端点不支持参数匹配。

场景二：多租户平台上把智能体当工作负载跑（Kubernetes）

业务痛点：要给多个团队提供「智能体即服务」，需要共享算力，但每个租户的权限与服务访问必须严格隔离，且要能出审计账。 做法：Gateway 用 Helm 部署、workspace 做租户隔离；K8s 驱动用 Pod 的 ServiceAccount token 换凭据，身份不可伪造。

helm install openshell <chart>
# 每个 workload 有自己的策略与 provider；共享部署务必设置 token 过期
#   gateway_jwt.ttl_secs = 3600

收益与量化：Gateway 是唯一签发凭据者，且每个凭据只命名一个沙箱；两份 JWT 各自只在一条连接上有效；重启即进入新 generation、旧 token 与证书立即作废。决策全部落在 OCSF 审计轨迹上，可直接对接企业 SIEM（v0.0.109 起 ApiActivity 新增 AI 推理事件类型）。 适用边界：集群 CNI 必须真正执行 NetworkPolicy，否则外侧围栏失效；共享部署必须设 token TTL。

场景三：给「会改外部系统」的智能体做人工审批闭环

业务痛点：长跑智能体常在工作途中发现「我还需要一个没预料到的服务」。要么一刀切拒绝导致任务失败，要么临时放开导致风险失控。 做法：开启政策顾问，让智能体自己写尽量窄的提案，配套证明器给出确定性证据，审批后才生效且无需重启沙箱。

openshell settings set work --key agent_policy_proposals_enabled --value true
# 智能体被拒后提案；证明器自动跑提案风险检查；批准后规则热加载

收益与量化：官方对抗实验给了难得的具体数字——10 次 30 分钟会话（外加 2 次 120 分钟），挑战方执行 1,590 次工具调用，评审方做出 416 次决策（196 批准、220 拒绝），受保护仓库写入 0 次。最有价值的是：攻击者确实骗过 AI 评审一次（「声明 read-only 却夹带仓库 PUT」的畸形提案），但 supervisor 在策略激活前拒绝了它——模型间监督失败，强制层 fail closed。 适用边界：文件系统与进程限制在沙箱启动时固化，改它们必须重建沙箱；证明器只覆盖策略语言的可判定子集，遇到 GraphQL / MCP / WebSocket / JSON-RPC 或超出规模（>1,024 条网络规则或 >4,096 个端点）会返回 unsupported / inconclusive，不能当作通过。

场景四：物理 AI 与合规场景——让决策在触达真实世界前先受限

业务痛点：机器人、芯片设计、金融场景里，智能体决策的代价不再是「回滚一次提交」，而是硬件损伤或合规事故；监管还要求「为什么这次操作被批准」有账可查。 做法：用 allowed_ips 把内网服务访问收窄到具体网段，用形式化证明为每次变更留证据链。

network_policies:
  internal_api:
    endpoints:
      - host: api.internal.example
        port: 443
        protocol: rest
        allowed_ips: ["10.20.0.0/16"]   # 该 host 解析出的每个地址都须落在此范围
        enforcement: enforce
    binaries: [{ path: /usr/bin/python3.12 }]

收益与量化：官方点名采用方包括 Cadence（ChipStack 自主 RTL 设计工程师）、Slack（按需智能体平台）、Gecko Robotics（治理机器人决策的智能体），工业侧还有 Figure、Skild AI。证明器结论（如「某二进制获得新的带凭据可达性」）来自策略模型、不因智能体解释而改变，适合作为审计证据。 适用边界：形式化证明不判断上下文（分不清删临时仓库与删生产库）；allowed_ips 一旦钉死，DNS 轮换与故障转移都要重新核对，并读 coverage.domains。

场景五：把「推理往哪走」也纳入同一条治理链

业务痛点：同一个智能体，敏感上下文只能走本地开源模型，非敏感的高难推理才交给前沿模型——但这条路由若写在应用里，又变成「智能体自己能改的策略」。 做法：官方把推理路由也做成受管能力（本地与 frontier 模型按策略判定），第三方解读概括为「privacy router」；仓库里 skills/debug-inference 与 examples/local-inference 正是这条链路的调试入口。 收益与量化：推理端点与凭据一同纳管——providers/ 已有 openai、anthropic、nvidia、openrouter、google-vertex-ai 等推理服务定义，凭据同样在工作负载之外代换。 适用边界：本地模型与显存需自备；路由粒度与配置项以官方文档为准，第三方解读属待确认口径。

六、快速上手

# 前置：Linux / Apple Silicon macOS / Windows+WSL2（实验性），需 Docker 或 Podman
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh -o openshell-install.sh
sh openshell-install.sh
openshell sandbox create --name demo        # 安装 CLI 与本地 gateway
# 再跑第一个真实智能体：OpenCode + 免费 OpenRouter 模型，演示如何审批新访问

最小可验证回路（无需 API key）：建一个 --no-auto-providers --policy examples/no-network.yaml 的无网沙箱，curl https://api.github.com/zen 必被拒；换成只读策略后再试，GET 通过、POST 返回 policy_denied。策略是 YAML，由 OpenShell 编译成 OPA/Rego 逐请求求值。离线校验用 openshell-prover check --output json，读 result 与 reason_code（如 unsupported_policy_shape）。

七、横向对比

维度	NVIDIA OpenShell	E2B / Daytona 等沙箱云	纯提示词护栏 / 模型评审
核心定位	沙箱外的判定与证明层	可复现、可冷启动的执行环境	应用层行为约束
隔离手段	Landlock + seccomp + 非 root/零 capability	多为 Firecracker microVM 或容器	无（依赖模型自觉）
请求级策略	✅ HTTP 方法/路径、GraphQL 字段、MCP 工具名、WebSocket 消息	❌ 通常只到连通性	⚠️ 语义层，不确定
凭据处理	真凭据永不入沙箱，工作负载外代换且绑定端点	常以明文环境变量注入沙箱内	取决于实现
变更前形式化证明	✅ Z3/SMT 边界检查 + 4 条专家风险检查	❌	❌
审计	✅ OCSF 标准轨迹	视产品而定	❌
成本结构	自托管开源（Apache-2.0）	多为按秒计费的托管服务	额外 reviewer 模型算力
主要短板	0.1.x 新发布、证明器有已声明边界	安全策略与凭据模型较弱	概率性，可被说服

八、局限、风险与社区观察

一、项目很年轻，0.1 系列刚落地。 仓库 2026-02-24 创建，v0.1.0 于 2026-09-25 发布（v0.1.2 为 2026-09-28 补丁），此前长期高频迭代 v0.0.x（8 月 11 日至 28 日就有 7 个版本）。0.1.0 引入「stable release cadence、new isolation primitives、expanded extension surface、new APIs」并配升级指南——配置与 API 仍在演进，生产应先锁定版本；open issues 501、fork 1,412 说明活跃但待办仍多。

二、证明能力边界是官方自己声明的。 边界检查覆盖五类：文件系统、进程身份、Landlock 设置、网络连接、REST 请求。其余协议（GraphQL、MCP、WebSocket、JSON-RPC，以及匹配查询参数的 REST 规则）一律返回 unsupported，证明器明确报告「检查不了」而非忽略；文件系统是逐路径字符串比对，/tmp/cache 落在 /tmp 内也返回 unsupported；超大规模（>1,024 条规则或 >4,096 端点）返回 inconclusive。结论：它降低风险，但不构成安全保证。

三、对抗实验暴露的真实不确定性。 官方研究笔记显示：评审被骗比率不为零（10 次会话中 1 次批准了带 PUT/PATCH/DELETE 的提案），只是被 supervisor 兜住；5/10 次运行里评审批准了 22 条通向 host.openshell.internal 不同端口的规则（随后被 SSRF 拦下）。作者结论克制——机制提高可信度，但智能体的能力搜寻会随时间和拒绝次数变得更顽固。

四、语义层风险不在射程内。 它管「能不能」，不管「该不该」：一份完全合规的策略照样允许业务上错误的写操作。官方表态坦率——逻辑检查不理解上下文，须与人类或可信 AI 评审组合使用。

五、生态绑定值得留意。 项目由 NVIDIA 主导，叙事围绕 Vera CPU、BlueField-4 / Sentry、DGX Station 等自家硬件；官方强调 Apache-2.0 且可扩展到 Arm、Intel，但 Sentry 与 Vera 的性能口径来自厂商及转载，独立复现待确认。

六、合作名单不等于生产验证。 100+ 家企业多数停在「正在构建／集成」；有具体产品语境的是 Cadence、Slack、SAP 与 Salesforce，生产可用性应以自建 PoC 为准。

九、小结与行动建议

一句话概括其价值主张：别再试图说服智能体遵守规则，而是让规则运行在它够不着的地方。 内核强制解决「绕不过去」，凭据代换解决「偷不走」，Z3 证明解决「说不清」，OCSF 审计解决「查不到」。短板同样清晰：只覆盖可判定子集、不判断语义、出生只有七个月。

1. 先跑不需要 API key 的验证回路：无网沙箱 GET 被拒 → 换只读策略 → GET 通过、POST 返回 policy_denied。
2. 把凭据迁出智能体进程，这是收益最高的一步：用现成 provider YAML（github、openai、anthropic、aws-bedrock），让智能体只接触占位符；切记授权不做横向扩散，别用放宽网络规则去修凭据绑定错误。
3. 上生产前先读 coverage.domains：策略里一旦出现 GraphQL / MCP / WebSocket，证明器即不可用——此时证明结果只能当辅助证据；并给 openshell-prover 设好 --timeout 处理 solver_timeout。
4. 共享部署必须收口三件事：设置 gateway_jwt.ttl_secs、确认集群 CNI 真正执行 NetworkPolicy、显式关闭遥测（OPENSHELL_TELEMETRY_ENABLED=false 或 Helm server.telemetryEnabled=false）。
5. 把政策顾问当成「注意力的放大器」而非自动放行器：默认人工复核，让证明器给出的反例（具体到二进制、host、method、path）成为审批依据；改文件/进程限制要重建沙箱，只有网络规则能热加载。

资料来源（抓取日期 2026-09-29）：GitHub REST API 与 Trending daily 页面（元数据、releases、tags、目录树、README/LICENSE/GOVERNANCE/MAINTAINERS/AGENTS）；OpenShell 官方文档（Overview、Architecture、Sandbox Policies、Network Rules、Policy Prover 等页）；NVIDIA Developer Blog 两篇（OpenShell 0.1.0 运行控制、自进化智能体）；NVIDIA 新闻稿（Open Agent Safety Platform）；OpenShell Research Dev Notes 两篇（形式化方法/Z3 溯源、长跑对抗实验的 416 次决策与提案原文）；第三方 kenhuangus.substack 与 DeepInfra/HPCwire 的 Vera 基准报道（厂商口径）。功能描述以仓库源码与官方材料为准；第三方与厂商数字已标注性质，无法核实处标「待确认」。