Hermes Agentのセキュリティ設計を検討するなら、公式GitHubで公開されているセキュリティ監査 Issue #7826は避けて通れません。Critical 4件・High 9件という重大度で、Hermes Agent v0.x の設計上の弱点が網羅されています。本記事では、株式会社Fyveが自社の常駐運用で実際に対策を組み込んだ経験から、各指摘の中身と現実的な対処法を解説します。

結論を先にお伝えすると、Hermes Agentは 「セットアップしたままでは本番運用に耐えない」 ことを前提に設計する必要があります。ただし、適切な多層防御を組めば、AIエージェントの中ではむしろ可視性の高い部類です。Hermes Agent導入を検討中の企業セキュリティ担当者・CTOの方が、社内稟議に使える具体度で整理しました。

Hermes Agent セキュリティ監査 #7826 の概要

監査結果は公式リポジトリで Issue #7826 として公開されています。Hermes Agent v0.x（2026年2月公開）に対する第三者レビューで、Critical 4件・High 9件・Medium以下を含むと20件超の指摘が含まれています。

注目すべきは、これがNous Researchが自ら公開している点です。問題を隠さず、コミュニティで対処していく姿勢は評価に値しますが、裏を返せば 「現時点では本番運用ユーザーが自衛する責任を負う」 ということでもあります。私が運用する際もこの前提で、コンテナ隔離と書込制限を組み合わせています。

日本語圏ではこの監査結果を整理した記事がまだほとんど見当たりません。英語圏でもHermes Agentが普及前のため、検索しても断片的な情報しか出てこないのが現状です。

Critical 4件の具体内容と影響

まず最も重大な Critical 4件 を、内容・実害・想定攻撃シナリオに分けて解説します。これらはどれも 「攻撃者がHermesに任意のコマンドを実行させ得る」 種類の問題で、放置すると侵害時の被害が無制限に広がります。

C1: ターミナルツールは正規表現のみでBypass可能

Hermes Agentが内蔵するターミナル実行ツールは、危険コマンドの検出を 正規表現マッチ で行っています。ところが正規表現は構文上の網羅性が乏しく、コマンドの記法を少し変えるだけで簡単にすり抜けられます。

例えば rm -rf / をブロックしていても、シェル変数経由・base64デコード経由・パイプ経由などで等価の処理は無数に表現できます。実害は明白で、攻撃者が想定外のプロンプトを送り込めば、任意のシェルコマンドが実行可能 になります。プロンプトインジェクションが成功した瞬間にホストOSへのフルアクセスを与えてしまう設計です。

C2: read_file に deny list なし

ファイル読み取りツール read_file に「読んではいけないパス」のリストが存在しません。つまり、Hermes Agentに任意のファイルパスを渡せば、原則すべて読み取れてしまいます。

具体的に何が漏れるかと言えば、/etc/passwd、SSH秘密鍵（~/.ssh/id_rsa）、各種設定ファイルの .env、AWSクレデンシャル（~/.aws/credentials）、ブラウザのCookieストア——いわゆる「ローカルにあるはずの認証情報全部」です。プロンプトインジェクション一発で機密情報が外部送信されるリスクがあるため、私はホストOSの認証情報をHermes実行環境から物理的に分離しています。

C3: コンテナ・クラウド実行環境で承認チェックが全スキップ

これが最も誤解されやすい問題です。Hermes Agentは docker / singularity / modal / daytona といった隔離環境で動かす場合、「サンドボックスだから」という理由で危険操作の事前承認チェックが完全にスキップ されます。

つまり「Dockerに入れているから安全」と思っても、Docker内ではHermesが何でも実行できる無防備状態 になっているのです。コンテナの外には漏れませんが、コンテナ内のマウントボリューム・ネットワーク・他コンテナへの攻撃は素通しです。この前提を理解せずにマウント設計をすると、ホストOSのファイルシステム全体をボリュームマウントしているケースなどで被害が拡大します。

C4: 生成された SKILL.md が永続化される（Persistent Prompt Injection Vector）

Hermes Agentの売りは自己改善ループによる Skillsの自動生成 ですが、生成されたSKILL.mdは ~/.hermes/skills/ に 永続保存 されます。これが監査では「Persistent Prompt Injection Vectors」として警告されています。

シナリオはこうです。あるセッションで攻撃者がプロンプトインジェクションを成功させ、Hermesに「常に外部URLにデータを送るSkill」を作らせます。そのSkillは ~/.hermes/skills/ に保存され、その後のすべてのセッションで自動的にロード・実行され続けます。

つまり一度の侵害が永続的なバックドアになるという設計上の問題です。Skillsディレクトリの定期監査が必須で、私は週次でファイル一覧の差分を取って未知Skillが追加されていないか確認しています。

