ARTEX以後のAI攻撃ツールをどう捉える？仕組みと企業が点検すべきリスク

AI攻撃ツールとは、言語モデルが調査結果を読み、外部ツールを動かして次の操作を選ぶことで、探索や検証などの作業を進める仕組みです。侵入を最初から最後まで無人で完遂する能力が、すべての製品に備わるという意味ではありません。

企業が見るべきなのは、製品名の多さだけでなく、自社の認証情報や公開システム、実行権限がどの経路で使われ得るかです。AI診断ツールを導入していない企業にも、公開された秘密情報を狙われるリスクはあります。

この記事では、クラウドやWebサービスを管理する情シス・開発責任者に向けて、攻撃基盤の全体像、公開調査が示した範囲、企業の確認事項を解説します。ScopeWeaver・Strix・Shannon・PentAGIは、その違いを理解する具体例として扱います。資料確認日は2026年11月12日です。個別環境の安全性や診断の網羅性は、対象に合わせた確認が必要です。

変化の中心は、既存の道具を使う手順の一部を、実行結果に応じてAIが組み立て直すことです。製品の数と、侵害の成立条件を分けて捉える必要があります。

従来の自動化でも、対象の列挙や既知のパターンに沿う検査はできました。エージェント型の仕組みでは、モデルが返ってきたデータやエラーを読み、作業を分解したり、使う道具や次の確認を選び直したりします。人が毎回コマンドの出力を読み、次の操作を入力する部分を減らせることが特徴です。

ただし、自動化する作業の範囲は構成によって異なります。ある処理は資産の整理だけを担い、別の処理は稼働アプリへリクエストを送り、結果を検証します。単に報告文を生成する段階と、外部システムの状態を変える段階では、必要な管理も変わります。

GTIGとMandiantは、複数の侵害事例でエージェント型フレームワークの悪用を観測したと報告しています。一方で、人が認証情報を渡した例や試行錯誤の記録もあり、標的を指定するだけで全工程を完遂する高度な段階は将来像と区別しています。GTIGの観測報告

防御側が確認したいのは、AIがどこまで賢いかという抽象的な評価より、認証情報を得た後に何へ接続できるか、失敗後も処理が続くか、どの記録が残るかです。手作業の一部が速くなっても、アクセス権や通信経路という成立条件まで消えるわけではありません。

GitGuardianの調査は、ARTEX以外にも約45の関連フレームワークを取り上げています。同社は、ネットワーク上の探索・侵入、WebアプリとAPI、C2との連携、汎用エージェントを攻撃用途に使うハーネス、研究用の仕組みという用途で整理しています。全製品を同条件で動かした性能比較ではありません。GitGuardianの調査

企業側の整理には、名称一覧より、扱う対象と実行範囲を見る表が役立ちます。

これは製品を固定的な箱に分けるための表ではありません。同じツールでも、版や実行モード、与える情報、接続するモデルによって動作が変わります。「ソースを読む製品だから外部へ操作しない」「セルフホストだから情報が外へ出ない」と判断する前に、実際のデータ経路と実行設定を確かめます。

一覧にあること自体は悪用の証明ではありません。正規の診断にも使われる道具の性質と、観測された攻撃者の使い方を分けることで、自社の検査環境を守る話と、攻撃を受ける側の話をつなげられます。

コードに専用機能が見当たらなくても、モデルが利用可能な汎用ツールを組み合わせる場合があります。機能一覧の確認に加え、実行時に与える権限と観測した動作を確かめます。

「秘密情報を探す専用スキャナを含まない」という事実から、「秘密情報を探せない」とは結論できません。ファイルを読む権限やコマンド実行の道具があれば、モデルが別の手段で同じ目的へ近づくことがあります。

GitGuardianは、専用の秘密情報スキャナを持たないARTEXの1ビルドを、架空のリポジトリを使う隔離環境で試しました。探索用の3種類の指示を各3回実行した9試行で、各回とも9つの架空の認証情報等のうち8つを発見したと報告しています。使われたのは汎用的なgitとgrepでした。GitGuardianの隔離実験

ここから考えるべき管理対象は、スキャナ名だけではありません。エージェントが読めるファイル、到達できるネットワーク、使える認証情報、追加の処理を動かす権限です。診断用に渡したフォルダ以外も読める構成では、指示文で対象を狭く書いても、ファイル側のアクセス権は変わりません。

専用機能の調査は不要になるわけではなく、提供された道具と権限を把握する出発点です。その先で、意図した操作だけが通るか、許可していない読取りや通信が拒否されるかを、別の証拠で確かめます。製品名やプロンプトの禁止文だけを、実行範囲の保証にしないことが重要です。

