Hermes Agentの危険性｜企業導入のセキュリティ対策【2026】

結論: Hermes Agentは「サーバーに常駐し続け、権限を持ったまま自己改善していく」設計そのものが攻撃対象領域を広げており、コミュニティ独立監査ではデフォルト設定でCritical（重大）4件・High（高）9件、計13件の脆弱性が指摘されています。企業が使う場合は「脆弱性を1つずつ潰す」よりも「権限最小化・実行環境の隔離・承認ゲート」を前提設計にすることが対策の本筋です。

この記事の要点:

• 要点1: 独立監査（GitHub Issue #7826、2026年4月11日公開・監査対象v0.8.0）はデフォルト設定を「ALLOW-ALL」と評価し、無制限シェル実行・承認バイパス・永続スキルへのインジェクションなど4件のCritical脆弱性を報告した
• 要点2: 監査から現行の最新版（v0.18.2、2026年7月8日リリース）までにはバージョン差があり、一部の脆弱性は修正済み・一部は設計思想として残る前提で読む必要がある
• 要点3: 公式SECURITY.mdは「エージェントプロセス内部の仕組みは境界(boundary)ではなく、OSレベルの隔離だけが唯一の防御線」と明言しており、対策の軸は個別バグ修正ではなく権限設計そのものになる

対象読者: 自律型AIエージェントを社内インフラに常駐させることを検討している情報システム部門の責任者・セキュリティ担当者・経営者

読了後にできること: 独立監査で指摘された具体的な脆弱性の内容を理解した上で、導入可否を判断するためのセキュリティチェックリストを自社にそのまま持ち帰れる

「エージェントに任せるのはいいけど、サーバーに常駐させたまま何もしていない時間も権限だけ持っている状態って、そもそも大丈夫なんですか？」

先日、ある企業のセキュリティ担当者向け研修で、この質問を受けました。Hermes Agentのように「立ち上げっぱなしで学習しながら動き続ける」タイプのOSSエージェントが話題になるたびに、必ずと言っていいほど出てくる論点です。便利さの説明はすぐ理解してもらえるのですが、「常駐している間ずっと、どこまでの権限を持っているのか」という質問には、多くの担当者が答えを持っていません。

これは無理もないことです。セッション型のChatGPTやClaude Codeであれば、使い終わればプロセスは終了し、権限もそこで切れます。しかしHermes Agentは違います。ターミナル操作・ファイル読み書き・外部サービス連携の権限を持ったまま、自己改善しながら動き続ける設計です。この「動き続ける」という一点が、通常のセキュリティレビューのやり方をそのまま当てはめにくくしています。

この記事では、Hermes Agentのコミュニティ独立監査で指摘された具体的な脆弱性、実際に採番された公開CVE、そして企業が導入前に整えるべき安全対策を、一次情報に基づいて整理します。恐怖を煽る意図はありません。リスクは正確に、対策は具体的にお伝えします。

Hermes Agentとは（おさらい）

Hermes AgentはNous Researchが2026年2月に公開したOSSの自律型AIエージェントです。セッションが終わると記憶も消えるアシスタント型とは異なり、サーバー上に常駐し続け、稼働期間が長くなるほど能力が向上する自己改善型の設計を特徴としています。仕組みや法人導入の基本については、Hermes Agentとは？法人導入完全ガイドで詳しく解説しています。本記事はその続編として、セキュリティに絞って掘り下げます。なお、Claude Codeとの違いを整理したい場合はHermes Agent vs Claude Code｜違いと選び方もあわせてご覧ください。

常駐型・自己改善型エージェントがリスクを増幅させる4つの構造

Hermes Agent固有の脆弱性を見る前に、なぜ「常駐型・自己改善型」というアーキテクチャそのものがセキュリティ上不利なのかを整理しておきます。これは公式SECURITY.mdも認めている構造的な問題です。

公式SECURITY.mdは、この4つの構造的リスクを踏まえた上で、「エージェントプロセスの内部にある承認ゲートやログのマスキングは、あくまでヒューリスティック（発見的な仕組み）であって、封じ込め機構ではない。敵対的なLLMに対する唯一のセキュリティ境界はOSである」と明記しています。つまり開発元自身が「アプリ内部の安全機構を過信しないでほしい」と述べているわけです。

独立監査が指摘した「Critical 4件・High 9件」の中身

2026年4月11日、Hermes Agent（監査対象バージョン: v0.8.0、812のPythonファイル・約36万4,000行）に対する独立したセキュリティ監査結果が、GitHub Issue #7826として公開されました。監査主体はコミュニティの第三者（ハンドルネーム表記）であり、Nous Research公式の監査ではない点に注意してください。マルウェアやデータ持ち出しの仕組みは検出されなかった一方、デフォルト設定の姿勢は「ALLOW-ALL（原則すべて許可）」と評価され、Critical 4件・High 9件、合計13件の脆弱性が報告されています。

