Strix・Cairn・Hermesとは？AIセキュリティツールの仕組みとリスク

Strix・Cairn・Hermesは、脆弱性の調査や実行、作業の継続管理にAIを使うツールで、同じ機能を競う製品ではなく、役割の異なるAIエージェントとして理解すると違いが見えてきます。

週刊アスキーの報道をきっかけに、この3つを知った方もいるでしょう。企業が押さえたいのは、名前の新しさよりも「AIが判断した内容を、どの権限で実行できるか」です。本記事では各ツールの設計を掘り下げ、悪用事例の数字の読み方と、企業が防御や検証に取り入れる際の判断軸を解説します。

まずは探索、目標に向けた実行、継続的な管理という3つの役割で整理できます。ただし、実際の機能には重なりがあります。

Gambit Securityの調査では、Strixは脆弱性探索、Cairnは侵入作業、Hermesはジョブの起動や活動全体の管理などに使われました。これは当該事例での分担であり、各製品の機能を限定する分類ではありません。Gambitの一次報告

以下は公開資料に基づく機能の整理です。Cairnの行は公開版oritera/Cairnを指し、事件で使われた実装と同一とは確認されていません。

表の評価項目は導入時の判断軸です。3製品を同条件で実測した性能順位ではありません。診断結果を受け取る人、検証を監督する人、運用を管理する人では、確認すべき成果も異なります。

AIモデルが文章から次の行動を考えても、それだけでブラウザーや端末が動くわけではありません。モデルの出力を道具の呼び出しにつなぎ、結果を戻し、次の判断を続けるためのソフトウェアが必要です。この実行を支える仕組みは、ハーネスとも呼ばれます。Strixの公式資料は、ブラウザー、HTTP通信を調べるプロキシ、端末などをエージェントに組み合わせる設計を示しています。Strix公式ドキュメント

ここから導けるのは、リスクがモデル単体の賢さでは決まらないということです。同じ判断が出ても、報告書を作る権限しかない環境と、システムを変更できる環境とでは影響が違います。

社内評価でも「どのモデルを使うか」に加え、実行できる操作、アクセスできる資産、判断の記録、承認が必要になる条件を確認します。会話の回答が正確かという評価だけでは、実行を伴うエージェントの管理として不十分です。

実際、報告された事例でも、3つのツールはそれぞれ別のAIモデルを提供サービス経由で使い分けていました。管理役のツールが新しいモデルに要求を拒否され、攻撃者が旧世代のモデルへ切り替えていた点は示唆に富みます。モデル側の安全対策が一定の歯止めになる一方、古いモデルや別の経路に逃げる余地が残ることを意味するからです。

作業を分担させる考え方は、エージェントオーケストレーションの解説も参考になります。

Strixの特徴は、疑わしい箇所の発見を、実際に問題が成立するかの検証につなげようとする点です。開発者やセキュリティ担当者向けの侵入テストツールとして公開されています。

Strixは、コードを読む分析に加え、実行中のアプリケーションの挙動を調べる機能を備えています。公式資料では、専門エージェントが協調して発見を共有し、PoCと呼ばれる実証によって脆弱性を確かめる構成が説明されています。Strix公式ドキュメント

例えば、社内の検証用アプリで「担当者以外にも情報が見えるかもしれない」という指摘が出たとします。コード上の条件分岐だけでは、実際のアクセス制御が別の層で働いている可能性が残ります。逆に、画面からボタンが消えていても、サーバー側の権限確認まで正しいとは限りません。これは設計上の説明例ですが、複数の観点を突き合わせる意味が分かります。

ただし、動かして確かめる診断は、対象への通信や状態の変化を伴い得ます。単にソースを読むレビューと同じ扱いにはできません。担当者は、何を確かめるためにどの操作が必要だったかを追える形で結果を受け取る必要があります。

Strixの公式リポジトリは、実証を伴う指摘、修正の提案、レポート作成、開発工程への組み込みを機能として掲げています。一方、こうした製品説明は、すべての環境で見逃しや誤検知がなくなるという独立した保証ではありません。Strix公式リポジトリ

受け入れ時には、少なくとも対象の版、利用したアカウント権限、期待する動作と観測結果、再現の条件を照合します。検証用の強い権限でだけ起きる現象を、そのまま外部からの侵入可能性として扱わないことも大切です。反対に、検証に失敗したという理由だけで「安全」と結論づけることもできません。

