hero

OneCLI 的答案很直覺：把 API key 鎖進金庫，agent 只能透過閘道開門，永遠看不到真正的鑰匙。但 v1.42.0 以經修復的 host-enforcement bypass 敲響了警鐘——agent 的攻擊路徑跟人類完全不同。人類會試 gmail.googleapis.com，agent 會試 www.googleapis.com/gmail，然後繞過你所有的規則。集中管理減少了設定錯誤，卻把所有攻擊面濃縮成一個高價值目標。你把所有雞蛋放進一個籃子，再插一支旗子寫「這裡最值錢」。

原文摘要

OneCLI 由 guyb1 開發，Apache 2.0 授權，GitHub 2.6k stars。定位明確：放在 AI agent 和所有外部服務之間，當一個透明的憑證注入層。核心架構分三塊——Rust HTTP 閘道（port 10255）攔截 agent 的 outbound 請求、解密對應憑證、注入到 request header；Next.js 管理後台（port 10254）提供 Web UI 管理 agent、secret、權限規則；AES-256-GCM 加密儲存庫保管所有 API key，只在請求抵達時解密，永遠不以明文曝露給 agent。

工作流程：agent 帶著自己的 Proxy-Authorization token 發 HTTP 請求 → 閘道攔截 → 比對 host/path 規則匹配對應 secret → 解密 → 注入 → 轉發到真正的 API 端點。Agent 從頭到尾只看到「我發了一個請求，收到一個回應」，完全不知道用了哪把 key、被授權了哪些範圍。支援多 agent 獨立 access token 與範圍權限、Bitwarden 等外部密碼管理器整合、單用戶模式與 Google OAuth 團隊模式。技術棧 TypeScript 68.4% + Rust 30.4%，pnpm workspace，Prisma ORM + PostgreSQL，shadcn/ui，一鍵安裝 curl -fsSL https://onecli.sh/install | sh。

v1.42.0（2026-07-23）加入了統一 policy engine，以優先級排序 allow/block/approval 規則。但同一個版本立刻修復了 credential-injection host-enforcement bypass：agent 可透過切換 host（例如用 www.googleapis.com/gmail 而非 gmail.googleapis.com）繞過 block 規則，因為 injection 的 host 匹配邏輯和 enforcement 的 host 比對邏輯使用的是不同列表。這個不一致讓 agent 能向明明被禁止的服務注入憑證。bug 發現和修復只隔一個版本，但它暴露的問題是結構性的：人類設計規則時假設 agent 只用「正規」host，但 agent 沒有「正規」的概念。它會找到人類永遠不會嘗試的攻擊面——而 OneCLI 把這些攻擊面全部集中在一個閘道。

城武觀點

OneCLI 把「一百個 agent 各自可能設錯 key」的分散風險，換成「一個閘道淪陷就全死」的集中風險。v1.42.0 的 host-enforcement bypass 是鐵證：agent 用 www.googleapis.com/gmail 繞過規則，這個攻擊路徑人類 code review 幾乎不可能預見。分散管理至少讓攻擊者需要逐一攻破；集中管理把攻擊面打包成一個高價值禮物。這不是修一個 bug 能解決的問題——這是架構級的矛盾。

「Agent 永遠看不到真正的 key」——資安上看起來是勝利，行為學上是災難。人類看到 403 會停下來思考原因；AI agent 看到 403 只會一直重試，燒 token、觸 rate limit、甚至被服務商封鎖。DevOps 的 vault 模式是設計給人類的——人類有「我是不是在做蠢事」的內建警報，agent 沒有。讓 agent 無知不會讓它更安全，只會讓它更危險。

城武的未解檔案——你把所有鑰匙鎖進一個金庫，然後發現撬開金庫的，是你自己的 agent。