Critical（重大）4件

High（高）9件

一方でこの監査は、良い点も具体的に評価しています。マルウェアやバックドアは検出されず、テレメトリ（外部への利用状況送信）も存在しない、APIキーは意図したプロバイダー以外に送信されない、30種類以上のAPIキーパターンをマスキングするログ冗長化処理がある、SSRF（サーバーサイドリクエストフォージェリ）対策として内部IP・クラウドメタデータエンドポイントへのアクセスをブロックしている、ファイル権限は0o600（所有者のみ読み書き可）に設定されている、サブプロセス実行時に60種類以上の環境変数から認証情報を除去している、依存関係ロックファイル（uv.lock）にSHA-256ハッシュが付与されている、といった設計は評価されています。「作り手に悪意はないが、デフォルトの姿勢が甘い」というのが、この監査の実態に近い要約です。

版差の注意: この監査対象はv0.8.0（2026年4月11日時点）です。現行の最新版はv0.18.2（2026年7月8日リリース）で、その間にStarlette依存関係のCVE対応やSSRF対策の強化、ダッシュボード認証の改善など、セキュリティ関連の修正が複数入っています。ただし、Critical/High 13件の1つひとつが現行版で個別に修正されたと確認できる一次情報は本記事執筆時点（2026年7月14日）では見当たりません。自社で導入する場合は、導入予定バージョンのコードで該当箇所（tools/approval.pyやtools/terminal_tool.pyなど）を必ず自分の目で確認してください。「監査でCritical指摘があった」という情報だけで判断せず、「自社が入れるバージョンで実際にどう動くか」を確認するのが唯一の安全な進め方です。

実際に採番された3つのCVEから見える”実害”のパターン

監査で指摘された13件とは別に、Hermes Agentには一般に公開されたCVE（Common Vulnerabilities and Exposures）が3件、NVD(National Vulnerability Database)に登録されています。監査結果が「潜在的リスクの指摘」であるのに対し、CVEは「具体的な脆弱性として確認・採番されたもの」です。

この3件から読み取れる共通パターンは、「メッセージング連携・WebUI・ファイル操作といった”エージェント本体以外の周辺機能”に穴が出やすい」ということです。エージェント本体のロジックだけでなく、外部サービスとの接続点（アダプタ）や管理画面まで含めて評価する必要があります。

プロンプトインジェクション・秘密情報・サプライチェーンという3つの構造的リスク

個別の脆弱性番号を追うだけでなく、企業として構造的に警戒すべきリスクを3つに整理します。

1. プロンプトインジェクション

C4（永続スキルへのインジェクション）が示す通り、Hermes Agentは外部からの入力（メール・チャット・Webページの内容など）を処理する過程で悪意ある指示を注入されるリスクを持ちます。厄介なのは、注入された指示が一度きりで終わらず、「スキル」として記憶され、将来のセッションでも再利用され続ける可能性がある点です。公式SECURITY.mdでも「プロンプトインジェクション単体（それが実害のあるセキュリティ結果に繋がらない場合）」は脆弱性報告の対象外(out-of-scope)と明記されており、”起きうる前提”で運用設計するしかない領域だと理解しておく必要があります。

2. 秘密情報の扱い

監査ではAPIキーの意図しない送信は確認されなかった一方、C2（無制限ファイル読み取り）はSSH秘密鍵等への到達可能性を指摘しています。エージェントが複数のLLMプロバイダー・メッセージングサービスと連携する構成では、認証情報の保管場所（環境変数・設定ファイル・メモリストア）が分散しやすく、1箇所の設計ミスが全体の秘密情報漏洩につながります。

3. サプライチェーン（OSS依存関係）

H9（Git依存関係のコミット未固定）は、企業のセキュリティレビューで見落とされがちな論点です。バージョン番号を固定していても、Git経由の依存が「最新のコミット」を指していると、依存先が改ざんされた瞬間に自社環境へ取り込まれてしまいます。加えてHermes Agentには「スキルマーケットプレイス」のようなコミュニティ製の拡張を取り込む仕組みもあり、npm等のパッケージレジストリと同様に、レビューされていないサードパーティコードを実行環境に持ち込むリスクとして扱うべきです。

企業が導入前に整えるべき7つの安全対策

ここまでの脆弱性・リスクを踏まえ、企業が実務として整えるべき対策を7つにまとめます。個別のバグ修正を待つのではなく、「攻撃されても被害が広がらない設計」を先に作ることが本筋です。

