NanoClaw 採用 OneCLI Agent Vault

背景

NanoClaw 宣布將 OneCLI Agent Vault 作為其預設的憑證與代理層，旨在解決 AI 代理程式在執行任務時，因直接接觸 API 金鑰而產生的安全風險。透過將憑證注入與存取政策轉移至外部網關，NanoClaw 試圖在不讓代理程式持有原始金鑰的情況下，實現對外部服務的受控存取，以避免類似 Meta 高層遭遇的郵件誤刪事故再次發生。

社群觀點

針對 NanoClaw 的這項整合，Hacker News 的討論呈現出技術實務派與資安懷疑論之間的拉鋸。支持者如 gdorsi 認為，這確實是朝正確方向邁出的一步，肯定了 NanoClaw 在整合個人助理安全機制上的努力，儘管他個人目前仍對授權代理程式存取電子郵件持保留態度。OneCLI 的開發者 Jonathanfishner 也親自參與討論，強調其架構實現了真正的隔離：代理程式運行於獨立容器中，完全接觸不到 OneCLI 的進程或真實金鑰，僅能看到預留位置標記，且所有行為都受到代理層的確定性規則約束。

然而，資深開發者對此方案的安全性提出了嚴厲批評。pdp 指出，雖然重視基本資安實踐是好事，但相較於標準化的 OAuth 模型，基於 CLI 與路徑規則的安全模型顯得相對落後。他認為 REST 風格的 API 或是 GraphQL、JSON-RPC 等協議，很難透過路徑規則進行有效管控，並預測這種基於 CLI 的熱潮可能在數月內就會消退。rvz 的觀點更為激進，他將此類方案形容為「氛圍驅動開發」的產物，批評 OneCLI 缺乏正式的資安審計，本質上只是在重新發明帶有政策控制的代理伺服器。他主張真正的解決方案應該是讓容器內完全不存在任何形式的金鑰，而非依賴可能被繞過的代理機制。

此外，關於代理程式安全性的未來發展，社群也提出了更深層次的構想。jryio 提到目前業界仍缺乏完整的「意圖層」模型，即不僅是授權存取，更要能精確定義代理程式的操作邊界，例如僅能處理特定參與者的郵件。他建議應朝向類似通用角色存取控制（RBAC）的方向發展，並分享了使用簽署權杖來表達意圖的技術路徑。這反映出開發者社群對於 AI 代理程式的期待，已從單純的憑證管理，轉向更為複雜的行為審查與細粒度權限控制。

延伸閱讀

• NanoClaw 開源專案：github.com/qwibitai/nanoclaw
• OneCLI 開源專案：github.com/onecli/onecli
• MCP (Model Context Protocol)：留言中提及的另一種安全模型標準。