在系统提示词里写“禁止访问生产数据”，只是给模型的行为建议，不是强制权限。真正的安全边界应当在 Agent 外部：即使它打开 shell、生成新代码或启动子进程，越权请求仍然被运行时拒绝。
NVIDIA 9 月 28 日详解 OpenShell 0.1.0，但官方 GitHub 在同日已发布 v0.1.2，因此安装时不应照抄文章的旧版本号。它支持 Codex、Claude Code、Pi 和 Hermes 等工作负载，主要由 Gateway、Supervisor 和 Sandbox 三部分组成。Gateway 管理多个沙箱和策略，Supervisor 在工作负载外检查外发请求，Sandbox 用操作系统内核控制文件、进程和特权。
这个分层的核心不是“让 Agent 更听话”，而是默认无网络路径，任何外发连接都经过 Supervisor。策略可检查 HTTP、GraphQL 和 MCP（模型上下文协议）流量，因此可以允许查询、拒绝写入。真实 API 密钥留在工作负载外，只对允许的终点替换占位凭据。就算密钥本身有写权限，策略层仍可拦住 POST。
最小验收：先证明拒绝，再证明放行
官方技术文章给了一个不需要 API 密钥的 GitHub 公开端点练习。安装 Docker、Podman 或支持的虚拟化后，先下载官方 no-network.yaml 和 github-readonly.yaml，然后执行：
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yaml
curl -sS --max-time 10 https://api.github.com/zen
openshell logs policy-demo --since 5m
预期第一次 curl 被拒绝，日志能指出请求程序和命中规则。接着用官方只读策略更新沙箱，重试 GET，再尝试一个写方法：验收标准是读取放行、写入拒绝、两者都有审计记录。本次环境未安装 OpenShell，上述命令未实际运行；示例必须结合 v0.1.2 当前文档执行，不应把文章摘要当作完整安全配置。
不能被“有沙箱”掩盖的三个问题
第一，策略写错了，强执行也只会精确地执行错误权限。应对策略变更做 diff，先用形式分析查看新增能力，再人工批准。第二，允许访问一个域名不等于允许一切操作；要尽量下沉到方法、路径和身份。第三，凭据不进工作负载只降低泄漏面，接收服务仍要实施自己的 IAM 和业务授权。
适合它的是长时间运行、会写代码、会调外部服务、还需要多租户管理的 Agent。如果任务只是在无网络的一次性容器中读公开文本，完整网关可能过重。我的判断是，OpenShell 的重要性不在于又有一个沙箱，而在于把网络、凭据和方法级权限组成一条可证明的控制链。
上线前给每个 Agent 做一张能力清单：可读哪些目录、可启哪些程序、可访哪些主机、可用哪些 HTTP 方法、凭据在哪里被替换，以及拒绝事件如何告警。
能力清单最好从任务推导，而不是从现有密钥推导。如果 Agent 的任务是归纳仓库 issue，它需要读 issue、读代码和写本地报告，不需要合并 PR、修改分支保护或访问计费接口。即使团队只有一枚范围较大的服务凭据，OpenShell 策略也应只允许任务必需的主机、路径和方法。这种做法不能替代缩小原始凭据权限，但能在更换凭据前先加一层强制约束。
策略变更应该像代码一样经过审查。diff 里不只要显示 YAML 增加了几行，还要翻译成人能理解的能力变化：新增了哪个主机，从 GET 放宽到了哪些写方法，哪个凭据首次可以到达某个端点。形式分析可以帮助找出组合后的越界能力，但业务负责人仍需判断这项权限是否与任务相符。
日志同样是安全边界的一部分。OpenShell 记录 OCSF（开放网络安全模式框架）格式的策略决策，这让拒绝事件可以进入统一安全分析流水线。建议分开统计误拒、真越权、未匹配路由和凭据绑定失败。如果所有拒绝都只叫“网络错误”，Agent 会不断重试，人也无法判断该改策略还是改任务。
运行时控制不能消除所有供应链风险。Agent 仍可能在允许的包仓库下载恶意依赖，在可写目录中保留污染状态，或把敏感内容嵌入对批准服务的合法请求。因此还需要依赖锁定、下载源签名、工作区一次性化、出站内容检查和业务系统自身的审计。把OpenShell当作唯一安全产品，反而会制造新的单点依赖。
多Agent场景还有组合权限问题。一个Agent只能读数据，另一个只能发消息，单独看都似乎低风险；但如果它们可以通过共享文件或远程MCP传递内容，整个系统就具备将数据发往外部的能力。NVIDIA说后续工作正扩展到多Agent权限分析，这也说明当前版本不应被当成已经完整解决组合风险。上线前要以整条任务图为单位审计，而不只看每个沙箱自己的策略。
故障演练可以从三个问题开始：如果Supervisor暂时不可用，网络是默认拒绝还是绕过检查；如果凭据代理失败，Agent是结束还是不断重试；如果日志后端不可用，策略执行是否仍然保持。只有在这些控制面故障下仍然会安全失败，运行时边界才真的值得信任。
如果 Agent 拿到的凭据本身有写权限，你现在还有哪一层能拦住误写？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。