これらを社内で実務に落とし込む際、AIに叩き台を作らせると早いです。以下、実際に使えるプロンプトを5つ紹介します。

プロンプト1：導入前セキュリティ評価の質問リストを作る

Hermes Agent（Nous Research製のOSS自律AIエージェント）を自社に導入するかどうかを判断するための、セキュリティ評価用の質問リストを作成してください。
評価対象領域は「実行権限の範囲」「ファイルアクセス制御」「外部送信の承認フロー」「秘密情報の保管方法」「サードパーティ拡張のレビュー体制」の5つです。
各領域について、情シス担当者が導入判断会議で使えるYes/No形式の質問を3つずつ、計15問作成してください。
不足している情報があれば、最初に質問してから作業を開始してください。仮定した点は必ず"仮定"と明記してください。

プロンプト2：権限最小化ポリシーの叩き台を作る

常駐型AIエージェントの権限最小化ポリシーの叩き台を作成してください。
対象は「シェルコマンド実行権限」「ファイル書き込み範囲」「外部API・メッセージング連携」の3項目です。
それぞれについて「デフォルトで許可する範囲」「明示的な承認が必要な範囲」「常に禁止する範囲」の3段階で整理してください。
業種・組織規模によって適切な設定は変わるため、断定せず「自社の状況に応じて調整してください」という注記を各項目に添えてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト3：外部送信の承認ゲート運用フローを設計する

常駐型AIエージェントが外部にメッセージを送信・投稿・データを送る際の「承認ゲート」の運用フローを設計してください。
条件は以下の通りです。
- 深夜・休日は人間が確認できないため、送信を保留してキューに貯める
- 送信先が社外（顧客・パートナー等）の場合は必ず人間承認を経る
- 社内ツールへの通知（Slack等）は自動送信を許可してよい
フローチャートの文章版（ステップ1、ステップ2…の形式）で出力してください。
不足している情報があれば、最初に質問してから作業を開始してください。

プロンプト4：インシデント対応Runbookの叩き台を作る

常駐型AIエージェントが「想定外のコマンドを実行した」「機密ファイルにアクセスした形跡がある」ことが判明した場合のインシデント対応Runbookの叩き台を作成してください。
構成は「検知」「初動（エージェント停止・隔離）」「影響範囲の特定」「関係者への報告」「再発防止」の5段階でお願いします。
各段階で「誰が」「何を」「どのツールで」確認するかを具体的に書いてください。
仮定した点は必ず"仮定"と明記してください。

プロンプト5：サードパーティ製スキル・プラグインのレビューチェックリストを作る

コミュニティ製のスキル・プラグインを常駐型AIエージェントに追加導入する前のセキュリティレビューチェックリストを作成してください。
確認項目には「実行するコマンド・APIコールの一覧化」「ファイルアクセス範囲」「外部通信先の一覧化」「作者・更新頻度・Issue対応状況の確認」を必ず含めてください。
チェックリストはYes/No形式で、1項目でもNoがあれば導入を見送る運用を想定した文言にしてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

自社でサーバー常駐型AIエージェント基盤を運用して設けている安全装置

ここからはHermes Agentそのものの話ではなく、私たちが自社のメディア運用・リード監視・記事公開の一部をサーバー常駐型のAIエージェント基盤（cron自動化・24時間稼働）で回してきた経験の話です。念のため明確にしておくと、これは私たちが独自に構築・運用している社内基盤であり、本記事で扱っているOSSの「Hermes Agent」とは別物です。名前が紛らわしいので誤解のないようにお伝えしておきます。

常駐エージェントを日常的に動かしていて痛感するのは、「便利さと引き換えに、常に何かが動いている状態を人間が監視し続けるのは現実的ではない」ということです。そのため、私たちは以下のような仕組みを設けて運用しています。

• 外部送信の承認ゲート：メール送信・SNS投稿・外部への公開アクションは、たとえエージェントが「完了した」と自己報告してきても、人間が明示的に承認するまで実行しない二段階の仕組みにしています。エージェントの自己申告を鵜呑みにしないことが前提です。
• 通知設計：長時間処理や異常終了は都度、担当者に通知が飛ぶようにしています。「気づいたら数時間分の処理が積み上がっていた」という事態を避けるためです。
• 暴走ガード：同じ処理を無限にループさせない、想定外の大量書き込みが発生したら自動停止する、といった歯止めを個別の自動化スクリプトに組み込んでいます。
• credential（認証情報）の分離：APIキー・パスワード類は自動化スクリプトに直書きせず、環境変数・シークレット管理の仕組み経由でのみ読み込む運用を徹底しています。

