NanoClaw 正在採用 OneCLI 作為其預設的憑證和代理層。每個 NanoClaw 代理程式將透過 OneCLI 的 Agent Vault 存取外部服務，這是一個處理憑證注入、存取策略和核准的閘道，讓代理程式永遠不會持有原始 API 金鑰。
NanoClaw 已經將每個代理程式隔離在自己的 Docker 容器中。OneCLI 的 Agent Vault 讓您能夠精細控制這些代理程式可以存取什麼以及如何存取。
先前，NanoClaw 運行自己的憑證代理程式，將所有秘密儲存在記憶體中。我們用 @onecli-sh/sdk 取代了它。當 NanoClaw 啟動一個容器時，它會呼叫 applyContainerConfig()，將出站 HTTPS 流量路由到 OneCLI 閘道，該閘道會注入真實的憑證：
每個 NanoClaw 代理程式群組都有自己的 OneCLI 代理程式身份，因此您的銷售代理程式和支援代理程式可以擁有不同的憑證策略。您只需使用 onecli secrets create 註冊一次憑證，閘道就會根據主機和路徑匹配出站請求。
OpenClaw 證明了人們願意交出電子郵件、日曆、程式碼儲存庫、資料庫的存取權限，以換取代理程式代表他們執行實際工作的價值。數百萬人確實這樣做了，而且大多數情況下都沒問題。但當出現問題時，後果是真實的。
Meta 的一位 AI 對齊總監授予 OpenClaw 存取她電子郵件的權限，並明確指示它未經她核准不得採取任何行動。該代理程式仍然開始大量刪除電子郵件。她無法從手機上阻止它，不得不親自跑到電腦前終止該程序。
這個故事說明了當代理程式在沒有邊界的情況下運作時會發生什麼。代理程式的價值在於賦予它們存取真實系統和真實資料的能力。一個什麼都不能碰的代理程式只是一個聊天機器人。但一個沒有策略、沒有速率限制、沒有核准流程、什麼都能碰的代理程式則是一個負擔。問題是如何在沒有風險的情況下解鎖 Claw。
今天大多數使用代理程式的人，要麼將 API 金鑰硬編碼在環境變數中，要麼從秘密管理器中提取。像 HashiCorp Vault 或 AWS Secrets Manager 這樣的秘密管理器解決了儲存問題，但它們並沒有解決代理程式實際使用憑證時發生的問題。代理程式擷取金鑰，從那一刻起，金鑰就在代理程式的環境中，在其上下文中，可以透過提示注入提取。Vault 保護了靜態的秘密，但一旦代理程式獲得了它，Vault 就出局了。
Agent Vault 位於代理程式和它調用的服務之間。您的憑證仍然保留在您今天存放的地方。但與其將原始金鑰交給代理程式，不如由 Vault 代理請求，根據主機和路徑進行匹配，注入真實的憑證，然後轉發。代理程式永遠不會看到金鑰。永遠不會持有它。永遠不會記錄它。
如果 Agent Vault 僅僅是交換金鑰，那它會很有用但有限。更重要的部分是其上方的策略層。
您可以設定速率限制，讓代理程式每小時只能發送或刪除幾封電子郵件：
限時存取、人工審核以及更進階的策略控制即將推出。回到 Meta 的事件：如果每小時的刪除電子郵件數量限制為三封，那麼造成的損害將是三封電子郵件，而不是整個收件匣。代理程式將達到上限，使用者將收到通知，這將只是一個小麻煩，而不是數百萬人看到的警示故事。
對於團隊和組織來說，這些策略可以在兩個層級上運作：組織設定了可能性的外層邊界，而個別使用者則在此框架內授予權限。但即使是單一使用者在自己的機器上運行 NanoClaw，能夠說「你可以存取我的電子郵件，但每小時只能刪除三條訊息」也能改變您對讓代理程式做什麼感到舒適的計算。
NanoClaw 解決了運行時隔離問題。每個代理程式都在自己的容器中運行，擁有自己的文件系統、自己的進程空間，並且無法從主機進行環境存取。OneCLI 的 Agent Vault 解決了憑證隔離和策略執行問題。兩者結合，代理程式在可見、可審核且可執行的邊界內運作。
這兩個專案都是開源的。NanoClaw 在 github.com/nanocoai/nanoclaw，OneCLI 在 github.com/onecli/onecli。