团队把 AI Agent 跑起来之后，凭据和权限该放在哪？用 OneCLI 拆开沙箱、网关与审批边界
当团队开始把 AI Agent 接入代码仓库、工单、对象存储或内部 API，问题很快会从“模型是否够聪明”转成“它到底拿到了什么权限”。把 API Key 直接塞进 Agent 容器的环境变量很省事，但也意味着：一旦提示词、依赖、工具调用或日志处理出现问题，密钥与业务动作会处在同一条故障链上。
OneCLI 是一个面向团队运行 AI Agent 的开源平台。它的重点不是再包装一套聊天界面，而是把个人 Agent、隔离运行环境、凭据代理和集中策略分成不同组件。项目的核心代码采用 Apache-2.0；不过仓库中存在受 OneCLI Enterprise License 约束的 ee/ 路径，因此不能笼统地称整个仓库都以 Apache-2.0 发布。对于希望自托管 Agent、又不想让每个 Agent 直接持有共享密钥的团队，这个边界值得先弄清楚。
先把问题拆成三层
一个可执行任务的 Agent 通常至少需要三种能力：能运行命令和写文件的执行环境；能访问 GitHub、LLM 或内部服务的网络出口；以及在删除工单、发送邮件等高风险动作前等待人的确认。若把这三件事都交给同一进程，权限审计会非常困难。
OneCLI 的设计将它们拆开：每名成员可拥有独立 Agent；Agent 在自己的 sandbox 中运行；出站请求经 Rust Gateway 处理；控制台则负责 Agent、连接、密钥授权、记忆和技能等管理。README 还说明，Runner 只需要主动向外连接，不必在运行 Agent 的机器上开放入站端口。这对笔记本、家庭实验环境或 NAT 后的 VPC 有实际价值，但不等于“默认绝对安全”——网关策略、部署主机和管理入口仍然是必须自行维护的安全边界。
更关键的是，沙箱不是“不能访问网络”。项目的说法是：它的出口被限制在 Gateway；Gateway 再根据已授予的连接与规则转发请求。这样做的目的不是消灭风险，而是把“某个 Agent 进程能读到所有密钥”的问题转化为可以集中配置、撤销与审查的授权问题。
架构中哪些部分真正承担边界
可以用下面的路径理解一次工具调用：
Agent sandbox -> Rust Gateway（策略匹配、凭据注入） -> 已授权的外部服务 Web Dashboard / API Server -> 管理 Agent、连接、授权与任务状态 Runner -> 创建、暂停、回收 sandbox
项目说明中，Gateway 会拦截出站请求，并按 host 与 path 规则匹配密钥；密钥可被注入到请求头或查询参数。静态 secret 以 AES-256-GCM 加密保存，并在请求时解密。Agent 通过 Proxy-Authorization 头携带访问令牌，而不是在每个 Agent 的提示词或工作目录里复制服务密钥。
这里有两个不该被忽略的取舍。第一，网关成为策略执行点，也成为高价值组件：其规则写得过宽，隔离并不会自动阻止越权访问。第二，MITM 处理 HTTPS、凭据按 URL 规则匹配等能力需要谨慎配置和监控；不要因为系统“有网关”就跳过最小权限、密钥轮换与审计。
OneCLI 还提供聊天内的人在回路审批，文档列举了发送邮件、删除 Linear ticket、清空 S3 bucket 这类需要强控制的动作。实际落地时，审批应当尽量绑定到具体动作及其参数，例如收件人、目标仓库或桶，而不是泛化为“允许访问某个域名”。否则审批可能退化成一次宽泛授权，无法回答“人究竟批准了什么”。
自托管前，先用最小环境验证控制面
上游 README 给出的自托管入口如下：
git clone https://github.com/onecli/onecli.git && cd onecli pnpm install pnpm run setup
完成后可在浏览器打开：
http://localhost:10254
这是适合先验证流程的起点，而不是把生产配置一步到位的替代品。仓库当前 package.json 要求 Node.js >=22，并固定使用 pnpm@9.0.0。如果是本地开发模式，官方文档给出 mise install、pnpm install、pnpm dev；并说明该命令会准备 .env 所需密钥、启动 PostgreSQL、执行迁移并运行完整组件。不要把开发命令直接当作长期生产部署方案。
首次初始化还有一个很容易遗漏的风险：官方自托管文档明确提示，实例尚未创建 owner 时，第一个访问并注册的人会成为 owner。因此启动后应立即完成管理员初始化；在此之前，不应把未初始化控制台暴露到公共网络。长期运行还应按文档固定镜像版本，例如在 .env 中设置 ONECLI_VERSION，避免默认 latest 在升级时带来不可预期变化。
凭据治理应当从“谁能用”开始
可采用一条简单但可操作的上线顺序：先为外部服务保存连接或模型密钥；再把该连接显式 grant 给某个 Agent；最后才让它执行任务。文档说明，没有获授模型 key 时，sandbox 不会启动。这比“每个 Agent 都带一套万能环境变量”更接近最小权限原则。
若组织已使用 Bitwarden，OneCLI 文档说明可通过 Bitwarden Agent Access SDK 进行按需注入：Gateway 在没有匹配服务器端 secret 时才向 vault 请求凭据，服务器端 secret 优先；返回的 vault 凭据在内存中缓存 60 秒后丢弃。需要精确理解的是，这个描述针对 vault 返回的凭据，并不表示平台的所有配置或会话状态都不持久化。当前文档确认的是 Bitwarden 集成；1Password 被描述为未来可能加入的选项，不应写成已支持功能。
适合尝试 OneCLI 的场景，是团队已经有多个需要实际访问外部系统的 Agent，并且愿意投入时间配置身份、授权、审批与部署运维。若只是个人本地运行一次性脚本，完整控制面可能过重；若团队追求“给模型一个全权限 Token 就立刻自动化”，它也会迫使你面对此前被跳过的安全设计工作。
把策略设计成可验证的变更，而非一次性勾选
上线前可以把每个 Agent 的授权写成一张简短清单：它服务于哪位成员或哪个业务角色、允许访问哪些服务、哪些请求方法会改变外部状态、哪些动作必须审批、授权失效后任务应如何失败。随后用一个低权限测试连接验证三类结果：读取允许的数据应成功；访问未授予的主机或路径应失败；需要审批的变更不应在无人确认时继续执行。这样做能把“平台是否安全”的抽象讨论，转成团队可以在每次新增连接时重复执行的验收项。
密钥规则也不宜只按域名粗分。例如同一 API 主机往往同时提供只读查询和写入接口；如果 host/path 匹配范围过大，一个本应只读取 issue 的 Agent 可能也能创建、关闭或删除资源。应优先把凭据拆为用途更小的 token，并让网关规则与任务边界对齐。对共享服务账号尤其如此：授予某个 Agent 的连接应能独立撤销，而不应迫使整个团队停用同一把密钥。
最后，不要把 Gateway 当作唯一防线。沙箱中的依赖供应链、Agent 的工作目录、控制台 owner 账户、外部服务自身的权限模型都仍会影响实际风险。保留 Agent 任务、授权变更和审批决定的审计记录；在升级镜像或修改 URL 匹配规则前先在隔离环境验证；当某个任务不再需要连接时及时收回 grant。OneCLI 提供的是将这些治理动作集中起来的结构，而不是替团队替代威胁建模和日常运维。
对故障路径也应预先设计：Gateway 无法匹配连接、凭据过期、审批无人响应、Runner 无法拉起 sandbox 时，任务应以可识别的失败状态结束，而不是自动退化为更宽的网络权限或共享管理员密钥。把失败原因返回给操作者，并将重试与人工介入作为明确流程，通常比“为了让任务先跑通”临时扩大授权更可靠。对于会修改工单、发布内容、发送通知或影响基础设施的任务，建议先在测试项目、测试桶或只读副本上演练完整链路；确认策略命中、审批记录和撤销行为都符合预期，再接入真实生产资源。