修正案についても同様です。不正なアクセスを止められても、正当な利用者の操作まで失敗するなら、そのまま採用できません。検出件数を増やすことより、重要な問題を根拠付きで絞り込み、修正後の業務動作まで確かめることに価値があります。

AIの診断能力をどう評価するかは、CyberGymとAIセキュリティ評価の解説でも取り上げています。

Cairnは、得られた情報から次の探索を選ぶ仕組みを理解する手がかりになります。ただし、Gambitの報告には使用版やリポジトリの記載がなく、事件での実装と、ここで解説する公開プロジェクトoritera/Cairnは同一と断定できません。Gambitの一次報告

公開リポジトリのoritera/Cairnは、自らを汎用の状態空間探索エンジンと位置づけ、侵入テストを最初の検証領域としています。中心にあるのは共有の掲示板で、確認結果のFact、未実行の探索方針であるIntent、人からの判断材料であるHintを扱います。ワーカーは固定された職種を持たず、共有された状態を読んで探索し、結果を書き戻します。Cairn公開リポジトリ

この設計は、長いチェックリストを一度作って順番に消化する方式とは違います。作業の途中で前提が変われば、次に確かめることも変わるからです。

例えば、許可された社内検証で、ある機能が既に廃止されていると分かった場合、その機能への調査を続ける理由は薄れます。確認結果を共有できれば、他の作業者も同じ前提を使えます。これは仕組みを理解するための例であり、実際の診断成果を示したものではありません。

Cairnの設計文書では、初期の試行、状況を読み直す判断、個別の探索を別のタスクとして扱います。ディスパッチャーがタスクの割り当てと実行管理を担い、ワーカーが状況判断や個別の探索を担います。Cairnのディスパッチャー設計

この構造から考えると、共有情報の質が後続の判断に影響します。Factという名前で保存されていても、内容が正しいことを外部の評価者が確かめられなければ、誤った前提を複数の作業に広げるおそれがあります。観測した証拠、対象、時刻、解釈を分けて残し、「目標を達成した」という報告にも検証可能な根拠を求めるべきです。

公開版のCairnはローカル実行にサンドボックスがないと明記しています。実行環境の権限をどう制限するかは、導入判断の重要な項目です。Cairn公開リポジトリ

Hermes Agentは、Nous Researchが公開する汎用エージェントです。記憶やスキルを持ち、単発の会話を超えて作業を続けられる点が、管理役としての理解につながります。Hermes公式リポジトリ

Hermesの永続メモリは、セッションをまたいで使う要点を保存する仕組みです。公式資料では、環境に関する情報などのメモリと利用者の情報を分け、セッション開始時に読み込むと説明されています。過去の詳しい経緯は、セッション履歴の検索で補います。Hermesの永続メモリ

スキルは、必要なときに読み込む手順や知識の文書です。すべての内容を毎回読み込むのではなく、名称や概要から必要な文書へ進む構成になっています。Hermesのスキル仕様

業務に置き換えると、メモリは引き継ぎの要点、履歴は過去の作業記録、スキルは再利用する手順書と考えると分かりやすいでしょう。「経験から学ぶ」という説明も、この保存と再利用を理解するのが出発点です。これらの機能だけを根拠に、AIモデル自体の重みが毎回再学習されるとは言えません。

Hermesの公式リポジトリには、定期実行やサブエージェントへの委譲なども記載されています。こうした機能は、定期調査や繰り返しの作業にも利用できます。Hermesそのものを攻撃専用の製品と捉えるのは不適切です。Hermes公式リポジトリ

運用上は、継続する仕組みに何を残すかが重要になります。仮に、先月の検証で許可されていた対象や操作をスキルに保存したとしても、その許可が今月も続いているとは限りません。手順が役に立つことと、実行が承認されていることは別の問題です。

対策としては、手順書の変更履歴を残す、許可の期限を実行時に確認する、定期ジョブの責任者を決めるといった運用が考えられます。終了時には会話を閉じるだけでなく、予約された処理や委譲先の作業も確認します。便利さを支える記憶や自動実行は、適切に更新・停止できてこそ業務に使えます。

