Hermes Agent を読み解く — セキュリティと安全運用
連載「Hermes Agent を読み解く」第10回（最終回）。
連載「Hermes Agent を読み解く」全10回
はじめに — 便利さの裏側を清算する
ここまで 9 回、Hermes の能力を称えてきた。会話ループ、記憶の再注入、71 のツール、マルチエージェント、Kanban、40 超の露出面、拡張機構。だがこれらはすべて諸刃だ。ツールを呼べるエージェントは、間違ったツールを呼ぶこともできる。多面に開かれたコアは、多面から攻撃されうる。最終回は、これまで「第10回で」と先送りしてきたリスクを清算し、安全運用の指針をまとめる。
1. 脅威モデル
SECURITY.md が中心に据える脅威は、プロンプトインジェクションだ。信頼できない入力（Web ページ、受信メッセージ、ツールの戻り値）の中に、エージェントへの命令が紛れ込み、それが破壊的なコマンド実行につながる——これが最大の懸念。
ここで重要な設計思想がある。Hermes のプロセス内ヒューリスティクス（第5回の DANGEROUS_PATTERNS など）は、「境界（security boundary）ではなく事故防止（accident prevention）」と位置づけられている。つまり「rm -rf を弾く」のは、悪意ある攻撃者を止める防壁としてではなく、エージェントのうっかりを減らす安全装置として設計されている。本気の攻撃者を前提とした境界は、プロセスの外（OS 権限、コンテナ、ネットワーク分離）で引くべき——という割り切りだ。この区別を誤解すると「Hermes がパターンマッチしてるから安全」と過信して事故る。
2. リスク表
| リスク | 内容 |
|---|---|
| 平文資格情報 |
.env / auth.json が平文（第1回）。読まれれば全鍵が漏れる |
--yolo |
全承認をスキップ（第5回）。プロンプトインジェクションと組み合わさると最悪 |
| 署名なし自動更新 |
hermes update が署名検証なしだと、更新経路が攻撃面になる |
| 公開バインド | Gateway を 0.0.0.0 で晒す、API をループバック外に出す（第8回） |
最も危険な組み合わせは --yolo × プロンプトインジェクションだ。承認ゲートを全部外した状態で、悪意ある入力に「rm -rf ~ を実行せよ」と書かれていたら、止めるものが無い。--yolo は「事故防止すら切る」スイッチだと理解すべきだ。
3. 安全運用チェックリスト（8 項目）
実運用で最低限守るべき 8 項目。
-
chmod 600—.env/auth.jsonの権限を所有者のみに絞る -
yolo 無効 —
--yoloを常用しない。承認は面倒でも残す -
gateway ループバック — OpenAI 互換 API は
127.0.0.1のまま。外に出すなら認証必須 - スキル / プラグインのレビュー — 第9回の 4 ソース、特に user / project / pip を入れる前に中身を読む
-
terminal バックエンド隔離 — シェル実行はコンテナや専用ユーザーに隔離。
HERMES_HOMEプロファイル分離（第9回）も活用 -
更新レビュー —
hermes updateの差分を確認してから適用。rolling main は 1 日で大きく動く - allowlist — ツールやコマンドは許可リスト方式で絞る
-
ログ監視 —
~/.hermes/logsを監視し、想定外のツール実行を検知
このリストは「Hermes が信用できない」から作るのではない。エージェントに terminal や computer_use を握らせる以上、人間側が境界を引く責任がある、という話だ。第1節の「ヒューリスティクスは境界ではない」がここに効いてくる。
4. コード品質の総括 — 連載を閉じる
10 回を通じて Hermes のコードを読んできた。最後に総括する。
巨大モノリス vs モジュール化の同居。gateway/run.py は 19,741 行、cli.py は 15,994 行、conversation_loop.py は 4,836 行——主要ファイルは軒並み巨大だ。一方で tools/ は 1 ツール 1 ファイルに近く、plugins/ の kind 別ロードや MemoryProvider ABC のように、拡張点はきれいに抽象化されている。**「コアは太く、辺縁は疎結合」**という構造で、読みやすさと一枚岩の重さが同居している。
承認のヒューリスティック依存。第5回・本回で見たとおり、安全機構の多くがパターンマッチに頼る。これは「事故防止」としては妥当だが、「境界」と取り違えてはいけない——設計者自身がそう明言している点は誠実だ。
新旧 CLI の併存。cli.py（15,994 行）と hermes_cli/main.py（15,674 行）が併存している。移行途上の名残で、rolling main を読むときの混乱の一因でもある（第1回のバージョン三層問題と同根の「動き続けるコードベース」の宿命だ）。
連載を終えて — 人格 = 知能 × 記憶
第4回で掲げたテーゼに戻る。人格 = 知能 × 記憶。
Hermes のコードを 10 回かけて読んで確信したのは、エージェントの「らしさ」はモデル（知能）だけでは決まらない、ということだ。会話を畳む圧縮、それを引き戻す記憶の再注入、SOUL.md の種、プロファイルによる文脈の分離——これらが組み合わさって初めて、揮発する context の上に連続した人格が立ち上がる。
そして最終回の主題だったセキュリティは、その人格に境界を与える営みだ。何でもできるエージェントは、何をすべきでないかを人間が決めなければ危うい。知能と記憶が人格を作り、境界がそれを安全に世界へ接続する。
自分のエージェントの中身を読むとは、結局、自分が何を任せ、何を任せないかを決めることだった。この連載が、読者自身の「箱の中」を覗く一助になれば幸いだ。
連載第1回はこちら
対応マップ章: §7, §8 / 行番号は hermes update でずれうる
クイックイタレート株式会社
IoT / 電力監視 / AI / 衛星・無線通信 / システムインテグレーション/
ローカル LLM・エージェント基盤に関するお問い合わせはお気軽にどうぞ。