発見した文字列と、利用できる認証情報は同じではありません。さらに、認証できたことと、重要なデータへ到達できたことも分かれます。実験や報告を読むときは、どの段階まで確認したのかをそろえる必要があります。

前述のGitGuardianの実験では、研究者がリポジトリのURLを与えています。したがって、大量の公開リポジトリから対象を見つける能力を測ったものではありません。また、取得した認証情報の使用を求める指示では動作に至らず、実サービスへの悪用も検証されていません。単一のビルド・モデル・小さな模擬対象での結果です。

調査結果は、次のように段階を分けると読み違いを防げます。

例えば、モデルが拒否した試行を「ツール側の権限制御が機能した」と記録すると、モデルを替えた場合に同じ結果になるかが分からなくなります。拒否、実行エラー、通信遮断、対象側の認可拒否は、それぞれ別の結果として残します。これは攻撃ツールの評価だけでなく、防御製品の効果を読むときにも共通する注意点です。

秘密情報の露出は、AI診断ツールを導入していない企業にも関係します。見つかった認証情報が有効で、強い権限や接続先を持つ場合、既存のAPIが次の入口になります。

Microsoftは、エージェント型ツールを使って公開GitHub上の秘密情報を探し、その後の活動に利用する攻撃を観測しています。少なくとも1件では、秘密情報の探索からAzure Key Vaultのデータ流出まで5分だったと報告しています。これは特定事例の時間であり、あらゆる攻撃の所要時間ではありません。Microsoftの報告

この経路で確認したいのは、公開ファイルの有無に加え、その値がどのIDに結び付き、どの操作を許すかです。人のログイン画面を守っていても、別のアプリケーション用認証情報が有効なら、その認証方式と権限の管理が必要になります。

例として、検証用の設定に書いた認証情報が、本番のストレージにも読取り権限を持っている構成を考えます。問題は文字列が外へ出たことに加え、検証と本番の権限がつながっている点です。公開範囲を見直す作業と、そのIDが到達できる資産を調べる作業を、別の担当へ引き継げる記録が要ります。

調査時は、認証情報の種類、所有者、発行元、利用先、許可する操作、発行・失効の時刻を対応付けます。無関係に見えるシステムでも同じIDや委託先の接続を共有していれば、確認範囲に含めるかを判断します。AIという名称の有無より、秘密情報から業務資産までのつながりが、被害の範囲を考える手がかりになります。

漏えいした値をファイルから消す作業と、その値で認証できなくする作業は別です。GitHubの公式案内は、パスワードやトークン等が露出した場合、最初に失効またはローテーションするよう示しています。履歴を書き換えても、既存のクローンやフォーク等から一括して消せるわけではありません。GitHubの対応案内

対応は、目的の異なる作業へ分けて記録すると整理できます。

• 認証情報を無効化し、継続して必要な処理には新しい値や別の認証方式を設定する。
• 公開ファイルや履歴、配布済みの成果物を調べ、秘密情報が残る場所を把握する。
• 利用履歴から、想定外の接続、権限変更、データ操作の有無を確認する。

これらは完了条件も異なります。旧値が使えなくなったこと、新しい設定で通常業務が動くこと、調査した期間と資産が記録されていることを、それぞれ確認します。ローテーションを済ませても、過去の不正アクセスや流出が取り消されるわけではありません。

履歴の書換えには共同作業への影響があります。証拠として残すもの、削除するもの、共有先に対応を依頼するものを整理し、削除作業の対象と順序を決めます。担当者が「削除しました」と報告するときも、ファイル削除なのか、失効なのか、履歴調査まで終えたのかが分かる表現にすると、対応の抜けを減らせます。

外部から識別できるサービスがあることと、無認証で操作できること、侵害されたことは分けて評価します。診断基盤には、接続先や認証情報だけでなく、機密性の高い結果も集まります。

GitGuardianは、2026年11月7日のARTEX系について、Shodanで識別された1,428サービスという集計を掲載しています。一方、Censysは11月4日に、外部公開されたARTEXコンソールのある1,465ホストを観測したと報告しています。GitGuardianの集計、Censysの観測

日付も、サービスとホストという単位も異なるため、この差から増減率は計算できません。Censysは同一構成のホスティングが集まるブロックの存在や、正規の診断担当者の環境も含み得ることを補足しています。数字をそのまま攻撃者数、導入企業数、侵害成功数として使うのは適切ではありません。

