沒有人妥善解決的問題
每個做有用事情的 AI 代理人都需要憑證：API 金鑰、存取 token、錢包金鑰、RPC 端點。代理人越強大，它持有的憑證就越敏感。
大多數框架把這視為開發者的問題。你自己想辦法處理機密。你自己想辦法處理隔離。你自己想辦法處理出問題時會怎樣。
Production 代理人的實際威脅模型有兩個截然不同的層級，幾乎沒有人清楚區分：
- 憑證管理 — 機密存在哪裡、如何輪換，以及如何在一群運行中的代理人之間立即撤銷存取？
- 憑證保護 — 當代理人本身成為攻擊面時會怎樣？透過工具輸出的提示注入、惡意技能、或隱藏在抓取網頁中的越獄。代理人正在用你的 API 金鑰在
os.environ中運行——而現在入侵它的東西也有了。
這些是不同的問題，需要不同的解決方案。Hermes 在同一天交付了兩者。
第 1 層：Bitwarden Secrets Manager——憑證管理
在這個整合之前，標準的 Hermes 設定跟其他代理人框架一樣——磁碟上的明文機密：
~/.hermes/.env
──────────────
BINANCE_API_KEY=xxx
WALLET_PRIVATE_KEY=********
OPENROUTER_API_KEY=xxx
TELEGRAM_BOT_TOKEN=xxx
明文存在磁碟上，任何有檔案系統存取權限的東西都能讀取。沒有輪換策略，沒有撤銷機制。如果你在多台機器上運行 Hermes——VPS、開發機器、閘道器伺服器——你到處複製貼上數值並手動保持同步。
Bitwarden Secrets Manager 將此集中化。一個啟動 token 留在 .env 中；其他一切存在 vault 中：
~/.hermes/.env Bitwarden Vault
────────────── ───────────────
BWS_ACCESS_TOKEN=**** WALLET_PRIVATE_KEY
OPENROUTER_API_KEY
TELEGRAM_BOT_TOKEN
在每次 Hermes 啟動時，代理人呼叫 bws secret list <project_id> 並注入結果到 os.environ。bws 二進位檔會自動下載——不需要 apt、brew 或 sudo。
實際上這給了你什麼
- 集中輪換。 在 Bitwarden 網頁應用程式中更改一次金鑰。每個 Hermes 實例在下次重啟時取得——不需要 SSH 到伺服器編輯
.env檔案。 - 立即撤銷。 機器人帳號被入侵？從 Web UI 撤銷存取 token，每個實例立即失去存取權。
- 優雅失敗。 如果 Bitwarden 在啟動時不可達，Hermes 會在 stderr 記錄警告並使用
.env中已有的內容繼續。不對外部可用性有硬性依賴。 - 自我保護。 Hermes 拒絕讓 Bitwarden 覆蓋啟動 token 本身，即使使用
override_existing: true。系統防禦自身的設定錯誤。
設定
hermes secrets bitwarden setup # wizard: installs bws, prompts for token, picks project
hermes secrets bitwarden status # verify
hermes secrets bitwarden sync # dry-run: see exactly what gets applied
在免費方案中可用——不需要付費方案就能開始。
第 2 層：iron-proxy——憑證保護
PR #30179 已完全實現，35 個單元測試通過且經過 E2E 驗證。它已開放審查但尚未合併到 main，但程式碼已完成且正在運行。
架構完全翻轉了標準模型。Hermes 不是將真實憑證注入沙箱環境，而是給代理人不透明的代理 token。代理人使用該 token 進行外部 API 呼叫，iron-proxy 在網路邊界攔截，將代理 token 替換為真實憑證，然後轉發請求。
沙箱永遠不包含實際金鑰。如 PR 所述："入侵沙箱，攻擊者帶走的只是在代理背後才能運作的 token。"
這具體關閉了什麼
- 一個被提示注入的代理人嘗試讀取並外洩其 API 金鑰，只會發現代理 token——在代理之外無用，在非白名單主機上無用。
- 一個被入侵的沙箱依賴嘗試向外通訊，會收到 HTTP 403。
- 一個嘗試雲端元資料端點（
169.254.169.254）的 SSRF 被預設拒絕。
新的 CLI 介面
hermes egress install # downloads pinned iron-proxy binary, SHA-256 verified
hermes egress setup # interactive wizard
hermes egress start # spawn the managed proxy daemon
hermes egress status # binary + config + pid + active mappings
以及讓整個堆疊一致的關鍵指令：
hermes egress setup --from-bitwarden
真實憑證在代理啟動時從你的 BSM 專案拉取。在 Bitwarden 中輪換金鑰，它會在下次代理重啟時傳播到所有沙箱——整個鏈條中不需要任何 .env 變更。Web UI 中的一個操作，跨整個艦隊完全傳播。
坦白的範圍（來自 PR 本身）
- 目前僅支援 Docker 後端。Modal、Daytona 和 SSH 在單獨的 PR 中推出。
- 它不保護被入侵的主機進程——真實金鑰始終存在主機環境中。
- 繞過 HTTPS 使用原始 socket 的沙箱超出範圍。
- 目前沒有原生 Windows 二進位檔。
這是針對沙箱層級的縱深防禦——不是完整的解決方案，但是該層級的正確架構。
兩個層級如何組合
Bitwarden Secrets Manager
└── One bootstrap token → N secrets in vault
└── Centralized rotation via web UI
└── Instant revocation across entire fleet
↓
--from-bitwarden
↓
iron-proxy egress firewall
└── Sandbox holds opaque tokens, not real keys
└── Credentials injected at network boundary only
└── Non-allowlisted hosts → HTTP 403
└── Cloud metadata endpoints → denied by default
└── Rotate in Bitwarden → propagates to all sandboxes
輪換憑證是在 Bitwarden 網頁應用程式中的一個操作——而這次輪換會傳播到沙箱隔離，不需要變更任何設定檔或重新部署任何東西。當你自主、大規模地運行代理人並存取真實系統時，這就是重要的操作特性。
生態系其他框架的現狀
大多數框架的模式相同：安全性是文件，而非基礎設施。根據獨立評估，CrewAI 提供大約三個安全層級（基本輸入驗證、速率限制、輸出過濾）。LangGraph 增加了約六個，包括執行緒級別的隔離和基於逾時的資源限制。兩者都沒有實現沙箱級別的憑證隔離、主機函式白名單或加密的代理人身份——這些仍然是 production 團隊的工作。
LangChain 推出了 LangSmith Sandboxes（microVM 隔離的執行環境），但那是針對程式碼執行隔離，而非框架層級的憑證管理和保護。
Hermes 填補的缺口：將憑證安全視為一等基礎設施問題，有自己的 CLI、自己的可組合架構和自己記錄的失敗模式——不是 README 中的一個章節，也不是你在部署前自己接線的東西。
為什麼這超越 Hermes 也很重要
隨著代理人變得更強大和自主，攻擊面不只是它們運行的基礎設施——而是代理人本身。一個能瀏覽網路、執行程式碼和呼叫金融 API 的代理人是一個目標，而且不只是來自外部攻擊者，也來自它處理的內容：一個惡意網頁、一個被投毒的工具結果、一個被提示注入的技能。代理人既是執行者也是潛在的攻擊載體。
將憑證安全視為開發者責任的框架，隱含假設代理人會始終按預期行為。隨著自主性增加，這個假設變得越來越難以維持。Hermes 證明了你可以將代理人安全建構為基礎設施而非策略：憑證永遠不進入沙箱，網路邊界是執行點，輪換是一個自動傳播的單一操作。
發展方向
- Secrets 路線圖的第 4 階段增加了可配置 TTL 的暫時性機密——只在特定操作期間存在的憑證，操作後自動清除。
- HashiCorp Vault 和 AWS Secrets Manager 支援已投資於這些系統的團隊。
- 增強的稽核日誌以滿足合規需求。
- Modal、Daytona 和 SSH 後端 iron-proxy 在單獨的後續 PR 中。
方向是一致的：技術堆疊的每一層都有一個適當的安全原語，而這些原語預設情況下彼此可組合。
結論
對於任何建構接觸敏感系統的代理人——金融 API、production 基礎設施、個人資料——這是值得關注的框架。
# Bitwarden is available now
hermes secrets bitwarden setup
iron-proxy 只差一個合併的 PR（NousResearch/hermes-agent#30179）。
來源：YanXbt 撰寫的文章。感謝 @NousResearch 和 @Teknium 的基礎工作。