正直にお伝えすると、これらの仕組みを最初から完璧に用意していたわけではありません。運用しながら「ここが抜けていた」と気づいて足してきた部分が大半です。だからこそ、Hermes Agentのような常駐エージェントを導入する企業には、「動かし始める前に、少なくとも承認ゲートと通知設計だけは決めておく」ことを強くおすすめします。後から足すのは、動かしながら気づいてからでは遅いことが多いからです。

【要注意】よくある失敗パターンと回避策

失敗1：デフォルト設定のまま本番投入する

❌ インストールして動いたことを確認したら、そのまま実運用に移行する

⭕ 監査が指摘する通りデフォルトは「ALLOW-ALL」の姿勢である前提に立ち、権限最小化・サンドボックス化を済ませてから本番投入する

なぜ重要か：個別相談を受けていても、「まず動かしてみて、問題が起きたら設定を見直す」という順番で進めようとする企業を実際によく見かけます。常駐エージェントは”動いている間ずっと権限を持ち続ける”ため、問題が起きてからでは遅いというのが、セッション型ツールとの決定的な違いです。

失敗2：監査結果を古いバージョンのまま鵜呑みにする

❌ 「Critical 4件、High 9件見つかった」という数字だけを見て、現行版でも同じ状態だと思い込む

⭕ 監査対象バージョン（v0.8.0）と自社が導入するバージョンの差分を必ず確認し、該当コードを自分の目で見る

なぜ重要か：逆に「最新版だから安心」と過信するのも危険です。修正されたのは公開CVE3件のうち2件であり、監査で指摘された13件全部が解消されたと確認できる一次情報は本記事執筆時点ではありません。「情報の鮮度」と「情報の正確さ」を両方確認する必要があります。

失敗3：エージェント本体だけを見て、周辺の連携機能を見落とす

❌ エージェントのコアロジックのセキュリティだけをレビューして安心する

⭕ メッセージング連携・WebUI・スキル/プラグインなど、周辺のアダプタ・管理画面まで含めてレビュー範囲に入れる

なぜ重要か：実際に採番された3件のCVEはいずれも「本体以外」の周辺機能で発見されています。セキュリティレビューの範囲を「コア機能だけ」に絞ると、実際の攻撃面を見落とすことになります。

失敗4：責任の所在を決めずに導入する

❌ 「OSSだから何かあったら開発コミュニティが対応してくれるはず」と考えて導入する

⭕ Hermes Agentには商用サポート契約やSLAがなく、障害・インシデント発生時の一次対応は自社側の責任になる前提で体制を組む

なぜ重要か：公式SECURITY.mdもバグバウンティ制度は運用していないと明記しており、脆弱性報告はsecurity@nousresearch.comへの非公開連絡か、GitHub Security Advisories経由が基本です。有事の際に「誰が一次対応するか」を事前に決めていないと、初動が大きく遅れます。

導入可否のセキュリティチェックリスト

最後に、Hermes Agentのような常駐型OSSエージェントを導入するかどうかを判断するためのチェックリストをまとめます。1つでも「いいえ」があれば、本番投入前にその項目を先に潰してください。

まとめ：今日から始める3つのアクション

1. 今日やること：自社で検討中・導入済みのHermes Agent（または類似の常駐型エージェント）が、どのバックエンド（ローカル／Docker等）で動いているかを確認し、承認バイパス（C3）の対象になっていないかチェックする
2. 今週中：本記事の「導入可否のセキュリティチェックリスト」をチームで確認し、「いいえ」の項目を洗い出す
3. 今月中：権限最小化ポリシーと外部送信の承認ゲート運用フローを、プロンプト2・3を使って叩き台から作成し、実際の運用ルールとして確定させる

次回予告：次回は、常駐型AIエージェントを含む社内のAI活用ルールをどう文書化するかをテーマに、社内ガバナンスポリシーのテンプレートをお届けします。

参考・出典

• Security Audit: 4 Critical, 9 High severity findings in default configuration — GitHub Issue（コミュニティ独立監査、参照日: 2026-07-14）
• Hermes Agent SECURITY.md（セキュリティポリシー・トラストモデル） — GitHub公式（参照日: 2026-07-14）
• CVE-2026-7396 Detail — NVD (National Vulnerability Database)（参照日: 2026-07-14）
• CVE-2026-7397 Detail — NVD（参照日: 2026-07-14）
• CVE-2026-6829 Detail — NVD（参照日: 2026-07-14）
• Hermes Agent Releases一覧 — GitHub公式（参照日: 2026-07-14）
• Hermes Agent 公式サイト（About）（参照日: 2026-07-14）
• Hermes Agentとは？法人導入完全ガイド — 自社記事（参照日: 2026-07-14）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。