Hermesの公式資料では、危険なコマンドの実行前に承認を求める仕組みと、承認確認を省略する設定が説明されています。ただし、常時有効の禁止リストなど、一部の制限は残ります。導入時には、承認設定と残る制限の両方を確認してください。Hermesのセキュリティ文書

この事例の重要な点は、探索と実行を継続する負担がAIによって変わり得ることです。被害や費用の数字は、調査対象と集計条件をそろえて読む必要があります。Gambitの報告によれば、2026年9月10〜15日に105件の攻撃プロジェクトが起動し、少なくとも27社が何らかの形で侵害されました。

Gambitが記した平均25.46ドルは、攻撃者自身の費用集計で、完了した101件のスキャンにおける、1件あたりの平均額です。最も安い標的で3.13ドル、最も高い標的で79.31ドルと幅があります。モデル利用料を中心とした集計で、侵入成功1件の総費用でも、市販サービスの料金でもありません。別の集計では、4週間のモデル利用費7,005.71ドルをアカウント記録で確認し、その後の活動を含む費用を約1.2万〜1.8万ドルと推計しています。Gambitの一次報告

この集計を、侵入の成功率や企業の被害額に直接結びつけることはできません。自社導入を検討する場合も、この金額をそのまま予算の目安にするのは避けましょう。モデル利用料のほかに、環境の準備、結果の確認、修正、再検証の負担があります。

評価では「1回いくらで動いたか」と「意思決定に使える結果をいくらで得たか」を分けると実態を捉えやすくなります。安価な指摘が大量に出ても、人による確認に時間がかかるなら、業務全体の負担が減るとは限りません。

同報告は人の指示も含む活動を対象としています。一部の標的では、人間が有効な管理者パスワードをエージェントに渡しており、すべての侵入経路をAIが自力で開いたわけではありません。調査の根拠にはAIの報告も含まれ、調査側自身も誤りの可能性に言及しています。Gambitの調査方法

したがって、この事例だけで「誰でも短い指示を出せば、どんな企業にも侵入できる」と一般化することはできません。一方で、途中結果を読み、別の方針を選び、作業を続ける仕組みがある以上、防御側は一度の失敗で相手が諦めることを前提にできません。これは各ツールの設計と事例から導ける運用上の示唆です。

対策の焦点も、単発の怪しい通信を止めることだけには収まりません。複数の操作が時間をまたいでどうつながるか、権限の変更や新しい定期処理が生まれていないかを調べられる記録が重要になります。

備えは、外からの侵害を防ぐ対策と、自社で動かすエージェントの権限管理の両方に必要です。自社の検証を始める場合は、目的と停止条件を決めてから小さく評価します。

防御の点検は、入口だけを見て終わらせないことが大切です。外部公開しているシステムに加え、管理者権限、配信するファイル、事業を再開するための復旧手段まで、担当を分けて確認します。

決済画面は、サーバー上のファイルだけでなく、利用者のブラウザーに実際に届くページと、セキュリティに影響するHTTPヘッダーも監視します。タグ管理を別部署が担当している場合も、全体を確認し、異常時に止める責任者を決めておきましょう。

この復旧の備えが重要になる理由は、報告された事例が示しています。大きなデータ損失は身代金要求ではなく、攻撃側の後片付けから生じました。抽出後にデータを消す手順が仕込まれていたほか、ある小売業者では名前による削除対象の照合が広すぎたため、管理者のバックアップ用を含む180テーブルが削除されました。侵害された本番権限では変更・削除できないコピーを確保し、復元できることまで確認する必要があります。

修正の優先順位には、実際の悪用が確認された脆弱性を集めるCISAのKEVカタログが参考になります。決済画面の改変対策はPCI SSCのスクリプト管理・監視の解説、復旧の備えはCISAのバックアップと復元確認の指針が根拠になります。

AIによる攻撃への備えを広く整理したい場合は、AIサイバー攻撃と企業防御の記事も参照してください。

OWASPは、LLMエージェントに過剰な機能、権限、自律性を与える問題をExcessive Agencyとして整理しています。必要な道具と権限に絞り、影響の大きい操作には人による承認を組み込むことを推奨しています。OWASPのExcessive Agency解説

診断用の権限も、報告書を保存する権限と、対象を書き換える権限を分けて検討します。「変更しないで」という指示に加え、不要な変更権限を与えない構成が必要です。

