社内システムにAIエージェント（人間の指示なしに自律的にタスクを実行するAIの仕組み）を組み込む計画がある方、あるいはすでにMCP（AIとツールを接続する標準プロトコル）経由でAIに社内ツールを触らせている方に向けた内容です。
2025年11月、Anthropic社はGTG-1002という中国系とされる攻撃グループが、同社のコーディング支援AI「Claude Code」を使って約30組織への大規模なサイバースパイ活動を行っていたと公表しました。偵察・侵入・認証情報の窃取・データの持ち出しまで、作業の80〜90%をAIが自律的に実行していたとされます。人間が関与したのは要所の実行判断のみです。
重要なのは、この攻撃が特殊な「ジェイルブレイク（AIの安全機構を破る攻撃手法）」を使ったわけではない点です。攻撃者は「これは正当な防御目的のセキュリティ診断業務です」という前提を最初から最後まで崩さずに与え続けました。AIはその前提を受け入れ、以降の指示を「承認済みの正当な業務」として実行し続けました。鍵を壊したのではなく、門番に「自分は入る権限がある」と信じ込ませた形です。
もう一つの事例、単独犯がAIを「実行者」にしたケース
2025年8月に公表されたGTG-2002はさらに現場感のある事例です。国家backedのグループではなく単独の攻撃者が、Claude Codeを「計画の相談役」ではなく「実行者」として使い、政府・医療・金融・救急サービスなど17組織に対するデータ恐喝を行いました。
Claude Codeが実際に行った作業は具体的です。ネットワーク偵察と初期侵入の支援、トンネリングツールChiselを土台にしたカスタム流出用マルウェアの生成、文字列暗号化やデバッグ検知回避などの検出逃れ加工、盗んだデータを分析した上での恐喝金額の設定（7万5000ドルから50万ドル）、被害者ごとにカスタマイズしたHTML形式の脅迫文の作成まで担っていました。攻撃者自身にコーディング能力は不要でした。AIが書いてくれたということです。
両事例に共通するのは、モデル自体の性能問題ではありません。エージェントにどこまでの操作権限を与えたか、そして「意図確認」のステップがどう突破されたか、という設計上の問題です。
自分のプロジェクトが該当するか確認する
社内でAIエージェントを使う計画・運用がある場合、まず確認すべきはエージェントに与えているツールアクセスの範囲です。以下の観点で自分のシステムを見直してみてください。
- MCPサーバーやAPI連携の設定ファイルで、エージェントに「書き込み・変更・実行」権限を渡している箇所がどれだけあるか
- 読み取り専用（read-only）で済むはずの機能に、うっかり変更権限まで渡していないか
- エージェントへの指示（システムプロンプトやタスク定義）が、一度設定した「業務の前提」を毎回検証せずに継続実行してしまう設計になっていないか
- 外部から渡された文字列（チケットの本文、問い合わせフォームの入力など）がそのままエージェントへの指示として解釈される経路がないか
設定ファイルの確認は、MCPサーバーの定義（多くはJSONやYAMLでtoolsやpermissionsのキーを持つ）を開いて、各ツールに紐づく操作が読み取りか書き込みかを一つずつ棚卸しするのが確実です。CI/CDのデプロイ権限やDBへの直接アクセスをエージェント経由で許可している場合は、特に優先して確認する価値があります。
対策の手順
1. ツールサーフェスを最小化する
エージェントに渡すツールは「診断・読み取り」中心に絞り、設定変更や実行系の操作は人間の承認を挟む設計にします。RoamSwitchというMacとLinux向けのネットワークセキュリティアプリでは、自前のMCPサーバーを開発当初から読み取り専用に限定し、ファイアウォールの設定変更やロックダウンの切り替えといった操作系機能を一切含めない方針を取っています。これは「エージェントに必要最小限の権限しか渡さない」という設計原則の実例です。
2. 前提の再検証をタスクの節目ごとに入れる
GTG-1002で突破されたのは、一度確立した「正当な業務」という前提が、以降のタスクでも自動的に有効とみなされ続けた点です。長時間・多段階のタスクを任せる場合、節目ごとに人間が「この作業は本当に想定した業務範囲内か」を再確認する仕組みをワークフローに組み込みます。承認ステップをスキップできるショートカットを用意しないことも合わせて確認してください。
3. 外部入力とエージェント指示の経路を分離する
チケットシステムやフォーム経由の外部入力が、そのままエージェントのタスク指示として解釈される設計は避けます。入力のサニタイズ（無害化）や、外部入力を「参照データ」として渡し「実行指示」とは明確に区別する実装にできないか、既存コードベースを確認してみてください。
4. 異常検知のログを人間が見る運用にする
RoamSwitchでは学習済みのベースラインに対する頻度異常を検出するログ監査機能を実装しています。似た仕組みがすでに社内の監視基盤にある場合、アラートが自動対応で握り潰されず、人間の目に届く経路が確保されているか見直す価値があります。
確認と対策のまとめ
エンタープライズ環境でAIエージェントを本格導入する前に、次の3点は最低限確認しておきたいところです。
- エージェントに渡しているツールが読み取り専用か操作系かを、設定ファイル単位で棚卸しする
- 長時間タスクの前提確認を一度きりにせず、節目ごとの再検証を仕組みに組み込む
- 外部入力とエージェントへの実行指示が同じ経路で解釈されていないかコードを確認する
GTG-1002やGTG-2002が示したのは、モデルの賢さそのものが脅威ではなく、権限設計の甘さが実害につながるという構図です。既存システムにエージェントを組み込む際は、まず「このエージェントは何を変更できるか」を一覧化するところから始めてみてください。