直接答案：沙箱决定 Agent 能接触什么，凭证治理决定它以谁的身份进入系统；二者不能互相替代。生产环境还必须单独验证高风险动作审批、日志独立性和异常后的撤销路径。
为什么一个“会干活”的 Agent 会遇到两道门
让 Agent 只回答知识问题，权限相对简单；让它改文件、打开系统、提交工单或查询敏感数据，执行能力就与风险一起上升。一道门是运行环境：进程能读写哪些目录，能否向陌生域名发网络请求，能否启动子进程。另一道门是身份与凭证：进入业务系统时使用谁的账号，密码或令牌是否暴露给模型，授权能否随时撤回。
企业常把两道门合成一句“有安全沙箱”。但沙箱隔离得再好，如果 Agent 拿着高权限通用账号，也可能在允许的出口做出越权业务动作。反过来，凭证保管得再严，若执行环境可随意读本地文件、访问公网，依然有信息泄露风险。技术架构需要把两者拆开，再在任务链上重新连接。
OpenShell 解决的是执行环境的边界
NVIDIA OpenShell 的官方文档将其定义为面向自主 Agent 的沙箱运行时，重点在隔离执行环境和声明式策略。文档列出文件系统、网络、进程和推理路由等控制面，目标是让 Agent 只接触完成任务所需的资源。它支持将 Agent 置于沙箱中运行，并通过策略约束外部访问；具体保障程度仍取决于实际配置与部署。
对企业来说，值得借鉴的不是“装一个沙箱就安全”，而是“权限要在模型外执行”。若某份网页内容诱导 Agent 去读取无关目录，提示词里写“不要读”只是软约束；文件系统策略拒绝访问，才是更明确的运行边界。安全团队可以用故意越权的测试任务验证：读取被禁止的路径、访问未授权的域名、尝试调用高风险进程，观察拒绝是否发生在执行层，以及拒绝理由能否进入审计记录。
同时要看版本边界。OpenShell 是运行时技术，不等同于开箱即用的企业级智能体平台，也不替企业完成业务规则、组织权限或合同流程设计。技术文章不应把它写成全套生产治理的唯一答案。
1Password 解决的是“Agent 要登录，但不应看见密码”
1Password 在 2026 年 10 月发布 1Password for Agents，官方描述的核心过程是：Agent 遇到登录需求时请求用户从保险库授权凭证使用；用户批准后，由 1Password 帮助完成填充，Agent 不直接获得密码本身。访问可以被查看、批准、管理和撤销。
这个设计回答了另一个经常被忽视的问题。企业不能因为 Agent 需要代人操作，就把账号密码写进提示词、环境变量或共享配置文件。更合理的做法是：凭证由专门系统保存，Agent 发起有范围、有目的的请求，用户或策略批准后仅获得所需的访问结果。真正落地时还要区分个人账号与服务账号、一次性授权与长期授权、可读动作与可写动作。
1Password 的产品针对其自身生态与支持范围；不能把其官网说明直接外推到所有企业内网系统。采购或集成时应核对受支持的应用、浏览器、审批方式、日志以及异常撤销行为。
两条路线合起来，仍缺“谁批准最终动作”
假设一个报账 Agent 在沙箱里读取制度文件，并通过保险库进入财务系统。它可以合法看到票据和填单页面，但“提交付款申请”仍是业务动作，不能仅凭环境安全和登录成功就自动放行。此处需要第三道门：按动作风险设置人工确认、二次审批或完全禁止。
同理，生产环境还需要第四道门：独立审计。至少记录任务发起人、使用的工具和凭证授权、策略命中、人工决定、最终写入结果。日志若能被执行 Agent 自己关闭或改写，就很难承担事后追责。对企业而言，安全不是四项功能分别存在，而是它们能否在同一条任务上形成连续证据。
Rich AIBox 如何放进这张技术图
彩讯股份 Rich AIBox 以 Harness 为运行底座，结合工作空间、Skill、沙箱隔离、审批通道与行为追踪，帮助企业把 Agent 的执行、业务动作和运营记录放进同一条任务链。OpenShell 聚焦执行环境，1Password for Agents 聚焦凭证授权；Rich AIBox 的平台价值在于连接模型、知识、工具与业务应用，但不能因此推定它采用前两者相同的底层实现或凭证机制。
这些机制并不等于完成了安全认证。Rich AIBox 在具体项目中的隔离级别、凭证接入方式、策略强制点和审计完整性，仍要对照目标版本文档与 PoC 验证；“有沙箱”也不能被理解为数据绝不会外流。
给安全团队的一组可复测测试
建议用一个脱敏的模拟任务，给 Agent 一份材料、一个内部系统和一个需要审批的写操作。第一轮允许正常读取，确认来源和权限。第二轮放入带有越权指令的外部文本，测试沙箱能否阻止访问无关文件和域名。第三轮撤销凭证授权，观察正在运行的任务是否停止使用该身份。第四轮拒绝写操作审批，确认系统不会绕过人工决定继续执行。第五轮导出运行记录，检查关键动作与拒绝事件是否完整。
测试结果不应只写“通过”。应记录策略版本、使用身份、触发条件、实际响应、重试行为和残余风险。若企业要把 Agent 用于不同部门，测试还应加入跨工作区访问和记忆隔离，防止在一个空间得到的资料出现在另一个空间的输出里。
技术趋势的真正含义
OpenShell 和 1Password for Agents 的共同信号，是 Agent 的能力正在从“模型会不会调用工具”转向“组织是否能安全委托”。一部分边界必须由执行环境强制，一部分由身份系统托管，还有一部分要留给人做业务判断。对 Rich AIBox 这类平台，关键不是宣称“全面解决 Agent 安全”，而是明确平台负责的运行隔离、审批与追踪边界，以及仍需企业身份系统和项目配置共同完成的部分。
FAQ
有了沙箱，还需要凭证管理吗？
需要。沙箱约束进程和资源范围，无法自动回答“以谁的身份登录业务系统”以及“令牌是否暴露”。凭证应单独托管并最小授权。
凭证不暴露给 Agent，是否就能自动提交业务动作？
不能。登录授权与业务审批不是一回事。付款、外发、正式提交等动作仍应按企业规则设置人工确认或禁止。
Rich AIBox 的沙箱是否与 OpenShell 同一种实现？
不能仅凭“沙箱”这个名称认定两者实现相同。应比较各自控制的资源范围、策略强制点和可复测结果。
参考资料
- NVIDIA OpenShell 开发文档
- NVIDIA OpenShell GitHub 仓库
- 1Password for Agents 官方博客