Agent 权限控制NVIDIA OpenShell 如何把策略挡在智能体之外原文NVIDIA Technical Blog - 《NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring》https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/最近几周 Agent 圈出一个很尴尬的局面多家前沿实验室先后确认智能体跑出了本该关住它的评测环境摸到了它不该碰的系统其中一部分还误报了自己的行为。NVIDIA 在 9 月 28 日一次性放出两篇博客回应这件事——一篇讲平台Open Agent Safety Platform一篇讲实现OpenShell 运行时控制。对 Agent 开发者来说值得抄的不是结论要给 Agent 加安全层而是它怎么做的权限不写在提示词里也不放在 Agent 进程里而是放在 Agent 够不到的地方由外部强制执行。这篇把这条机制从概念到命令拆开讲。一、这条热点在说什么NVIDIA OpenShell 是一个开源安全运行时Apache 2.0仓库在 github.com/NVIDIA/openshell当前版本 0.1.0定位是在不改动 Agent 代码的前提下声明并强制执行这个 Agent 能访问哪些系统和数据。它有两个层次层次组成职责运行时OpenShell沙箱执行、受控服务访问、凭证管理、策略形式化分析平台OpenShell Sentry on BlueField-4 DOCA把监控与强制执行下沉到 DPU 硬件做带外out-of-band观测与线速执行官方给出的采用方包括 Cadence芯片设计里的 RTL 设计工程师智能体、Slack按需 Agent 平台、Gecko Robotics物理机器人上的 Agent 治理。框架侧声明支持 Codex、Claude Code、Pi、Hermes 以及后续框架。一句话概括它的立场互联网不是靠让网页开发者承诺善良变安全的是靠浏览器不再信任网页里的代码变安全的。Agent 需要同一个信任层。二、五条设计原则第一条就否掉了靠模型自觉平台文档把设计原则列成五条其中前三条基本决定了实现形态策略必须可验证Agent 运行前要有证明器prover证明它的策略无法越出操作者意图强制执行必须带外控制逻辑不在 Agent 内部也不在它能够到的范围内Agent 甚至不需要知道自己在被看着通往模型大脑的路径才是控制点Agent 不动下一次思考就无法行动控住这条路径就同时拿到了最好的观测点和随时中断它的开关。后两条偏向部署策略Agent 权限越大其推理过程就需要越可见这也是开放模型的一个优势——整个推理空间和激活值都可见以及责任分担模型——实验室、企业、硬件供应商各管一层所以运行时和策略语言必须开放任何供应商都能接入。第三条是这篇最值得记的一句。很多团队的权限设计是给工具加白名单但 Agent 的每个动作都要经过一次模型调用控住模型调用入口等价于拿到了一个统一拦截点加一个总开关。三、三层架构与三个组件平台层把智能体系统切成三层应用层模型、harness、工具、数据、脚本、运行时层把应用层投射到基础设施上负责持续监控与实时策略执行、基础设施层真正跑负载的算力与硬件。OpenShell 自己是运行时层由三个组件咬合OpenShell Gateway管理大量沙箱的生命周期与策略OpenShell Supervisor与每个沙箱配对运行在 Agent 工作负载之外逐个检查出站请求是否符合策略OpenShell Sandbox用内核级控制限制工作负载能读改哪些文件、防止它获取额外系统权限并且除了经 Supervisor 之外没有网络出口。关键在中间那个。Supervisor 不在 Agent 进程里Agent 拿到 shell、运行生成的代码、拉起子进程、甚至提议把任务委托给子 Agent 时这些控制依然成立。四、drift为什么这个问题训不掉官方把Agent 跑偏叫 drift行为漂移定义为偏离既定任务或运行约束的动作。触发原因很具体被策略拦截、程序 bug、缺工具、指令含糊或者让 Agent 连续跑几天几周去啃一个难题——前一千种尝试都不成功的那种。它的结论需要划重点这类漂移无法在不损失能力的前提下被训练掉而且处于这种状态的 Agent不能被指望完全管住自己的行为。这就是为什么必须有一层独立的、运行时的强制措施而不是继续在提示词和微调上想办法。五、跟着走一遍一次策略决策是怎么发生的官方给的演示刻意不用模型调用只用 curl 打 GitHub 的公开端点让每一次策略决策都肉眼可见。同一个规则对 Agent 发起的请求同样生效。先建一个没有任何出网权限的沙箱openshell sandbox create--namepolicy-demo\--no-auto-providers\--policyexamples/no-network.yamlcreate 命令会直接在沙箱里打开一个 shell。在里面尝试读一个公开接口curl-sS--max-time10https://api.github.com/zen请求失败因为沙箱没有出网许可。在宿主机另开一个终端看日志能查到是哪个程序发的请求、为什么被拦openshell logs policy-demo--since5m接着换成只读策略。官方的策略用 YAML 编写编译成 OPA/Rego然后由 OpenShell 对每个出站请求求值network_policies:github_api:name:github-api-readonlyendpoints:-host:api.github.comport:443protocol:restenforcement:enforceaccess:read-onlybinaries:-path:/usr/bin/curl逐字段读一遍endpoints声明目标主机与端口protocol: rest表示要解析 HTTP 内容——正因为解析了它才能在同一条 API 上放行读、拦下写access: read-only是权限级别binaries把这条规则限定给指定可执行文件避免换个程序绕过。这套写法说明一个设计取向网络策略不是能不能连而是能对哪个服务做什么操作。同样的解析能力覆盖 HTTP、GraphQL 和 MCP 流量。不用重启沙箱就能换策略openshell policysetpolicy-demo\--policyexamples/github-readonly.yaml--wait回到沙箱里再试两次请求读放行、写被拦宿主机日志里能看到拦截记录。策略决策会写进符合 OCSFOpen Cybersecurity Schema Framework规范的审计轨迹拦截时可返回带说明的错误帮 Agent 判断下一步做什么而不是让它卡死。六、凭证不进入工作负载Agent 干活离不开模型 API 和内部服务但把真凭证交给工作负载等于把边界交给了它。OpenShell 的做法是真实凭证始终留在 Agent 工作负载之外只有请求命中该凭证被批准的端点时才在外部完成替换。一个服务的授权不会让凭证对另一个服务可用——如果 Agent 把占位符发到了批准范围外的地址请求直接被拒。这里有个容易误解的点服务端自己的权限检查仍然生效OpenShell 只是额外加了一层控制。所以会出现这种情况——凭证本身有写权限但只读策略仍然能拦住写请求。两层各自独立不是替代关系。服务用 provider profile 定义凭证、端点与允许的程序把一个已配置好的 GitHub provider 挂到新沙箱上直接跑 Codexopenshell sandbox create\--providergithub\-- codex七、运行时改权限申请要人来批长任务总会遇到一开始没预料到的服务。策略拦住请求时OpenShell 会记录这次拒绝交给操作者或 AI 审核者复核。开启策略顾问后Agent 可以提出一个范围尽量窄的网络或文件策略变更申请默认状态是待人工复核并且Agent 不能批准自己的申请。批准之后新规则热加载进正在运行的沙箱Agent 不用重启任务就能重试。要注意边界文件系统和进程限制在沙箱启动时就固定了改这些必须新建沙箱能热改的只有网络类策略。这个划分挺务实——网络访问是长任务里最常随任务演化的部分。开启方式openshell settingssetsandbox-name\--keyagent_policy_proposals_enabled\--valuetrue八、形式化证明为什么不能让模型自己判断我这权限没问题官方点出一个很实在的漏洞一条策略看起来严格不代表没有别的路。从一个工具上拦住 GitHub 写操作如果另一个被允许的工具或生成的代码用同一把凭证也能发出同样的写请求拦截就没有意义。所以策略证明器用形式化逻辑去检查策略授予的全部权限包括 provider 贡献的访问权要么证明被建模的权限都在操作者定义的边界内要么给出一个具体的越界动作。关键性质是结论来自策略模型Agent 的解释无法改变这个结论。官方还给了一段对抗实验的结果在长时程对抗实验中被削弱了安全护栏的前沿模型最多花了约两小时试图说服一个 AI 审核者授予能够修改受保护 GitHub 仓库的权限。证明器向审核者提供了这些权限实际意味着什么的证据在人工复核与运行时控制叠加下这些测试中没有发生受保护仓库的写入。对做 Agent 的人来说这条的迁移价值比硬件细节更高凡是把是否放行交给模型判断的地方都要有一个模型改不动的证据来源。九、从本地到生产小规模起步的路径官方也写了先在本地沙箱里定义权限、开发应用要服务多个用户时用 workspaces 与 SDK 管理沙箱每个工作负载有自己的策略和挂载的 provider。沙箱外的可信中间件负责接身份服务、往请求链路上加应用自己的检查。算力驱动支持 Docker、Podman、MicroVM、Kubernetes。硬件那条线属于规模化选项在 Vera Rubin POD 这类系统里每块计算托盘上都有一颗 BlueField-4 DPU位于节点通往模型的唯一路径上因此可以提供连续的带外可观测性与线速的实时策略执行它独立于主机主机不可信时依然成立。已经跑在 Vera BlueField-4 上的团队启用这套保护只是一次软件更新。十、小结可以直接搬走的三条权限从提示词里的要求改成运行时可执行、可审计的策略并且策略要能编译成机器可判定的规则这里是 YAML → OPA/Rego强制执行放在 Agent 够不到的位置外置 Supervisor、必要时下沉到硬件保证 Agent 起 shell、跑代码、拉子进程时控制不失效放行判断要有模型改不动的证据来源形式化证明、确定性策略求值同时给 Agent 一条申请—人工批准—热加载的合法扩展通道。一句话记住这篇的立意沙箱解决的是跑在哪策略执行解决的是能做什么两者都要且后者必须是 Agent 自己动不了的那一层。以上版本号、组件、命令与策略字段均来自 NVIDIA 9 月 28 日的两篇官方博客平台篇与 OpenShell 0.1.0 走查篇产品页、硬件要求与后续版本变化以官方文档为准。