自託管 Hermes Agent security 指南

嗨，我是 Lena。喺碰任何一個 config file 之前，我花咗大半個下午讀佢嘅 security 頁面。讀完之後，我又返去再讀一次。第一次睇，呢個 system 好似一長串 options。第二次，我先開始睇到佢嘅形狀——喺 Hermes Agent security 入面，真正重要嘅唔係某一個 "security feature"，而係一疊彼此獨立嘅 layers。每一層都假設其他層有可能會失效。

呢個 framing 比我原本以為更重要。我見過大部分 agent security writeups，讀落都似一份 tips checklist——開呢個、設嗰個 flag，咁就安全。但 Hermes 實際文件化嘅方式唔同。佢係一個 defense-in-depth model，每一層都只做一件具體工作，開咗任何單一一層，都唔能夠替代其他層。冇任何一層係完整答案。 呢句基本上就係成篇文章。

呢篇係我思考點樣 harden 一個長期運行嘅 self-hosted Hermes deployment 時寫低嘅筆記。有啲地方我都仲喺度摸索。

Hermes security model 嘅分層結構

如果你仔細讀 官方 security 頁面，佢嘅 model 大概有七個彼此獨立嘅 layers——而「獨立」呢個字喺度真係有重量。每一層都對可能出錯嘅地方有唔同假設。按一次 tool call 入面大致套用嘅順序：

• 用戶授權——gateway-level check，睇邊個可以同 agent 溝通
• 危險命令 approval——shell commands 執行前，基於 pattern 做 detection
• Tirith content scanner——基於 Rust 嘅 pre-execution scan，用嚟檢查 prompt-injection、credential exfil、terminal-injection patterns
• Runtime isolation——local vs Docker vs SSH vs Modal vs Daytona vs Singularity
• Credential filtering——為 child processes strip env vars、MCP subprocess env allowlists、output redaction
• Context file scanning——AGENTS.md、SOUL.md、.cursorrules 喺 load time 掃描 prompt injection
• Cross-session isolation——sessions 唔可以讀取彼此 state；cron paths 亦針對 traversal 做咗 hardening

我成日返返去諗呢點，因為真正 catch 到某個問題嘅 layer，唔一定係你以為應該 catch 到佢嗰一層。 一條 malicious shell command 可能俾 approval 擋住，可能俾 Tirith 擋住，亦可能俾 container 擋住——或者三個都擋住，又或者有時一個都擋唔到。所以關掉其中一層，直到出事之前都會覺得好似安全。

呢個原則其實比 agents 更早。CISA 嘅 Secure by Design joint guidance 講 secure defaults——即係 out-of-the-box configuration 應該係安全嘅，任何 deviation 都要係 explicit。Hermes 大致跟住呢個方向：approvals 預設開啟，Tirith 喺 high-security mode 下 fail closed，gateway 喺冇 allowlist 時 deny all users。問題係「大致」呢兩個字，而 deviations 係重要嘅。

危險命令 approval，以及佢幫到手嘅位置

呢一段我想講得小心啲。Approval prompts 會令人覺得安心，而呢個正正係佢容易被過度信任嘅原因。

Hermes 維護咗一組危險命令嘅 regex patterns——例如 rm -rf、DROP TABLE、fork bombs、將 curl output pipe 去 bash、kill gateway process。命中之後，用戶會被要求 approve。有三個 modes：manual（永遠問）、smart（LLM-assisted risk scoring）、off（唔問）。另外仲有 session 用嘅 /yolo，會 bypass everything。

我一直提醒自己：regex-based detection 本質上係可以被 bypass 嘅。 一條 command 可以被 obfuscate、base64-encode、拆成兩次 tool call、寫入 file 再 source。Hermes 掃描前會 normalize input（strip ANSI escapes、null bytes、NFKC Unicode），呢點堵住咗最明顯嘅 obfuscation paths。但佢始終係喺一個 open-ended attack surface 上做 pattern matching。

Hermes GitHub 最近有一份 community security audit 詳細講過呢件事。finding 唔係 Hermes unsafe——而係 default configuration is permissive，並且假設 user 會自己 harden。呢個設計選擇可以 defend。但佢亦將真正責任放咗喺負責運行 deployment 嘅人身上。

所以我而家點睇 approval：佢係用嚟 catch accidents 嘅 tripwire，唔係對抗 adversarial agent 嘅 defense。當一個有 tool access 嘅 model 以 unintentional 方式走偏——wrong path、missing flag、一條好有自信但錯嘅 command——approval 可以捉到。當 model input 真係已經 compromised，approval 就唔係應該依賴嘅 layer。Approval prompt 係 ​human-in-the-loop​​ seatbelt；container 先係 crumple zone。