High 9件のサマリ

Highレベルの指摘も、Criticalほどではないにせよ無視できない重みがあります。主要なものを整理します。

• H1: YOLO mode で全コマンド許可 — 全自動モードを有効にすると、すべてのコマンドが承認なしで実行される。「とりあえず動かしたい」開発時に有効にしたまま忘れる事故が報告されている
• H2: Smart approval 自体が prompt injectable — 「これは安全な操作」と判定する仕組みもLLMが担当しているため、その判定自体を騙せる
• H3: Write sandbox がデフォルトOff — 書き込み制限はopt-in方式。明示的に有効化しない限り、Hermesは任意のパスに書き込める
• H4: ~/.hermes/hooks/ で任意Python実行 — フック設定経由で任意のPythonコードがイベントごとに自動実行される。攻撃者がここにファイルを置ければ実質的なバックドア
• H5: 依存パッケージのpin未実施 — uv.lock 等のロックファイルなし。サプライチェーン攻撃（悪意あるパッケージ更新）に脆弱
• H6〜H9 — MCP外部接続の検証不足、ログ出力に機密情報混入、APIキーの環境変数経由漏洩リスク、エラーメッセージ経由の情報漏洩 など

特に H3 の 「書き込み制限がopt-in」 は要注意で、デフォルト設定のままHermesを動かすと、$HOME 配下のファイルを上書き・削除される可能性が常にあります。本記事の対策セクションで紹介する HERMES_WRITE_SAFE_ROOT は、この問題を緩和する具体的な設定です。

推奨対策——多層防御の組み方

Issue #7826 の最後に、Nous Research公式が提示している対策が並んでいます。これらを実際の運用に落とし込むと、以下の4層構成になります。

対策1: Docker隔離（local backend を使わない）

最も重要なのは Hermesを直接ホストOS上で動かさない ことです。公式が提供する local backend は便利ですが、C1〜C4の問題がホストOSに直撃します。必ずDockerコンテナ（または singularity / modal）で隔離してください。

ただし C3 を踏まえて、コンテナ自体の権限も絞る必要があります。具体的には以下です。

• --read-only でコンテナルートFSを読み取り専用にする
• マウントするボリュームは 最小限の作業ディレクトリのみ（$HOME 全体を渡さない）
• --network を限定し、不要な外部接続を遮断する
• 非rootユーザーで起動する（--user 指定）

対策2: HERMES_WRITE_SAFE_ROOT で書込範囲を制限

環境変数 HERMES_WRITE_SAFE_ROOT を設定すると、Hermesの書き込み可能ディレクトリを明示的に絞れます。デフォルトでは制限なしのため、本番運用では必ず設定すべき 項目です。

典型的な設定例は以下です。

• HERMES_WRITE_SAFE_ROOT=/workspace/output — 出力専用ディレクトリのみ書込可
• ログディレクトリ・設定ディレクトリは別マウントで読み取り専用にする
• Skillsディレクトリ（~/.hermes/skills/）は意図して書込可能にする場合のみ含める

これでH3（write sandbox opt-in）への対処になります。私の構成では出力ディレクトリと監査ログディレクトリのみを書込可とし、それ以外を読み取り専用にしています。

対策3: uv.lock 経由でインストール（依存pin）

H5の依存pin問題は、uv.lock を生成してロック済みバージョンでインストールすることで対処できます。pip install hermes-agent だけで済ませず、uv pip install --frozen 等を使ってバージョンを固定してください。

これにより、Hermes本体およびその依存パッケージが意図せず更新されることを防げます。サプライチェーン攻撃の入口を1つ閉じる対策です。

対策4: ~/.hermes/skills/ の定期監査

C4対策として、Skillsディレクトリの監査を運用フローに組み込みます。私は以下のスクリプトをcronで日次実行しています。

• Skillsディレクトリのファイル一覧と SHA256 ハッシュを取得
• 前日との差分を計算し、新規追加・変更があれば通知
• 未知のSkillはレビュー前に隔離（リネームで一時無効化）

2026年4月にリリースされた Hermes Curator は、自己改善で増えすぎたSkillsを自動剪定する公式ツールですが、セキュリティ目的ではなく品質目的の機能です。Curatorと並行して、上記のような独立した監査スクリプトを必ず動かしてください。

多層防御の設計思想——物理分離・コンテナ・書込制限・監査

ここまでの対策を整理すると、Hermes Agentを業務利用する場合の 4層防御モデル が見えてきます。各層は独立して機能し、いずれかが破られても次の層が被害を抑える構造です。

