Show HN: OneCLI – 以 Rust 開發的 AI 代理程式金鑰保險箱

背景

隨著 AI Agent（人工智慧代理）的興起，開發者面臨一個嚴峻的安全挑戰：如何讓這些具備自主行動能力的代理調用各類 API 服務，同時又不直接暴露真實的 API 金鑰。OneCLI 是一款以 Rust 編寫的開源憑證保險箱，它作為代理與外部服務之間的閘道器，透過「預留位置金鑰」替換機制，確保 AI 代理在執行任務時完全接觸不到真實的機密資訊。

社群觀點

針對 OneCLI 提出的解決方案，社群展開了關於安全性與實作細節的深入討論。支持者認為這解決了 AI 代理管線中憑證擴散的痛點，特別是當每個代理都需要特定權限時，集中化的管理能有效縮小洩漏後的損害範圍。然而，質疑者如 paxys 指出，即便代理拿不到真實金鑰，只要它持有能被代理伺服器識別的「虛擬金鑰」，它依然能執行所有被授權的操作，這可能導致開發者產生虛假的安全感。對此，miki_ships 反駁道，這類代理伺服器的核心價值在於「權限限縮」，因為許多 SaaS 服務（如 Stripe 或 Notion）並不支援細粒度的權限控制，透過代理伺服器，開發者可以強制執行請求範圍的限制，補足上游服務的功能缺失。

在技術實作層面，多位開發者分享了類似系統的開發經驗與坑洞。hardsnow 提醒，並非所有環境都完美支援 HTTP_PROXY 協議，特別是 Node.js 在這方面表現不佳，且 AWS 的 SigV4 簽名機制無法透過簡單的字串替換來完成，必須在代理端重新進行請求簽名。針對 Node.js 的問題，semanticc 補充在較新版本中可透過環境變數開啟支援，而 lancetiparton 則建議在 Kubernetes 環境中使用 Sidecar 容器搭配 iptables 強制導向，並注入自簽憑證來處理 TLS 終端，以確保所有流量都能被正確攔截與注入機密。

此外，關於「虛擬金鑰」是否會觸發企業內部的安全掃描工具，社群也表達了擔憂。anthonyskipper 認為這類預留位置字串可能導致大量的掃描誤報，增加資安運維的負擔。另一派觀點則討論了 OneCLI 與現有工具（如 Hashicorp Vault 或 AWS Secrets Manager）的差異。雖然有人認為既有的保險箱工具已足夠成熟，但 rgbrgb 指出，傳統工具通常是將金鑰交給程式碼使用，這依然存在金鑰在記憶體中被讀取或在日誌中洩漏的風險，而 OneCLI 這種「透明注入」的架構則能讓代理從頭到尾都無法接觸到敏感數據。最後，wuweiaxin 提出了一個更進階的觀點：真正的安全模型應該是針對每個任務生成短效期的權限令牌，而非長期有效的 API 金鑰，這才是解決代理自主行為風險的終極方案。

延伸閱讀

在討論中，社群成員提及了多個相關工具與參考資源，包括同樣具備憑證注入功能的 IronClaw 框架，以及針對信用卡數據設計的 VeryGoodSecurity 服務。此外，fly.io 團隊開發的無狀態服務 Tokenizer 與 BuzzFeed 開源的 SSO Proxy 也被視為此領域的先行者。對於偏好命令列工具的用戶，留言中也推薦了 scrt 作為 1Password 的 CLI 補充方案。針對 OpenClaw 用戶，sathish316 則分享了如何結合 Hashicorp Vault 實作動態憑證獲取的腳本範例。