診断対象のページやファイルに埋め込まれた不正な指示で、エージェントが誘導される「間接プロンプトインジェクション」のリスクもあります。これは今回の事件で確認された手口ではなく、一般的な導入リスクです。外部コンテンツを実行指示として扱わず、機密情報へのアクセスや外部送信を制限し、影響の大きい操作には承認を求めます。OWASPのプロンプトインジェクション解説

Hermesの公式セキュリティ文書も、ファイル操作の保護機能が、悪意ある、あるいは侵害されたエージェントを隔離するサンドボックスではないと明記しています。端末操作は別経路になり得るためです。Hermesのセキュリティ文書

実行環境を分ける際も、共有フォルダー、外部通信、持ち込む認証情報を点検します。隔離環境の中に強い権限を渡せば、その権限が届く先への影響は残ります。

防御目的で使うなら、まず書面で許可された限定的な検証環境を用意します。Strixの公式資料も、所有するアプリケーションか、明示的な許可を得た対象だけをテストするよう求めています。Strix公式ドキュメント

検証前に、対象、アカウント、実施時間、変更可能な範囲、異常時の停止条件を決めます。比較する版や設定、評価対象もそろえます。

ローカルでツールを動かしても、クラウドモデルを使う構成ではデータが提供先へ送られます。診断中のコード・通信内容・認証情報について、送信範囲とマスキング、提供先の保存・学習利用条件を確認してください。Strixのモデル実行環境の説明

測る指標は、再現できた指摘の割合、人による確認時間、重要な問題の見逃し、修正後の再確認にかかった時間などです。これは推奨する評価方法であり、3ツールの実測値ではありません。既知の問題を含む教材用アプリと、問題が修正された版を用意すると、検出と修正確認を分けて考えられます。

停止操作の確認も評価に含めましょう。担当者が中断を指示したとき、端末処理やサブエージェント、定期ジョブまで止まるかを確かめておくと、導入後の責任範囲を具体化できます。

導入を検討すると、費用や人による診断との関係が気になるはずです。ソフトウェアの公開形態と、業務で使うための負担を分けて判断しましょう。

公開ソフトウェアを使うことと、運用費用がかからないことは同じではありません。Strixにはローカルで動かすオープンソース版に加え、クラウドなどの提供形態があります。モデルの利用条件、計算資源、保守や結果の確認にかかる費用は別に考える必要があります。Strixの提供形態

3つの公開ソフトウェアはライセンスも異なります。StrixはApache-2.0、HermesはMIT、公開版oritera/CairnはAGPL-3.0です。Cairnの公式READMEは、AGPLの義務を負わずに商用・プロプライエタリ環境で利用したい場合、別途商用ライセンスを取得するよう案内しています。Cairnのライセンス説明

取り入れる前に各リポジトリのライセンスで条件を確認してください。

比較する際は、利用する版と契約条件を先にそろえます。今回の事件で報じられた費用を、社内で安全に運用する費用に置き換えることはできません。

この3ツールの資料と今回の事例だけから、人による診断が不要になるとは判断できません。探索や確認を支援できても、対象範囲の合意、業務への影響判断、結果の妥当性確認、修正の優先順位づけは引き続き必要です。

まず、定期的に繰り返す検証や、修正後の再確認など、成果を照合しやすい場面で役割を決めるのが現実的です。担当者を何人減らせるかより、従来は確認しきれなかった範囲をどこまで確かめられるかを評価すると、導入の意味が明確になります。

担当と判断の分担は、社内レッドチームの体制づくりで詳しく解説しています。

公開資料では、Strixは調査と実証、oritera/Cairnは目標に応じた探索、Hermesは記憶やスキルによる継続管理という特徴があります。役割には重なりがあり、事件で使われた版や設定と現在の公開機能は分けて考える必要があります。特にCairnは、事件での実装と公開版の同一性が確認されていません。

企業にとっての判断軸は、AIがどこまで自律的に動くかだけではありません。結果を確かめる証拠があるか、必要な権限だけを渡しているか、途中で止められるか、事業を復旧できるかまで見て初めて、活用の可否を判断できます。

自社での利用を検討する際は、許可された検証環境と、受け入れる成果の条件を先に決めてください。AI活用や業務システムの見直しを相談する場合も、対象システム、現在の権限管理、確認したい課題を整理しておくと、具体的な検討につながります。