症状：Agent 明明被提示“不要读取密钥”，却仍可能通过获准工具访问文件或向外部服务发请求。
最快解法：评估 NVIDIA OpenShell 部署，用运行时策略限制文件、网络和凭据访问；先在受控环境逐项测试，再判断是否适合接入业务。
适合正在评估 OpenShell、需要在服务器或团队环境运行自主 Agent 的开发者与平台工程师。
如果你要确认运行前提、策略边界和上线验收方式，本文按文件、网络、凭据这几类风险展开。
最后更新于 2026 年 9 月 30 日；部署与策略信息核对自 NVIDIA OpenShell 官方文档、Quickstart及安全指南。兼容性和发布渠道请以官方支持矩阵为准。
提示词约束为什么不能代替执行隔离？
“不要把工作区内容发出去”只是行为指令，不是操作系统权限。Agent 调用命令、文件工具或网络客户端后，能否读写文件、访问外部地址，取决于运行环境和工具的授权。提示词可能影响模型如何选择，却不能强制拦截越权操作。
AI Agent 沙箱要解决的是另一层问题：让访问规则由运行时执行，而不是只靠 Agent 遵守约定。OpenShell 将 Agent 放在沙箱中，由 Gateway 管理生命周期和策略，Supervisor 在运行边界内处理请求，计算驱动负责创建沙箱并建立隔离。它不是“装上就绝对安全”的保证；宿主机、镜像、驱动、策略和工具链仍需纳入评估。官方架构说明介绍了这些组件及其职责。
它与只配置普通容器的方案有什么不同？ 普通容器提供运行隔离，但不会自动替你定义每个 Agent 可读写的路径、可访问的网络目标或凭据可用范围。OpenShell 在运行环境之外增加策略管理和执行机制，让这些权限可以被显式配置与验证。它不是容器的替代品，而是将 Agent 的访问边界变得更可检查。
⚠️ 部署状态提醒：官方支持矩阵区分开发版、预发布版与稳定版，并说明稳定版在支持矩阵范围内面向生产使用。不要把从开发分支安装成功，等同于获得生产环境支持；先确认版本渠道、运行平台及驱动均符合矩阵要求。
部署前要检查哪些运行条件？
部署前需要准备什么？ 至少要有可连接的 Gateway、已配置的计算驱动、工作站上的 CLI，以及包含 Agent 和必要依赖的运行镜像。Quickstart 列出 Kubernetes、Docker、Podman 和 MicroVM 等驱动选项，但实际可用组合应以支持矩阵为准。CLI 安装成功并不代表目标主机、驱动和内核功能都满足要求。
还要验证 Gateway 到驱动及沙箱的通信路径、镜像中 Agent 程序的真实位置、外部服务域名解析，以及凭据从 Provider 到目标请求的链路。若文件隔离依赖 Landlock，官方安全指南指出其强制基线需要 Landlock ABI 3 或更新能力；文档建议使用 Linux 6.2 或更新版本，或经过验证、提供相应 ABI 的发行版回移植。实际环境应检查内核能力，而不只看发行版名称。
| 检查项 | 部署前确认 | 未确认的后果 |
|---|---|---|
| 版本与平台 | 选择稳定版，并核对主机、架构和驱动支持情况 | 功能不兼容，或使用尚未通过发布验证的构建 |
| 计算驱动 | 确认 Gateway 已配置目标驱动，且能创建沙箱 | CLI 可运行，但沙箱创建或连接失败 |
| Agent 镜像 | 核对 Agent、工具依赖及实际二进制路径 | 网络规则绑定到错误程序，或 Agent 缺少任务依赖 |
| 内核与文件策略 | 检查 Landlock 能力以及策略是否完整生效 | 配置路径未按预期限制，导致验收结果不可信 |
| 网络与凭据 | 确认外部端点、请求路径和 Provider 绑定方式 | 为了排错而放宽权限，或凭据无法按预期注入 |
安装和首次创建沙箱时，按当前Quickstart 步骤操作；不要长期依赖未经复核的安装脚本或开发版命令。团队环境也应明确谁能管理 Gateway、修改策略和批准新增端点，避免把个人开发配置直接当成共享服务器规范。
文件、网络与凭据怎样逐项收紧？
文件规则怎么验证？ 先列出任务所需工作区、依赖目录和输出目录，再区分只读与读写权限。只给构建任务开放必要的输出子目录，不要因为 Agent 需要写一个目录，就授予整个宿主机目录写权限。官方策略文档说明，文件系统与进程类设置在沙箱启动时应用；变更后应确认是否需要重新创建沙箱。
测试时准备三类路径：任务必须读取的文件、明确禁止读取的敏感路径、明确禁止写入的位置。通过 Agent 实际使用的工具分别尝试访问，记录哪些成功、哪些被拒绝。还要检查工作目录、挂载目录和镜像内路径是否重叠；仅检查策略文件内容，不能证明运行时实际采用了预期规则。
网络策略要限制到什么程度？ 先明确任务需要访问的目标，再按具体程序、主机和端口配置允许规则；对支持请求检查的 API，继续限制方法和路径。只允许连接到某个 API 主机，不一定意味着请求只能读取数据。OpenShell 的网络规则说明提到，匹配规则可能叠加，因此要检查所有可能授权同一请求的规则，而不是只检查刚新增的那一项。
| 风险边界 | 初始策略 | 验收动作 |
|---|---|---|
| 文件访问 | 只开放任务路径，并分别设置只读、读写 | 测试授权读取、越权读取及越权写入 |
| 外部网络 | 只允许任务必需的程序和目标 | 测试允许目标、未授权目标及不允许的方法或路径 |
| 凭据使用 | 使用 Provider 管理凭据，限定其适用端点 | 检查错误端点是否被拒绝，以及 Agent 是否能读到真实密钥 |
| 策略变更 | 审查每次权限扩展，并核对生效策略 | 保存变更记录，重新运行相关越权测试 |
一个常见场景是：团队的代码审查 Agent 需要读取项目文件、向模型服务发送请求，并查询代码托管服务。与其让它继承开发机的全部凭据和网络权限，不如先将项目目录设为只读，再按实际调用为必要程序放行目标端点；之后单独验证写入操作、未授权域名和不必要的 API 方法都被拒绝。这个案例只能说明如何设计测试，不能替代你在目标镜像与驱动上的实际验收。
凭据被注入后，Agent 就一定看不到吗？ 不应这样推断。要分别检查密钥存储、凭据注入路径和 Agent 进程可见内容。Provider Profile 可以描述凭据、端点和允许的程序；网络连接授权与凭据授权是不同的边界。根据Provider Profiles 文档，网络规则放行本身不代表凭据也可发送到该目标，端点绑定也不能替代网络授权。
不要把密钥写进提示词、仓库或 Agent 可读的配置文件。验收应使用专用测试凭据：确认 Agent 不能通过文件、环境信息或日志直接取出真实密钥；再测试未授权端点无法获得凭据。遇到请求失败时，先核对端点绑定和有效策略，不要为了让调用成功就扩大整个网络范围。
✅ 优点：权限可以按路径、程序和网络目标拆分；策略调整及请求结果可供复核；凭据可以与网络访问授权分开管理。
❌ 限制：你需要了解 Agent 的真实依赖与二进制路径；静态隔离项变更可能需要重建沙箱；策略维护和回归测试会增加运维工作。沙箱也无法替代宿主机加固、凭据轮换和业务审计。
怎样用测试结果决定是否继续部署？
不要把“沙箱启动成功”当成安全验收通过。至少覆盖越权文件读取、越权写入、未授权网络连接、请求方法或路径不符、凭据误发，以及沙箱或 Supervisor 异常退出。每项测试都记录预期结果、实际结果和所用策略版本；任何一次越权访问成功，都应先修正边界，再重新测试。
- 固定测试基线。记录 OpenShell 版本、主机系统、内核、计算驱动、镜像标识和策略版本，避免环境变化让测试结果无法复现。
- 盘点真实工具行为。运行代表性任务，列出 Agent 实际启动的程序、读写路径、外部目标和请求类型，不要只依赖项目说明。
- 先收紧文件访问。分别设置必需的只读与读写路径；检查启动日志和安全事件，确认关键策略没有被跳过。
- 验证网络规则。同时测试允许和拒绝用例，检查请求方法、路径以及同一主机上的叠加规则。
- 验证凭据边界。使用无生产权限的测试密钥，确认正确端点可以按预期调用，错误端点和越权工具不能取得凭据。
- 测试异常与恢复。模拟沙箱停止、策略更新失败或 Supervisor 连接中断，确认 Agent 不会因控制链路异常而绕过策略继续执行。
- 复核日志与变更。查阅允许、拒绝、策略更新和安全发现事件；官方日志说明列出了 CLI、TUI 和沙箱内日志的查看方式。日志应按团队审计要求持久化，不能把短期查看结果当作长期留存。
据此判断时，可以采用明确分支：
- 若目标驱动在官方矩阵内、权限需求可列清，且受控测试能够稳定拦截越权请求，就继续在非生产环境验证真实工作负载。
- 若 Agent 依赖尚未盘点的插件、动态目标或宽泛文件挂载，先收敛工具和权限，再重新评估。
- 若策略未能生效、日志无法支撑核验，或业务要求立即投入关键生产流程，就暂缓上线，不能用“提示词写得更严格”代替补齐隔离与验收。
- 若工作负载要求直接访问宿主机设备、物理接口或长期稳定的高负载运行，应评估专用自有基础设施，不要假设云端临时环境能替代这些条件。
若你当前是在共享服务器上直接运行 Agent，手工维护容器权限可能带来规则分散、出站流量难以复核、排错时权限越放越宽等问题；OpenShell 能帮助明确部分运行边界，但不会替你完成业务风险评估。反过来，若你的任务是长期稳定重负载或必须使用物理接口，自购或专用服务器通常更值得评估。只有在临时搭建远程开发工作站、编写策略或验证客户端流程时，才考虑把 Mac 环境作为辅助方案；先阅读 Kvmzen 服务条款，再对照 Kvmzen Mac 云租用环境确认用途与运行时相符。Mac 工作站不能替代你对目标 Linux 驱动、内核和沙箱策略的验证。