自社環境の点検では、集計の大小より、識別された場所で何が起きるかを調べます。ログイン画面だけが見えるのか、結果を取得できるのか、処理を開始できるのか、別のAPIに認証なしで届くのかを分ける必要があります。

管理画面の入口を認証で保護していても、結果ファイルの配布先やバックアップが別経路で公開されていれば、その経路の調査が残ります。反対に、画面のタイトルが検索サービスに記録されたことだけで、背後のデータを読まれたとは判断できません。観測した応答と未確認の経路を対応付けることが、対応範囲を決める出発点です。

結果を見る画面にも、操作に関わる権限が含まれる場合があります。Strixの公式資料では、結果ビューアの既定の待受は127.0.0.1で、トークン由来のセッションがなければ実行データを読めないと説明されています。実行中スキャンのダッシュボードURLには指示を与える権限がある一方、単独で起動するビューアは実行中スキャンを操作できません。StrixのViewer説明

この例から、共有リンクを送る際は、何を許すリンクなのかを確認する必要があります。レポートの閲覧、元の通信記録の取得、進行中の処理への指示は、同じ権限とは限りません。担当者が想定した用途と、リンクが実際に与える操作を照合します。

保管するデータも一覧にします。対象URL、コマンド、リクエストと応答、報告書、画面キャプチャ、設定のバックアップでは、含まれる秘密情報や個人データが異なります。閲覧者と保存期間を決め、複製先にも同じ制限が適用されるかを確認します。

さらに、入口の公開停止、共有リンクへの対応、実行中の処理の停止を同じ作業にまとめないことが大切です。画面を閉じた後もワーカーが動く構成なら、画面の応答だけでは停止を確認できません。どの処理が止まり、どのセッションや認証情報が残るかまでを、運用記録として追えるようにします。

各ツールは、共通するリスクを具体化する例として見ると役立ちます。製品名から優劣を決めるより、入力、実行する操作、管理する権限の違いを確認します。

4ツールは、同じ対象へ同じ情報を与えて比較した結果ではありません。次の表は、公開資料にある設計を、本記事の論点に対応させたものです。

出典：ScopeWeaver、Strix、Shannon、PentAGI

例えばScopeWeaverの資料は、scopeをプロンプト上の指示と資産記録のフィルターとして説明し、実際のネットワーク境界には外部の通信制御が必要と明記しています。PentAGIの資料も、ホストのDockerソケットを渡すと、エージェントがホストDocker APIを扱える影響を説明しています。ScopeWeaverのscope説明、PentAGIのDocker権限説明

このように、入力画面での指定、アプリ内の制御、OSやネットワークの制限を分けると、確認すべき境界が見えます。製品全体の仕組みや実測の詳細は、Strix等の解説とScopeWeaver隔離ラボの検証記事で扱っています。

正規の検証へ使えるかを考える際には、機能説明に加えて製品ごとの利用条件を確認します。ScopeWeaverのREADMEは、ローカルの隔離環境での研究・技術検証等に利用を限定し、オンラインのシステムや本番での実試験を禁止する追加条件を掲げています。AGPLの説明と、この著者の利用条件は分けて読む必要があります。ScopeWeaverの利用条件

Shannonも、本番への実行を禁止し、実証のための操作がデータを変更し得ると説明しています。動くPoCを得た問題を報告する方針でも、人の最終確認は必要で、実証できない依存関係や設定上の問題等は報告に含まれない場合があります。Shannonの安全性と限界

比較結果を読むときは、同じURLを与えただけで条件がそろったと考えないことも重要です。ソースの提供、アカウントの権限、対象の初期状態、モデル、時間上限が異なれば、得られる情報や試せる操作が変わります。製品内の実証方針も、独立した再確認や網羅性の保証とは別です。

社内で記録するなら、製品・版・モデルと入力条件、完了した範囲、途中失敗、証拠を一緒に残します。「発見なし」が、調査を終えた結果なのか、接続や認証に失敗した結果なのかを区別できなければ、別製品との比較にも、修正後の確認にも使いにくくなります。

点検対象は、秘密情報から業務資産へつながる経路と、診断基盤自身の公開・実行経路です。AIツールの利用有無に応じて担当を分け、確認した証拠と残る範囲を記録します。

まず、外から得られた認証情報が、自社の何を操作できるかを把握します。対象には、自社の公開リポジトリだけでなく、委託先と共有する設定や、過去に配布した検証用の成果物も含め、所有者と公開条件を整理します。他社の環境を無断で調べる話ではなく、自社が管理する情報と契約上確認できる範囲の点検です。

