Hermes Agent 是 Nous Research 推出的開源 AI Agent 框架，支援終端機操作、程式碼執行、檔案讀寫、網頁瀏覽等功能，可透過 CLI、Telegram、Discord 等多平台使用。在開源 AI Agent 社群中受到廣泛關注。
品得網絡的技術顧問團隊針對 Hermes Agent v0.8.0 原始碼進行了完整的安全審查，發現 2 個 CRITICAL、3 個 HIGH、3 個 MEDIUM 等級的安全風險。以下是完整的分析報告。
CRITICAL #1：API 金鑰明文儲存
Hermes Agent 將使用者的 API Key（包括 OpenAI、Anthropic、以及 Telegram / Discord Bot Token）以純文字 JSON 檔案儲存在本機磁碟上，路徑為 ~/.hermes/ 目錄。
技術細節：
- OAuth token 存於
~/.hermes/.anthropic_oauth.json - 僅靠作業系統檔案權限（0600）保護
- 未整合任何作業系統金鑰管理（如 macOS Keychain、Windows Credential Manager）
- Log 檔案的敏感資訊遮蔽採用 regex 比對，存在遺漏風險
影響評估：若攻擊者取得該機器的檔案存取權（無論是實體接觸、遠端入侵或惡意軟體），即可直接取得所有 API 金鑰。這意味著攻擊者能以受害者的身份呼叫 AI 服務、存取連接的通訊平台，造成財務損失和資料外洩。
CRITICAL #2：任意程式碼執行，無沙盒隔離
Hermes Agent 的 terminal_tool 和 code_execution_tool 允許 AI 在使用者的作業系統上直接執行任何 shell 指令和 Python 程式碼，唯一的限制是 5 分鐘的 timeout。
技術細節：
- 沒有沙盒（sandbox）隔離機制
- 沒有指令白名單或黑名單
- 沒有檔案系統存取範圍限制
- AI 的操作權限等同於執行 Hermes Agent 的使用者帳號
影響評估：若 AI 被 Prompt 注入攻擊誤導，可能執行刪除檔案、安裝後門程式、竊取資料等惡意操作。與 Claude Code 的「每步確認」機制相比，Hermes Agent 在這方面缺乏安全防線。
HIGH #1：Prompt 注入偵測機制薄弱
Hermes Agent 的 Prompt 注入防護採用基於正則表達式（regex）的關鍵字比對。這種方式只能攔截最基礎的注入攻擊模式，對於語意變形、Unicode 編碼、多語言混合等進階攻擊手法幾乎無效。
風險場景：攻擊者可以在網頁、PDF、或其他文件中嵌入經過變形的惡意指令。當 AI Agent 讀取這些文件時，就可能被「洗腦」執行非預期操作。
HIGH #2：無角色權限控管（RBAC）
Hermes Agent 的存取控制僅區分「允許」和「不允許」，所有被允許的使用者都擁有完整的操作權限。沒有「唯讀」、「限制操作」或「管理員」等角色分級。
風險場景：在 Telegram 群組場景中，群組內的每個成員都能讓 Agent 執行任何操作，包括存取檔案、執行指令、切換 AI 供應商。對企業而言，這意味著無法實現最小權限原則（Least Privilege）。
HIGH #3：AI Provider 自動切換無通知
Hermes Agent 內建了 Provider Fallback 機制：當主要的 AI 供應商（如 Claude）發生錯誤時，系統會自動切換到備用供應商，且不通知使用者。
風險場景：使用者原本選擇 Claude 作為 AI 後端，是基於對其安全性和隱私政策的信任。若系統靜默切換到另一家供應商，使用者的對話內容（可能包含商業機密）就在不知情的情況下被傳送到第三方。
MEDIUM 等級風險
Session 與記憶資料未加密
所有對話紀錄儲存在 SQLite 資料庫和 JSONL 檔案中，均為明文。Agent 的自我改進訓練資料（trajectory files）同樣以明文保存。若設備遺失或被盜，所有歷史對話將完全暴露。
供應鏈安全風險
專案依賴 20 個以上的外部套件，但 requirements.txt 未固定版本 hash。Docker image 包含開發工具（不應出現在 production 環境）。這意味著依賴套件被植入後門的攻擊面是存在的。
SSRF 與網路安全
瀏覽器自動化功能（Playwright）的 URL 安全檢查存在漏洞，可透過 DNS Rebinding 技術繞過。攻擊者可能誘導 Agent 存取內部網路資源。
風險威脅矩陣
| 威脅 | 影響程度 | 發生可能性 | 風險等級 |
|---|---|---|---|
| API 金鑰明文儲存 | 極高 | 中 | CRITICAL |
| 任意程式碼執行 | 極高 | 中 | CRITICAL |
| Prompt 注入偵測不足 | 高 | 中 | HIGH |
| 無角色權限控管 | 高 | 低 | HIGH |
| Provider 自動切換 | 高 | 中 | HIGH |
| Session 資料未加密 | 中 | 低 | MEDIUM |
| 供應鏈安全風險 | 高 | 低 | MEDIUM |
| SSRF 攻擊面 | 高 | 低 | MEDIUM |
與商業 AI Agent 的安全性比較
以 Claude Code 為例，商業級 AI Agent 在安全性上有幾個關鍵差異：
- 操作確認機制：Claude Code 每個敏感操作都會跳出確認框，使用者可以審核後才執行
- 權限分級：支援不同層級的操作許可（自動允許 / 需確認 / 禁止）
- 資料隔離：雲端處理不會在本機留下明文 session 檔案
- 供應商鎖定：不會靜默切換 AI 後端
這不代表商業產品完美無缺，但在安全基線上確實比開源框架高出不少。更多平台之間的安全性比較，可以參考我們先前的AI Agent 三大平台安全性深度比較。
結語
Hermes Agent 是一個功能豐富的開源 AI Agent 框架，展現了 AI Agent 技術的巨大潛力。但從企業安全的角度來看，目前的版本尚未達到企業級部署的安全標準。
建議有興趣的技術團隊在完全隔離的環境中進行評估，並持續關注社群的安全修復更新。
下一篇：老闆看得懂的 AI Agent 風險報告——同樣的資安發現，用決策者聽得懂的語言重新說一遍。
本文基於 2026 年 4 月對 Hermes Agent v0.8.0 原始碼的獨立安全審查。如需企業 AI 導入安全評估服務，歡迎聯繫品得網絡。
Hermes Agent 有哪些 CRITICAL 等級的安全漏洞？
Hermes Agent v0.8.0 有兩個 CRITICAL 漏洞：(1) API 金鑰以明文 JSON 儲存在本機磁碟，未整合 OS Keychain 或加密機制；(2) terminal_tool 和 code_execution_tool 允許 AI 在無沙盒隔離的環境下執行任意 shell 指令和 Python 程式碼。
Hermes Agent 的 Prompt 注入防護有效嗎？
Hermes Agent 採用基於正則表達式（regex）的關鍵字比對來偵測 Prompt 注入，這種方式只能攔截最基礎的攻擊模式，對語意變形、Unicode 編碼、多語言混合等進階手法幾乎無效，被評為 HIGH 風險。
Hermes Agent 跟 Claude Code 在安全性上差在哪？
Claude Code 每個敏感操作都會跳出確認框讓使用者審核、支援不同層級的操作許可、雲端處理不留明文 session、不會靜默切換 AI 後端。Hermes Agent 在這四個面向都缺乏對應的安全機制。