Runtime isolation choices

呢度係 Hermes 真正畀你選擇嘅地方，而呢個 choice 比其他選項更有重量。terminal backend 決定咗「agent ran a command」喺物理層面實際代表咩。

• local——喺 host 上面 run commands。Default。Approval prompts active。Blast ​radius​​ 就係 host。
• docker——commands 喺 container 入面 run，read-only root、dropped capabilities，CPU/memory/disk 可配置。Dangerous command checks 會 unconditionally skipped，因為 container 本身就係 boundary。
• ssh——喺 remote machine 上 run commands。適合將 agent 完全移離你部 laptop。
• modal 同 daytona——serverless backends，idle 時 hibernate。Container-class isolation，near-zero idle cost。
• singularity——用於冇 Docker 嘅 HPC environments。

有幾件事值得抽出嚟講。approval prompts 嘅 "container bypass" 係刻意設計——team 嘅 reasoning 係，如果 container hold 得住，內部 regex check 就係 redundant；如果 container fail，regex 本來都救唔到你。我都要諗咗一陣，先同意呢個邏輯。

如果你揀 Docker，Hermes config 暴露嘅 hardening levers 同 Docker 官方 engine security docs 入面嘅 standard practices 好接近——namespace isolation、dropped capabilities、read-only root、resource limits。Default Hermes Docker image 已經開咗呢啲。大家最易犯嘅錯，係又將嘢加返入去。 terminal.docker_forward_env 就係最明顯嗰個：你 forward 入 container 嘅每一個 variable，agent 都可以讀到同 exfiltrate。Default allowlist 係 empty，我會保持咁樣，除非係 task-specific tokens。

Persistent vs ephemeral mode 係另一個 fork。Persistent 會將 workspace directory bind-mount 到多次 runs 之間，所以 agent 可以 build state——對 development 有用。Ephemeral 用 tmpfs，所以 container stop 之後所有嘢都會消失——更適合接近 production 嘅場景。點揀就睇你可唔可以接受一個 malicious file 喺 ~/.hermes/sandboxes/ 入面住一星期，然後你先發現。

Messaging 同 MCP security boundaries

當 Hermes 作為 gateway 運行，「邊個可以同佢講嘢」就變成一個真正問題。Authorization model 係 layered：per-platform allow-all flags、DM pairing approved list、platform allowlists、global allowlist。如果呢啲都冇配置，default 就係 deny everyone，並且 startup warning。呢個 default 係啱嘅——而有啲 self-host guides 會教 users 為咗 testing 設 GATEWAY_ALLOW_ALL_USERS=true，之後又唔記得 undo，呢件事本身就係一類 incident。

DM pairing 係我一直推薦畀人嘅部分。唔需要你維護 Telegram/Discord IDs list，unknown user 會收到一個 one-time pairing code，然後你喺 CLI 用 hermes pairing approve telegram ABC12DEF approve。Hermes docs 提到，呢個 design 借鑑咗 OWASP 同 NIST SP 800-63 digital identity guidance——codes 係 one-time、time-bounded，而 approval action 係 explicit。佢唔新奇，但代表 access decisions 係由一個真實人類望住 request 作出，而唔係預先 edit config files。

MCP 完全係另一個 surface。我花最長時間先 internalize 到嘅一點：Hermes 入面嘅 MCP tool，擁有嘅係佢背後 server 嘅 permissions，而唔係 agent 嘅 permissions。 呢個正正係 protocol 嘅重點，但亦代表每一個 connected MCP server 都係一次獨立嘅 trust decision。

Hermes 嘅 MCP config reference 記錄咗兩個我而家視為 non-optional 嘅 protections。第一，environment filtering：default 只有 PATH、HOME、USER、LANG、LC_ALL、TERM、SHELL、TMPDIR 同 XDG_* 會 pass through 畀 MCP stdio subprocesses。其他所有嘢——API keys、tokens——都會被 strip。真正需要嘅 variables，要放喺 server explicit env block 入面。第二，per-server tool filtering，用 include 同 exclude：如果一個 server expose 20 個 tools，而 agent 只需要 3 個，就 allowlist 嗰 3 個。

第三個唔係 config，而係 discipline。Context files（AGENTS.md、SOUL.md、.cursorrules）喺被 load 入 system prompt 之前，會先掃描 prompt injection patterns。呢一層處理嘅就係 OWASP's LLM Top 10 稱為 indirect prompt injection 嘅問題——instructions 藏喺 model 被要求閱讀嘅 content 入面。scanner 唔係 complete defense（呢個 category 入面冇嘢係），但呢個 check 放喺呢度係啱嘅，而且 default on。