Webアプリの担当者はソースの公開範囲を把握していても、設定に含まれるクラウドIDの権限を別チームが管理している場合があります。このとき「秘密情報はなかった」という確認だけでは、調べたリポジトリや期間、対象IDの範囲が伝わりません。点検の単位を対応付ける表が役立ちます。

優先順位は、外部から到達できること、有効な認証情報があること、重要資産へ強い権限がつながることを組み合わせて判断します。ツールの名称に一致する通信がないという理由だけで、秘密情報の露出や通常APIを使う不審な操作を調査対象から外さないようにします。

漏えい時の失効を遅らせないため、平時に業務への影響、ログの保管期間、委託先との連絡経路を整理しておきます。少人数の体制で進める防御計画については、少人数チームの防御策と30日計画も参照してください。

診断基盤を扱う場合は、製品の利用条件に合う対象と環境を選んだうえで、どの権限を誰へ与えるかを確認します。対象URLを入力したこと、コンテナ内で動くこと、画面にログインがあることは、それぞれ異なる範囲の説明です。

OWASPは、エージェントに必要なツールと権限だけを与え、認可をモデルの文脈の外にある実行側で検査することを示しています。高影響の操作では、承認を実際の対象・操作に結び付け、監査記録や停止の設計も組み合わせる考え方です。OWASPのAI Agent Security Cheat Sheet

運用票には、設定項目だけでなく、確認結果を書ける欄を設けます。例えば次の項目は、製品ごとの対応状況を確かめるための点検案です。

• 公開経路：画面、API、結果ファイル、バックアップの到達範囲と認証を確認したか。
• 実行範囲：通信先、ファイル、認証情報、ホストへのアクセスをどこで制限するか。
• 操作権限：閲覧、ダウンロード、指示、開始・停止を誰へ許すか。
• 証拠保管：通信記録や報告書に含まれる情報と、その閲覧・保持・削除をどう管理するか。
• 中断と復旧：画面を閉じた後の処理、残る接続、対象データの復元をどう確認するか。

結果は「確認済み」「条件付き」「未確認」「対象外」に分け、未試行を合格欄へ入れないようにします。拒否されるべき操作を実際に試す場合も、許可された隔離対象と模擬データを使い、対象と停止条件を決めて行います。権限制御の実装は最小権限の設計ガイド、停止や費用上限はガードレール運用チェックリストで詳しく扱っています。

製品一覧は全体像をつかむ資料ですが、特定の名称への対策だけで管理範囲は決まりません。導入や併用を検討するときも、目的と確認できた結果を対応させます。

一覧にないことは、自社への影響がない根拠にはなりません。ツールの名前が違っても、露出した認証情報や許可された接続経路を使う仕組みは成立し得ます。

製品名は調査の手がかりとして使い、自社の秘密情報、IDの権限、公開資産、操作記録も点検対象にします。一方、名前が一覧にあるだけで、その利用者や公開インスタンスを悪意あるものとは判断できません。観測した操作と権限を確認します。

追加の確認が得られる可能性はありますが、似た探索や同じ指摘が増え、人の確認負担が大きくなる場合もあります。追加の指摘と確認負担を比べ、併用する価値を判断します。

利用条件に合う模擬対象で初期状態と入力情報をそろえ、独立に結果を取得してから候補を突合します。重複を除いた再現可能な指摘、未確認範囲、確認工数、総費用で追加価値を測ります。実行条件の異なる発見件数だけで優劣を決めず、途中失敗やモデルの拒否も別に記録します。

AI攻撃ツールを捉えるときは、モデルが何を推論するかに加え、どの道具を使い、何を読み、どこへ接続し、どの権限で操作できるかを見ます。製品の機能一覧、ラボでの実験、実際の侵害の観測は、それぞれ示せる範囲が異なります。

企業側の課題は、公開された秘密情報から重要な資産へ届く経路と、診断基盤自身が持つ権限・保存データを把握することです。AI診断ツールを使っていなくても前者は残り、試用環境を置けば後者の管理も加わります。ScopeWeaver・Strix・Shannon・PentAGIの例は、その境界を具体的に理解する材料になります。

点検の相談や社内の引継ぎでは、対象の一覧、利用するID、公開経路、既に確認した証拠、未確認の範囲を一緒にまとめると、誰が何を確認するかを決めやすくなります。ツールを増やす判断より先に、自社で有効な認証情報と実行権限がどこへつながっているかを整理することが、防御と正規の検証に共通する出発点です。