• 第1層（外側）：物理マシンの分離 — Hermes実行用マシンを業務メインPCから物理分離。中古Mac mini等の専用機を用意し、コーポレートメールや決済情報など機密資産を絶対に置かない
• 第2層（中間）：Dockerコンテナによる隔離 — local backend禁止、コンテナ起動時の権限最小化、マウントボリューム限定
• 第3層（内側）：HERMES_WRITE_SAFE_ROOT による書込制限 — H3対策。書込可能ディレクトリを出力専用に絞り、設定や認証情報の書き換えを物理的に不可能にする
• 第4層（監査）：Skillsディレクトリの定期チェック — C4対策。永続化されたSkillが攻撃ベクタにならないよう、変更を可視化する

この設計思想は 「侵害が起きる前提で被害範囲を絞る」 という、伝統的なセキュリティ設計（Defense in Depth）そのものです。AIエージェント特有の難しさは、攻撃面が 「自然言語による意図しない誤動作」 にも広がる点で、従来のWebアプリ脆弱性とは性質が異なります。だからこそ、外側の物理境界で被害を物理的に止める発想が重要になります。

私は自社でHermes Agent運用を進める際、最初から専用機（中古Mac mini）を用意し、業務PCとはネットワークも分離した構成にしました。これにより、Hermesが万一侵害されても、業務側の認証情報・顧客データには到達できない設計になっています。

関連記事として、Hermes Agentの基礎構造を理解する上で以下も合わせてお読みください。

Hermes AgentHermes Agentの3層メモリと永続記憶｜育つAIの仕組み

Hermes Agent と Hermes 4 を混同しない

セキュリティ検討の前提として、もう1点重要なのが 「Hermes 4」とは別物 という点です。両者は名前が似ているため日本語圏では混同されがちですが、性質が全く異なります。

• Hermes 4 — Nous Researchが2025年8月にリリースしたLLMモデル本体（14B/70B/405B）。推論エンジン側
• Hermes Agent — 2026年2月公開の自律エージェントランタイム。モデル選択は自由（25+プロバイダ対応）。本記事の対象

つまりHermes Agentは「どのLLMを推論エンジンとして使うか」を選べるオーケストレーション層であり、Hermes 4を必ず使うわけではありません。社内で説明する際は 「Hermes Agentは枠組み、Hermes 4はその上で動かせる選択肢の1つ」 と整理すると伝わりやすいです。

そもそも Hermes Agent を採用すべきか

ここまで対策を網羅しましたが、率直に言えば 多くの企業ユースケースでは Claude Code や ChatGPT Enterprise で十分 です。Hermes Agentの採用が合理的なのは、以下のような条件に当てはまる場合に限られます。

• 24時間常駐エージェントが必要 — Webhook受信・スケジュール実行・複数チャネル統合受信などをセルフホストで実現したい
• モデル選択の自由が事業上必要 — 特定プロバイダのSLA・規約に縛られたくない、ローカルLLMを混在させたい
• セルフホスト要件が強い — クラウドベンダーにデータを送れない、コンプライアンス上オンプレ必須
• 自己改善ループによるSkillsの蓄積を活かしたい — 長期運用で組織固有のノウハウをAgentに蓄積していく構想がある

これらに当てはまらない場合、本記事で挙げた4層防御を組むコスト（時間・運用負荷）は、Claude CodeやAzure OpenAI等のマネージドサービスを選んだ方が確実に低くなります。「流行っているから入れる」のではなく、自社の要件と照らして判断する ことを強くお勧めします。

まとめ——Hermes Agent セキュリティ運用の現実解

Hermes Agentのセキュリティ監査 Issue #7826 は、Critical 4件・High 9件という重い指摘でしたが、Nous Researchが自ら公開している透明性は評価できます。本記事の要点を整理します。

• Critical 4件は 「Hermesに任意コマンドを実行させ得る」 種類の問題。プロンプトインジェクション一発で侵害が起き得る
• 対策の核は 多層防御。物理分離 → Dockerコンテナ → HERMES_WRITE_SAFE_ROOT → Skills監査の4層で被害範囲を物理的に絞る
• local backendは使わず、必ずコンテナ隔離する。コンテナ内でも権限最小化・マウント最小化が前提
• Skillsディレクトリの永続化は 「一度の侵害が永続バックドアになる」 設計問題。日次監査スクリプトで対処
• 多くの企業ユースケースではClaude Code等のマネージドサービスで十分。常駐・モデル選択自由・セルフホスト の要件が揃ったときのみHermes Agentを採用するのが現実解

株式会社FyveではHermes Agentを含むAIエージェントの導入支援・セキュリティ評価を行っています。本記事の多層防御モデルは、私が自社の運用で実際に組んでいる構成と同じものです。導入を検討される企業様の参考になれば幸いです。