北京
一个智能体可以被要求待在边界之内。更值得追问的是：究竟是哪个组件，能真正拦住它越过这条边界。
英伟达在10月21日发布OpenShell，把运行时强制执行放到了这个问题的中心。沿着文档记录的请求路径走一遍，会发现一个在照抄快速开始之前值得核对的细节：省略--policy，并不能证明那条限制性的默认策略已经生效。
设想一个智能体想要调用外部API。在OpenShell记录的架构里，工作负载没法直接向那个服务打开一条不受限制的通路。它的网络流量要经过一条受保护的通道，送到智能体信任边界之外的一个监督程序那里。由监督程序检查策略，再打开一条被允许的连接。
这种分离才是关键的设计思路：请求访问的程序，并不拥有授予访问权的那个组件。
还有一个策略证明器组件。文档说，它会在批准之前检查拟议的网络变更是否扩大了访问权限。这更应当被理解为对建模后的策略变更做检查，而不是宣称智能体的每一个可能动作都已被形式化证明为安全。
默认策略的说明比“沙箱一启动就是锁死的”要具体得多。那条限制性的兜底策略，只在没有生效的全局策略、没有保存的沙箱策略、也没有由镜像提供策略时才适用。即便创建命令里没有--policy标志，镜像或配置同样可以提供策略。而镜像策略无效时，启动会被阻断，而不是悄悄退回兜底策略。
兜底策略本身不含任何出站网络规则。但挂载的提供方可以往生效策略里补充规则。所以，只描述兜底策略，并不足以完整描述一个运行中沙箱的权限。
这里有个容易犯的审查错误：看着某人敲下的命令，就从它省略了哪些标志去推断整个访问边界。该问的是：最终选中了哪条策略，又有哪些附加规则变成了生效状态。这比“默认”这个标签有用得多。
凭据同样有边界。文档记录的沙箱路径，把真实的提供方凭据挡在智能体工作负载之外，只在被允许的目的地上才提供。这减少了把可复用密钥直接放进智能体环境里的必要。
提供方参考文档里有一个重要的范围细节。拥有特权的操作员可以通过一次显式RPC取回选定的运行时凭据。文档提醒，这一步会把值导出到沙箱端点强制执行的范围之外。普通用户和OIDC管理员无法调用这个RPC。
所以“智能体看不到真实密钥”描述的是经过中介的工作负载路径，并不意味着平台不存在特权性的凭据导出操作。不同的角色，握有不同的权限。
放到部署审查里，这意味着什么？可以沿着实际运行时追踪一条被允许的请求和一条被拒绝的请求，检查选中的策略与生效的策略，并核对谁有权修改它们。提供方挂载和操作员特权也要放在一起看；只审查智能体的提示词，会漏掉这些决定。
这些是建议的核验步骤，不是在这次工作中实际执行的测试。围绕这篇文章所做的工作，是阅读提交bc4c8f0上的架构、兜底策略和提供方参考文档。没有安装OpenShell，没有测试逃逸，也没有验证硬件参考架构。
实际可拿走的结论并不宏大：被强制执行的边界，是运行时隔离、选中的策略、提供方规则与特权操作共同组合出来的结果。快速开始命令，只是入口。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
