Microsoft SecurityのAutoJack AI agent RCE研究でまず押さえるべき点は、通常のMicrosoft Security製品に緊急の設定変更が必要になった、という話ではないことです。これは、AIエージェントが外部Webページを閲覧し、同じ端末上のローカル制御面にアクセスできる場合に、RCEにつながり得る設計上のリスクを示したResearch記事です。
特に確認すべきなのは、AutoGen Studioを開発版からビルドして使っているチーム、MCP連携やブラウジング機能付きAIエージェントを検証している開発者、そしてMicrosoft DefenderやMicrosoft EntraでAIエージェント環境を監視しているセキュリティ担当者です。Microsoft Security Blogでは、影響のあったMCP WebSocket面はPyPI公開版には含まれておらず、pip install autogenstudioで導入した利用者はこの特定チェーンの影響を受けないと説明されています。(Microsoft)
Microsoft SecurityのAutoJack AI agent RCE研究 は何が変わった？影響範囲と確認ポイント
Microsoft Security Blogで2026年6月18日に公開された「AutoJack」は、公式ソース上ではResearchに分類されています。内容は、AutoGen Studioの開発途中のMCP WebSocket実装において、外部ページを閲覧するAIエージェントがlocalhost上の制御面へ到達し、結果としてホスト上で任意プロセスを起動し得る、という攻撃連鎖を示したものです。(Microsoft)
重要なのは、単一の不具合だけではなく、次のような前提が重なった点です。
| 観点 | 内容 | 実務上の意味 |
|---|---|---|
| localhost前提 | ローカルホストからの接続を信頼する設計 | AIエージェントが同じ端末で動くと、外部ページの影響がlocalhost側へ届く可能性がある |
| 認証の抜け | 一部のMCP系パスが通常の認証経路から外れていた | 「アプリ全体で認証を有効にした」だけでは制御面を守れない場合がある |
| パラメーター処理 | URL経由のパラメーターがプロセス起動に関わる処理へ渡っていた | ツール実行・MCPサーバー起動・コマンド実行系の入力検証が重要になる |
Microsoftはこの連鎖を、AIエージェントが攻撃者の最後の配送手段になるという意味で「AutoJack」と呼んでいます。公式記事では、AutoGen StudioのMCP WebSocket面におけるOrigin許可、認証、server_params処理の3点が連鎖したと説明されています。(Microsoft)
今回の変更点は「修正済みの研究公開」と「localhost信頼の見直し」
今回のポイントは、AutoGen Studioの特定実装が修正されたことに加え、AIエージェント開発全体に対して「localhostは安全な境界とは限らない」という教訓が示された点です。
| 変更点 | 内容 | 確認すべきこと |
|---|---|---|
| MCP WebSocketの堅牢化 | WebSocket URLから直接サーバーパラメーターを受け取る形をやめ、サーバー側で登録したセッション情報を参照する形に変更 | 開発版を使っている場合は、修正後のコミット以降かを確認する |
| 認証経路の見直し | MCP系ルートが通常の認証経路を通るように修正 | WebSocketや/api/*を含め、制御面全体に認証が効いているか確認する |
| PyPI版への影響整理 | 公式記事では、影響のあったMCP WebSocket面はPyPI公開版に含まれていないと説明 | pip install版か、GitHub mainブランチ由来かを切り分ける |
| AIエージェント設計への警告 | ブラウジング機能とローカルの強力な制御面を同居させる危険性を提示 | 開発端末、検証環境、本番相当環境で分離方針を見直す |
修正はAutoGenのGitHubリポジトリのcommit b047730で確認でき、コミットメッセージにもMCP WebSocket endpointのhardeningが含まれています。差分では、WebSocket URLにserver_paramsを含める方式から、サーバー側にセッションパラメーターを保持してWebSocket接続時に参照する方式へ変更されています。(GitHub)
影響を受ける可能性が高い対象者
このResearch記事を見たときに、すべてのMicrosoft Security利用者が同じ対応をする必要はありません。まず、自社がAutoGen StudioやMCP連携のAIエージェントを使っているか、どの形で導入しているかを切り分けることが重要です。
| 対象者・環境 | 影響の見方 | 優先対応 |
|---|---|---|
| PyPIからAutoGen Studioを導入している利用者 | 公式記事では、この特定チェーンの攻撃面はPyPI公開版に含まれていないと説明 | ただし、AIエージェントの権限分離や監視は見直す |
| GitHub mainブランチからAutoGen Studioをビルドした開発者 | MCPプラグイン追加から修正コミットまでの間に取得した環境は確認対象 | commit b047730以降かを確認し、古いビルドは破棄または更新 |
| Web閲覧機能付きAIエージェントを開発しているチーム | AutoJackと同じ設計パターンが別フレームワークでも起こり得る | ブラウザ、ツール実行、ローカル制御面を分離する |
| Microsoft Defender利用組織 | 製品そのものの脆弱性というより、検知・調査の観点で関係 | 不審な子プロセス、ローカルWebSocket、外部サイト閲覧を監視 |
| Microsoft Entraや条件付きアクセスを使う組織 | 開発端末侵害時の横展開やトークン悪用を抑える観点で関係 | PIM、条件付きアクセス、エージェントID管理を見直す |
Microsoftは、AutoGen Studioを開発用プロトタイプとして分離環境で扱うこと、インターネット公開サービスとして運用しないこと、mainブランチからMCP対応版を使う場合は修正コミット以降を使うことを推奨しています。(Microsoft)
すぐ確認したい設定と運用上の注意
AutoGen StudioやAIエージェント側で確認すること
まずは、AutoGen Studioの導入経路を確認します。PyPI版なのか、GitHubのmainブランチから直接ビルドしたものなのかで、今回の特定チェーンに対する優先度が変わります。
| 確認項目 | 確認する理由 | 対応の目安 |
|---|---|---|
| 導入元 | PyPI版かGitHub開発版かで影響範囲が変わる | 開発版の場合は取得日時とコミットを確認 |
| 実行アカウント | RCEが起きた場合、そのユーザー権限で影響が広がる | 日常利用や管理者アカウントでは実行しない |
| 待受ポート | デフォルトポートやWebSocket制御面が外部から見えると危険 | loopbackのみ、またはファイアウォールで制限 |
| 認証範囲 | REST APIだけでなくWebSocketやMCP系パスにも認証が必要 | リバースプロキシを含め全パスで認証を確認 |
| ツール実行 | MCPサーバーやコード実行ツールが任意コマンド化すると危険 | 実行可能なツール・引数・接続先を許可リスト化 |
| ブラウジング機能 | 外部ページのスクリプトやプロンプトインジェクションの影響を受ける | 信頼できないURLを直接処理させない設計にする |
| 分離環境 | 開発端末上の資格情報やソースコードを守る必要がある | コンテナ、VM、Windows Sandbox、Dev Boxなどで分離 |
Microsoftのガイダンスでは、AutoGen Studioをloopbackのみにバインドする、ポート8081などへの非loopback通信をファイアウォールで遮断する、認証付きリバースプロキシを使う、低権限アカウントやコンテナで実行する、といった対策が挙げられています。(Microsoft)
Microsoft Defenderで見るべき検知ポイント
Microsoft Defenderを使っている場合は、AutoJackそのものを「単一の脆弱性名」で探すより、挙動で見るほうが実務的です。公式記事では、AutoGen Studio実行中の不審な子プロセス、MCP制御面へのWebSocket到達、ブラウザ自動化ホストの外部ドメイン閲覧などを調査観点として挙げています。(Microsoft)
| 監視観点 | 見るべき例 | 判断のポイント |
|---|---|---|
| 不審な子プロセス | Python、Node、AutoGen関連プロセスからシェルや管理系ツールが起動 | 開発者が意図した操作か、AIエージェント経由かを確認 |
| ローカル制御面への通信 | localhostや8081番台などへのWebSocket接続 | AutoGen Studio稼働時間と通信時刻を突き合わせる |
| ブラウザ自動化の外部アクセス | Playwrightやブラウジングエージェントが非業務ドメインへアクセス | 要約対象URL、プロンプト、入力元を確認 |
| 資格情報の露出 | 開発端末上のトークン、SSHキー、クラウド認証情報 | 侵害疑いがあればローテーションを実施 |
もしAdvanced Huntingで該当する挙動が見つかった場合は、単なる検証ログとして流さず、開発環境の侵害可能性として扱うべきです。公式記事でも、該当活動が見つかった場合はホストを確認し、開発者の資格情報やトークンをローテーションし、自動起動場所への書き込みがないか確認するよう示されています。(Microsoft)
Prompt ShieldsやAI-SPMだけに頼り切らない
Azure AI Content Safety Prompt Shieldsは、ユーザー入力や間接プロンプトインジェクションを検出する早期の防御点になります。ただし、公式記事では、Prompt Shieldsはその後に発生するクライアントサイドJavaScript実行そのものを遮断するものではないと説明されています。つまり、入力段階の防御、エンドポイント監視、ネットワーク制御、権限分離を組み合わせる必要があります。(Microsoft)
Microsoft Defender for CloudのAI Security Posture Managementは、AI BOMの作成、IaCやコンテナ依存関係のスキャン、攻撃経路分析によって、AutoGen Studioのようなプロトタイプがどこに展開されているかを把握する助けになります。一方で、pipで導入されたPythonパッケージは通常のインベントリで必ず見つかるとは限らないため、プロセスやファイルのテレメトリも併用するのが現実的です。(Microsoft)
誤解しやすいポイント
「localhostだから安全」はAIエージェント時代には通用しにくい
従来の開発ツールでは、localhostにしか待ち受けていなければ安全と考えがちでした。しかし、AIエージェントが同じ端末上でWebページを閲覧し、ローカルサービスへ到達できる場合、その前提は崩れます。Microsoftは、エージェントが信頼できないページを閲覧し、特権的なローカルサービスと通信できるなら、loopbackも攻撃面になり得ると整理しています。(Microsoft)
「認証を有効にしたから大丈夫」とは限らない
アプリの通常画面やREST APIに認証がかかっていても、WebSocket、MCP、デバッグ用API、内部制御面が同じ認証経路に入っていない場合があります。今回の研究でも、MCP系パスが認証ミドルウェアの対象外になっていたことが連鎖の一部でした。実務では、「ログイン画面があるか」ではなく、「制御面の全エンドポイントに認証・認可が効いているか」で確認する必要があります。(Microsoft)
「PyPI版は対象外だから何もしない」も危険
公式記事上では、影響のあった特定のMCP WebSocket面はPyPI公開版には含まれていないとされています。しかし、AutoJackの本質はAutoGen Studioだけの問題ではありません。外部コンテンツを読むAIエージェント、ローカルの強力な制御面、localhost前提の信頼。この3つがそろう設計は、別のAIエージェント基盤でも同じ種類のリスクを生みます。(Microsoft)
管理者が今日やるべきこと
まず、社内にAutoGen Studio、AutoGen、MCPサーバー、Playwrightなどのブラウザ自動化を使ったAIエージェント検証環境があるかを棚卸しします。次に、開発者端末や検証VMで、外部Webページを読ませるエージェントと、ローカルのコード実行・MCP・デバッグAPIが同居していないかを確認します。
優先順位は次の通りです。
| 優先度 | 対応 |
|---|---|
| 高 | GitHub mainブランチ由来のAutoGen Studioを使っている環境を確認し、修正コミット以降へ更新 |
| 高 | Web閲覧エージェントとローカル制御面を同じ高権限ユーザーで動かさない |
| 高 | WebSocket、MCP、/api/*、デバッグポートに認証・認可があるか確認 |
| 中 | Microsoft Defenderで不審な子プロセスやlocalhost WebSocket通信を調査 |
| 中 | 開発者端末上のトークン、SSHキー、クラウド認証情報の保管場所を見直す |
| 中 | AIエージェント検証をコンテナ、VM、Windows Sandbox、Microsoft Dev Boxなどへ分離 |
| 低 | 社内のAI開発ガイドラインに「localhostを信頼境界にしない」を明記 |
Microsoft SecurityのAutoJack AI agent RCE研究は、単なるAutoGen Studioの修正情報ではなく、AIエージェントを安全に運用するための設計レビュー項目です。PyPI版の通常利用者がこの特定チェーンで直ちに影響を受ける可能性は低い一方、外部Webを読むAIエージェントと、ローカルの強力な制御面を同居させる設計は見直す価値があります。
次に取るべき行動は明確です。AutoGen StudioやMCP連携の導入経路を確認し、開発版を使っている場合は修正済みかを確認します。そのうえで、認証、権限分離、ファイアウォール、Defenderでの監視、資格情報の保護をセットで見直してください。今回の教訓は「AIエージェントに外部を見せるなら、localhostも外部入力の影響を受ける前提で守る」ことです。
コメント