KechuAI

OneCLI：把 API Key 永远留在 Agent 视线之外的 Rust 凭证网关

AI
开源
安全
Agent
网关
Rust
2026/9/29
·

阅读时间: 大约 7 分钟

OneCLI：把 API Key 永远留在 Agent 视线之外的 Rust 凭证网关

OneCLI 官方架构图：Web Dashboard 与 Slack 接入 API Server，Runner 在 NAT 后拉起每个员工的沙箱，所有出站流量统一经过 Rust Gateway，密钥只在 Secret Store 里按主机+路径解密注入

“靠 prompt 约束模型别把 API Key 发到外面去，根本靠不住。“这是过去一年 Agent 安全领域最大的共识。OneCLI 的选择是把策略放到模型管不到的地方——网络层。这个 YC 支持、GitHub 约 3.5K star 的开源项目，把自己定位为”为团队打造的 Agent harness”：每个员工一个沙箱 Agent，所有出站请求强制过一个 Rust 网关，凭证由网关在请求时注入，Agent 手里只有占位符。本文基于其官方文档与架构说明做解析。

一、架构：沙箱是牢笼，网关是唯一出口

官方把系统拆成六个组件（见上图）：

  • Web Dashboard（Next.js，端口 10254）：建 Agent、对话、改记忆/技能、管理连接与授权；
  • API Server（Node.js / Hono）：控制面，持有数据库、会话面与 Runner 轮询的工作队列；
  • Rust Gateway（端口 10255）：拦截每一个出站请求（包括 HTTPS，通过 MITM），做策略判定与凭证注入；
  • Runner + 沙箱（Docker）：启动、停放、回收 Agent 沙箱，出站-only，从不碰数据库；
  • Sandbox Supervisor：跑在每个沙箱内，用厂商中立的 harness 接口，Agent 运行时可替换；
  • Secret Store：静态 AES-256-GCM 加密，仅在请求时解密。

关键拓扑约束是：沙箱里唯一能出去的路就是网关。Runner 出站-only、不开入站端口，所以一台笔记本、homelab 或 NAT 后的 VPC 都能跑，无需内网穿透隧道。

二、网关怎么干活

每个出站请求（无论是沙箱内 Agent，还是你用 onecli run -- claude 接进来的外部编码 Agent）都走同一条路径：

  1. Agent 发出普通 HTTP 请求，例如 GET https://www.googleapis.com/calendar/v3/events；
  2. 网关先评策略：组织规则 + 该 Agent 自身授权。被封或超限的请求直接回 403/429；
  3. 命中审批规则的请求暂停，在对话里渲染 Approve/Deny 卡片，超时默认拒绝；
  4. 若放行，网关按目标主机与路径匹配授予该 Agent 的凭证，解密后以 header（如 Authorization: Bearer ...）或查询参数注入；没授权的凭证根本不会被考虑；
  5. 带凭证转发，响应原样返回。

这里有个值得肯定的安全次序：策略判定在凭证注入之前——被拒的请求不会触发解密、不会碰到任何密钥。Agent 用 Proxy-Authorization 头里的 access token 向网关自证身份，从头到尾拿不到真实密钥。官方还支持接 Bitwarden / 1Password 做按需注入。

三、策略引擎

规则自顶向下、首条命中即生效，每条规则把”身份”（哪些 Agent/人）与”目标”（某个应用及其工具、某个连接、某个密钥、或一条网络模式）配对，动作有三种：Block（403）、Allow（可叠加要求人工审批，或限速到每窗口 N 次，超出回 429）。策略引擎喂了两层：组织级护栏（任何工作区不能放松）与 Agent 级授权（你授予一个连接时自动编译成规则）——两层都允许才放行。

四、口径与局限

  1. 所有流量过一个网关，网关即单点：Koala 点评点出的正是这一点——覆盖面确实比在单个 MCP Server 里做权限校验更广（连 Agent 自己写代码直接发 HTTP 这条路也被堵住），但代价是网关本身成为关键单点，一旦它被攻破或故障，全部 Agent 出站都受影响。
  2. HTTPS MITM 意味着网关看得见明文：为了按 URL 路径做策略与凭证注入，网关要解密 Agent 的 TLS 流量。这对自有数据是可控的，但意味着信任必须完整地放在这层；对涉及第三方敏感数据的场景需评估合规。
  3. 产品已从”凭证网关”扩成”团队 Agent 平台”：官网现在主打”每个员工一个 AI 队友”，凭证网关是其中的安全底座，而非全部；核心代码 Apache-2.0，企业功能另有单独许可——自-host 能用多少、哪些要付费需自行核对。
  4. “500 次/月 + $5 额度”是免费档营销数字，不是性能 SLA；生产自-host 的成本主要在沙箱与 Runner 的 Docker 资源。
  5. 审批靠卡片+超时拒绝：这是确定性的人机回环，但”过期即拒绝”在夜间/非工作时间会阻塞需要即时审批的自动化任务。

五、客观分析：价值与谁该关注

价值：它把”最小权限 + 网络层强制执行”从理念落到了一个可自-host 的具体产品——Agent 永远拿不到密钥、策略在凭证解密前判定、限速/审批/按主机路径授权一应俱全；onecli run -- claude 还能把现有编码 Agent 一并纳管，不必换工具。

局限：单点网关与 MITM 信任模型需要运维信心；深度使用团队版/企业功能会有许可约束；对个人开发者或单 Agent 场景偏重。

适合谁：要给全公司员工发 Agent、又绝不能让密钥散落到 prompt/代码里的团队；尤其适合已有 Claude Code/Codex/Cursor 等多套编码 Agent、想用一个网关统一收口出站权限与审批的工程组织。

参考来源