Hardening 一個 self-hosted Hermes deployment

以下係我最後用落嘅幾個 patterns，按大致 priority order：

用 non-root user 運行，只喺 required 嘅地方配置 passwordless ​sudo​​。 Hermes installer 假設係咁；security model 亦假設係咁。唔好用 root run gateway。

揀 runtime isolation 要跟你嘅 trust model，而唔係跟 convenience。 對於一部主要跑 scheduled jobs 同回覆 messages 嘅 server，Docker backend 加 empty docker_forward_env、ephemeral workspace、minimal mounted volumes，係悶但正確嘅選擇。Local backend 喺 personal laptop 上合理，因為你會望住每個 approval prompt；但喺一部你冇 actively staring at 嘅 VPS 上，佢係較差嘅 default。

唔好將 secrets 放入 broad scopes。 Provider API keys 同 gateway tokens 放喺 ~/.hermes/.env，permissions 係 0600。佢哋永遠唔應該喺 env_passthrough，亦永遠唔應該喺 docker_forward_env。MCP servers 只應該得到佢哋 env block explicit named 嘅 variables。

明確配置 user authorization。 要嘛用你真正想授權嘅 user IDs 設 platform allowlists，要嘛用 DM pairing。永遠唔好喺 production environment 留低 ​GATEWAY_ALLOW_ALL_USERS=true​​——嗰個係 testing flag。

Audit 你關掉咗嘅 layers。 approvals.mode: off 同 /yolo 存在有原因——CI runs、sandboxed test environments——但如果任何一個喺你嘅 live config 入面，寫低點解。tirith_enabled: false 都一樣。價值唔係佢哋有冇開，而係你能唔能夠回答點解佢哋冇開。

Update discipline 比 initial config 更重要。 Hermes 發版頻密，而且 security improvements 幾乎喺每個 recent release 都有落地——secret-exfil blocking、expanded credential directory protections、broader token redaction patterns、browser URL exfil blocks。一個六個月冇更新嘅 install，就算當初設得幾小心，都已經係更差嘅 install。

我會繼續 refine 呢套理解。有啲 layers 我仲未完全明——Tirith verdict-to-approval handoff 係其中一個我想花更多時間睇嘅位，而我亦未對自己長期運行嘅 deployment 做過一次真正 audit pass。我相當確定嘅係，layered model 係啱嘅，而且冇任何單一 layer 係完整答案。 如果一篇 writeup 話可以畀你 one trick，佢大概係錯嘅。

FAQ

​我應唔應該用 ​approvals.mode: off​？

只應該喺 container 或 sandbox 入面，而且係 container 做緊實際 isolation 工作時用。喺 local backend 上，唔好。

Docker backend 可唔可以完全替代 approval prompts？

對 host-level damage 嚟講，大致可以——所以 container backend active 時 approval 會被 bypass。但佢 唔係 credential filtering 或 MCP boundaries 嘅替代品。

​YOLO​​ mode 實際上 disable 咗咩？

Current session 嘅 dangerous command approval prompts。佢唔會 disable Tirith、container isolation、gateway authorization 或 env filtering。

我點樣知道 ​env​​ vars 入面邊啲會俾 ​MCP​​ subprocesses 見到？

只有 PATH、HOME、USER、LANG、LC_ALL、TERM、SHELL、TMPDIR、XDG_*，同 server explicit env block 入面嘅任何嘢。其他全部會被 strip。

有冇 managed ​Hermes​​ 可以幫我處理呢啲？

有 providers 提供 one-click deployments。佢哋處理 install——但唔會替你決定邊個可以同你個 bot 講嘢，或者你啲 MCP servers 可以讀咩。呢啲決策仍然要係你自己嘅。

等我喺自己 setup 上花更多時間，我會再返嚟睇呢個問題。暫時，呢個就係我目前嘅理解。

Previous Posts:

• 如果你設定緊多個 scheduled tasks，可以先了解 Hermes Cron Memory & Context Limits 點樣影響你嘅 cron jobs。
• 如果你 troubleshooting overlapping runs 或 slow execution，可以睇呢篇 ​Safe Hermes MCP Setup for Cron Jobs。
• 想深入了解點樣用清晰 prompts 同 instructions 改善 agent behavior：How to Write Effective Hermes Agent Skills
• 諗緊自動化 real-time monitoring？呢篇 guide 會幫到你：Periodic Health Check Cron Jobs with Hermes
• 需要 optimize cron delivery，令 results 更穩定？可以繼續讀 Managing Agent Capabilities and Tool Access