让 AI 写一段代码，已经不稀奇。

让 AI 读文件，装依赖，调接口，拿凭证，才算真正能干活。

麻烦也在这里。

一旦 Agent 有了手脚，它会不会碰错文件？会不会连上不该连的地址？会不会把凭证带去不该去的地方？

NVIDIA 在 GitHub 上开源的 OpenShell，给出的答案很直接：给 Agent 能力，但不给无限权限。

这个项目刚进入 0.1.x，带来稳定发布节奏、新隔离原语、扩展接口和新 API。

它面向的也不是单个聊天机器人，是一群自主 AI Agent。

README 里写得很直白：

Agents are most useful when they can read files, install packages, call APIs, and use credentials. OpenShell gives them that capability without giving them unrestricted access to your data, secrets, or network.

Agent 要有手，风险也跟着长出来

AI Agent 的价值，来自它能碰真实系统。

读文件，它才能理解代码库。装包，它才能跑任务。调 API，它才能连接外部服务。使用凭证，它才能真正执行操作。

但权限一旦放开，问题就来了。

文件能不能读？系统调用能不能发？网络能不能连？凭证会不会被滥用？

老实讲，这类焦虑并不抽象。热门评论里就有人提到，即便限制了网络域名，仍然担心代码库数据被 Agent 外泄。

也有人提到类似 HF 事件的数据外泄风险。

痛点已经很明确：Agent 越接近生产资料，越需要边界。

第一道闸，放在内核层

OpenShell 的治理方式分两层。第一层是内核级执行。

每个 Agent 跑在隔离沙箱里。内核控制它能访问哪些文件，能发起哪些系统调用。每个网络连接离开沙箱前，都要经过策略检查。

更关键的是凭证处理。

Agent 看不到真实凭证。OpenShell 只在发往批准端点的请求里注入凭证。

这句话值得多看一眼。

如果把凭证直接交给 Agent，风险自然更大。OpenShell 的思路更像门禁系统。员工不需要万能钥匙，只需要在授权范围内使用门卡。

个人觉得，这比单纯提醒模型小心一点要靠谱。安全不能靠 Agent 自觉，得靠系统强制执行。

改权限之前，先过一遍数学验证

第二层治理，是形式化验证。

策略变更被批准前，OpenShell 会先用形式化验证检查新规则可能放出什么风险。

比如，是否允许带凭证访问新主机。比如，是否允许调用新的 API 方法。风险变更会等待人工审查。

这一步很有意思。

OpenShell 把检查提前到规则变更之前。你准备放开一个口子，它先算一遍这个口子可能通向哪里。

评论区也有开发者感受到这种细粒度：

the level of control is cool, almost too pedantic.

说实话，这种控制欲对普通开发者可能有点重。对企业场景，它可能刚好是刚需。

容器只是笼子，OpenShell 想做控制台

看到沙箱，很多人会想到容器。

社区评论也很直接：

If you haven’t already been running your agents in containers, you’re crazy. That said, this looks like a great way to manage those containers.

OpenShell 并没有绕开容器。它在沙箱、网关和监督组件之间搭起一套控制平面。

项目支持 Linux，macOS on Apple Silicon，Windows with WSL 2 仍处于实验状态。运行需要 Docker、Podman 或主机虚拟化。

Kubernetes 用户可以用 Helm 部署网关，但 CNI 必须能执行 NetworkPolicy。

它还提供了策略、凭证提供方、扩展中间件、拦截器、计算驱动，以及 SDK。

安装也很开发者向。一行脚本装 CLI 和本地网关，再用 openshell sandbox create --name demo 创建沙箱。

如果想让编码 Agent 学会操作 OpenShell，还可以运行 npx skills add NVIDIA/OpenShell。这些技能会教 Agent 驱动 CLI、写沙箱策略、调试网关和推理路由。

这套东西听起来不性感。但它把 Agent 从聊天框拉到了基础设施层。

反转：讲安全的项目，默认开了遥测

OpenShell 的 README 专门提到遥测。

它会收集匿名遥测，仅限操作类别和计数，用于改进项目。不会收集沙箱名、主机名、文件路径、提示词、凭证、提供方或模型名、用户内容。

关闭方式也给了。网关设置 OPENSHELL_TELEMETRY_ENABLED=false，Helm 安装设置 server.telemetryEnabled=false，也可以直接编译掉遥测。

但评论区并不买账。

Taking default telemetry is insane.

这点我不太认同默认开启。

哪怕数据范围写得再清楚，安全敏感项目最好把选择权先交给用户。尤其是当产品主打 safe 和 private 时，默认关闭会更稳。

另一个反转来自能力本身。有人质疑：

the more access you give the agent the more capable it becomes. You can't have you cake and eat it...

这个判断很扎心。

Agent 越有能力，就越需要权限。权限越多，风险就越大。OpenShell 没有消灭这个矛盾，它把矛盾变成可声明、可验证、可审查的策略。

社区已经上场，企业运维才是硬需求

OpenShell 并不只是一个概念。

有评论说，团队已经在它之上做策略管理、安全 git 使用，以及 SCA 和 SAST 集成。也有人提到，在 GTC Europe 的演示里，相当一部分内容用到了它。

还有开发者观察到，NVIDIA 对项目的支持在加快。此前有人担心，竞争项目冒出来后，OpenShell 会被冷落。

这些信号放在一起看，方向挺清楚：Agent 基础设施正在从 demo 走向运维。

当一群 Agent 开始读代码、跑命令、调服务，企业需要的就不只是聪明模型。

它需要知道谁能读哪个文件，谁能访问哪个域名，谁能在哪个端点使用凭证，谁会在策略变更时触发人工审查。

OpenShell 把琐碎但致命的权限问题摆上台面。当 AI 开始真正干活，门禁会不会比模型更重要？

【锐评】：让 AI 干活不难，难的是让它在该停的地方停下。

参考链接：
https://github.com/NVIDIA/OpenShell