2026年5月8日時点で確認されたMicrosoft公式情報で、AIエージェント開発者が最初に確認すべき点は明確です。自社や自社サービスが Microsoft Semantic Kernel を使ってAIエージェントを構築している場合、Python版は semantic-kernel 1.39.4未満、.NET版はSemantic Kernel .NET SDK 1.71.0未満の利用有無を確認し、該当する場合は速やかに更新してください。今回の「When prompts become shells」は、単なるプロンプトインジェクション対策の話ではありません。AIエージェントにツール実行権限を与えると、プロンプトがファイル操作やコマンド実行につながり、RCE、つまりリモートコード実行の入口になり得ることを示した重要なセキュリティ情報です。(Microsoft)
この記事では、Microsoft Security Blogで公開された「When prompts become shells: RCE vulnerabilities in AI agent frameworks」をもとに、何が変わったのか、どの環境が影響を受けるのか、管理者と開発者が確認すべき設定・移行・展開上の注意点を整理します。Microsoft 365 Copilotを利用している一般ユーザー向けの機能変更というより、Semantic KernelやAIエージェント基盤を使ってアプリを開発・運用している組織が優先的に読むべき内容です。
MicrosoftのAI/Copilot関連で何が変わるのか
今回のポイントは、MicrosoftがAIエージェントフレームワークにおける新しい攻撃面を具体的な脆弱性として示したことです。
従来のプロンプトインジェクションは、「AIに意図しない回答をさせる」「機密情報を引き出そうとする」といった文脈で語られることが多くありました。しかしAIエージェントは、単に文章を返すだけではありません。プラグインやツールを通じて、ファイルを読む、データベースを検索する、スクリプトを実行する、外部APIを呼び出すといった操作を行います。Microsoftは、この構造によりAI層の脆弱性が「コンテンツ上の問題」から「実行リスク」へ変わると説明しています。(Microsoft)
特に重要なのは、問題の中心がAIモデルそのものではなく、モデルの出力を信頼してツールに渡すフレームワークや設計にある点です。AIモデルは自然言語を構造化されたツール呼び出しに変換します。そのツールの引数を攻撃者がプロンプト経由で操作できると、ファイル書き込み、データ流出、RCEにつながる可能性があります。(Microsoft)
今回整理された2つの脆弱性
Microsoftの公式記事では、Semantic Kernelに関する2つの脆弱性が取り上げられています。どちらも、AIエージェントがツールを呼び出す設計に起因する問題です。
| CVE | 主な影響対象 | 成立条件 | 想定される影響 | 優先対応 |
|---|---|---|---|---|
| CVE-2026-26030 | Python版 semantic-kernel | 1.39.4未満、In-Memory Vector Storeのフィルター機能を利用、Search Pluginの既定構成に依存 | プロンプトインジェクションからRCEに発展する可能性 | semantic-kernel 1.39.4以上へ更新 |
| CVE-2026-25592 | Semantic Kernel .NET SDK | 1.71.0未満、SessionsPythonPlugin を利用 | 任意ファイル書き込み、サンドボックス境界の回避、RCEにつながる可能性 | Semantic Kernel .NET SDK 1.71.0以上へ更新 |
CVE-2026-26030について、GitHub AdvisoryではPythonパッケージ semantic-kernel の1.39.4未満が影響を受け、1.39.4で修正済みとされています。また、回避策として本番環境で InMemoryVectorStore を使わないことが示されています。(GitHub)
CVE-2026-25592については、GitHub上のMicrosoft Semantic KernelリポジトリのAdvisoryで、NuGetパッケージ Microsoft.SemanticKernel.Plugins.Core の1.71.0未満が影響対象、1.71.0で修正済みとされています。回避策として、DownloadFileAsync や UploadFileAsync に渡される localFilePath をFunction Invocation Filterで検証し、許可リスト化する方法が示されています。(GitHub)
CVE-2026-26030：プロンプトがPythonコード実行につながる仕組み
CVE-2026-26030は、Semantic Kernel Python SDKの InMemoryVectorStore のフィルター機能に関するRCE脆弱性です。Microsoftの説明では、攻撃者がプロンプトインジェクションでエージェントの入力に影響を与え、対象エージェントがSearch PluginのバックエンドとしてIn-Memory Vector Storeを既定構成で使っている場合に、プロンプトからRCEが成立し得るとされています。(Microsoft)
分かりやすく言うと、次のような流れです。
| 段階 | 何が起きるか | 実務上の見方 |
|---|---|---|
| ユーザー入力 | 「パリのホテルを探して」のような自然言語が入る | 通常の検索リクエストに見える |
| モデルの判断 | AIモデルが検索ツールを呼び出す | ツール呼び出し自体は正常なエージェント動作 |
| 引数の生成 | city="Paris" のような値がプラグインに渡る | ここに攻撃者が細工した文字列を混ぜられる |
| フィルター処理 | 文字列がPythonの式として処理される | 入力検証が弱いとコード実行の入口になる |
| 結果 | 任意コマンド実行につながる可能性 | エージェントホスト側の侵害として扱う必要がある |
Microsoftは、この脆弱性の原因として、AIモデルが制御できる値が十分にサニタイズされず、Pythonの eval() による評価に到達していた点を説明しています。修正では、安全なASTノードの許可リスト、許可された関数呼び出しの制限、危険な属性のブロック、名前ノードの制限など、複数層の防御が追加されています。(Microsoft)
影響を受けるか確認する方法
Python版を使っている開発チームは、まず依存関係を確認します。
python -m pip show semantic-kernelまたは、環境によっては次のようにバージョンを確認できます。
python -c "import semantic_kernel; print(semantic_kernel.__version__)"確認すべきポイントは、単にパッケージが入っているかではありません。次の3点をセットで確認してください。
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
semantic-kernel のバージョン | requirements.txt、pyproject.toml、ロックファイル、コンテナイメージ | 1.39.4未満なら更新対象 |
| In-Memory Vector Storeの利用 | エージェントの検索処理、RAG検証コード、PoCから流用したコード | 本番環境で使っている場合は特に注意 |
| Search Pluginとの連携 | ツール登録、プラグイン登録、既定構成 | モデルが検索引数を生成できる構成なら要確認 |
「検証用に作っただけ」のIn-Memory Vector Storeが、そのまま社内ツールやPoC環境に残っているケースは珍しくありません。PoC環境でも社内ネットワークやクラウド資格情報にアクセスできるなら、実質的には本番に近いリスクがあります。
CVE-2026-25592：サンドボックス内の処理がホスト側ファイル書き込みに変わる
CVE-2026-25592は、Semantic Kernel .NET SDKの SessionsPythonPlugin に関する脆弱性です。このプラグインは、Azure Container Apps dynamic sessionsのような隔離されたクラウドホスト型サンドボックス内でPythonコードを実行するために使われます。
問題は、ファイル転送に関わる DownloadFileAsync が、AIモデルから呼び出せる関数として公開されていた点です。Microsoftの説明では、localFilePath がAI制御下になり、パス検証やディレクトリ制限がない状態では、攻撃者がプロンプト経由で危険な場所へファイルを書き込ませる可能性がありました。(Microsoft)
Microsoftが示した攻撃の流れは、概念的には次の通りです。
| 段階 | 攻撃の流れ | 防御上のポイント |
|---|---|---|
| 1 | サンドボックス内で悪意あるスクリプトを生成させる | サンドボックス内だけならまだホスト実行ではない |
| 2 | DownloadFileAsync を使ってホスト側の危険なパスへ保存させる | ここでサンドボックス境界が崩れる |
| 3 | Windowsのスタートアップフォルダなどから実行される | 永続化やホスト侵害として扱う |
修正では、AIモデルから DownloadFileAsync を呼び出せないようにし、開発者がプログラムから呼び出す場合にも、パス正規化と許可ディレクトリ照合による検証が追加されています。Microsoftは、Semantic Kernelを使っている場合はすぐにアップグレードすることを主な推奨策としています。(Microsoft)
.NET環境での確認コマンド
.NETプロジェクトでは、直接依存だけでなく推移的依存も確認してください。
Windows環境では次のように確認できます。
dotnet list package --include-transitive | findstr /i SemanticKernelLinuxやmacOSでは、次のように確認できます。
dotnet list package --include-transitive | grep -i SemanticKernelNuGetパッケージの更新後は、アプリケーションのビルドだけでなく、エージェントが使うツール呼び出しの挙動も確認します。今回の修正では、AIモデルから見えるツールの範囲が変わるため、以前はモデルが自律的に呼び出せていた処理が、更新後は呼び出せなくなる可能性があります。これはセキュリティ上は望ましい変更ですが、既存ワークフローに影響する場合があります。
Microsoft 365 Copilot利用者は何を確認すべきか
今回の情報は、Microsoft 365 Copilotの一般的な利用者に「すぐ設定変更が必要」という内容ではありません。中心は、Semantic Kernelなどを使ってAIエージェントを開発・運用している組織です。
ただし、次のような組織は確認対象になります。
- 社内向けAIエージェントを自社開発している
- Semantic Kernelを使ってRAG、検索、コード実行、ファイル処理を組み込んでいる
- Copilot Studioや独自エージェントから外部API、社内DB、ファイル操作ツールを呼び出している
- PoCとして作ったAIエージェントを社内ユーザーに公開している
- エージェントホストがAzure、Windows Server、開発者PC、CI/CD環境の資格情報にアクセスできる
重要なのは、「Copilotを使っているか」ではなく、AIモデルがどのツールを呼び出せるかです。Microsoftも、LLM自体をセキュリティ境界として扱うべきではなく、モデルが影響を与えられるツール引数は攻撃者制御の入力として扱うべきだと説明しています。(Microsoft)
管理者が最初に行うべき確認
管理者は、開発チームに「Semantic Kernelを使っていますか」と聞くだけでは不十分です。依存関係、実行環境、公開範囲、権限をセットで棚卸しする必要があります。
| 優先度 | 確認項目 | 具体的な確認方法 |
|---|---|---|
| 高 | Semantic Kernelの利用有無 | GitHub、Azure DevOps、社内Git、コンテナ定義で semantic-kernel、Microsoft.SemanticKernel を検索 |
| 高 | バージョン | Pythonは1.39.4以上、.NETは1.71.0以上を基準に確認 |
| 高 | エージェントの公開範囲 | 社外公開、社内限定、開発環境のみのどれかを分類 |
| 高 | ツール権限 | ファイル操作、コード実行、OSコマンド、DB検索、外部送信の有無を確認 |
| 中 | 実行ユーザーの権限 | 管理者権限、書き込み可能ディレクトリ、クラウドロール、マネージドIDを確認 |
| 中 | 監視ログ | エージェントプロセスからの子プロセス起動、外部通信、ファイル作成を確認 |
| 中 | PoC環境 | 「一時的に作った」エージェントが社内で使われ続けていないか確認 |
特に見落としやすいのは、PoC環境と開発者PCです。AIエージェントの検証では、利便性を優先して広い権限のAPIキーやクラウド認証情報を使うことがあります。その状態でプロンプトインジェクションからコード実行が成立すると、影響範囲はアプリケーションだけでなく、ホストや接続先サービスに広がります。
開発者が確認すべき設定とコード
開発者は、単にライブラリを更新して終わりにしないことが重要です。今回の脆弱性は、AIエージェント設計そのものに関わるため、ツール公開範囲と入力検証を見直す必要があります。
AIモデルに見せるツールを最小化する
AIエージェントでは、「便利だから全部の関数をツールとして登録する」という設計が危険です。モデルに公開した関数は、プロンプトインジェクションによって攻撃者が間接的に呼び出せる可能性があります。
特に次のようなツールは、公開前に強い制限が必要です。
| ツールの種類 | リスク | 実装時の判断基準 |
|---|---|---|
| ファイル読み取り | 機密情報の流出 | 読み取り可能なディレクトリを限定する |
| ファイル書き込み | 永続化、改ざん、RCE | 書き込み先を許可リスト化し、絶対パスを禁止または厳格検証する |
| コード実行 | 直接的なRCE | サンドボックス、権限制限、ネットワーク制限を必須にする |
| 外部HTTP送信 | データ持ち出し | 宛先ドメイン、メソッド、送信サイズを制限する |
| DB検索・更新 | 情報漏えい、データ破壊 | 読み取り専用アカウントやクエリ制限を使う |
ツール引数を「攻撃者入力」として扱う
AIモデルが生成したツール引数は、信頼済みデータではありません。自然言語から生成された値であっても、外部ユーザーや外部コンテンツに影響されているなら、Webアプリのフォーム入力と同じように検証すべきです。
実装では、次の考え方が有効です。
- 文字列連結でコード、クエリ、ファイルパスを作らない
- パスは
..の有無だけで判定せず、正規化後に許可ディレクトリ配下か確認する - ツール引数は型、長さ、形式、許可値を検証する
- 失敗時は曖昧に補正せず、安全に拒否する
- 危険なツールは人間の承認を挟む
プロンプトで「この操作は禁止」と書くだけでは不十分です。プロンプトはガードレールの一部にはなりますが、セキュリティ境界ではありません。境界はコード、権限、ネットワーク、監査ログで作る必要があります。
Function Invocation Filterを使う
Semantic Kernel .NET SDKを利用している場合、関数呼び出し時に引数を検査するFunction Invocation Filterの導入を検討してください。GitHub Advisoryでも、更新できない場合の回避策として、DownloadFileAsync や UploadFileAsync に渡る localFilePath を検証し、許可リスト化することが示されています。(GitHub)
実務では、次のようなルールを設けます。
| ルール | 例 |
|---|---|
| 書き込み先ディレクトリを固定する | /app/agent-output/ や専用一時ディレクトリのみ許可 |
| 絶対パスを制限する | C:\Windows\、ユーザープロファイル、スタートアップフォルダを禁止 |
| 拡張子を制限する | .txt、.json、.csv など業務上必要なものだけ許可 |
| 実行可能ファイルを禁止する | .exe、.ps1、.bat、.cmd、.sh などを原則禁止 |
| 保存前に正規化する | 文字列比較ではなく正規化後の実パスで判定 |
移行・展開時に注意すべきポイント
今回の更新は、依存パッケージを上げるだけなら短時間で終わるように見えます。しかし、AIエージェントの展開では「どこで動いているか」を見落としやすいため、移行計画を分けて考える必要があります。
コンテナイメージとCI/CDを更新する
開発端末でパッケージを更新しても、本番のコンテナイメージが古いままでは意味がありません。次の場所を確認してください。
Dockerfilerequirements.txtpoetry.lockpyproject.toml.csprojpackages.lock.json- GitHub ActionsやAzure Pipelinesのキャッシュ
- Azure App Service、Azure Functions、AKS、VM上のデプロイ済みイメージ
- 社内配布しているエージェント実行環境
依存関係スキャンを使っている場合も、直接依存だけでなく推移的依存を確認します。NuGetやpipのロックファイルが古いと、設定ファイルだけ更新しても実際のデプロイに反映されないことがあります。
更新後の動作確認では「安全に失敗するか」を見る
セキュリティ更新後は、正常系だけでなく異常系のテストが重要です。
| テスト観点 | 確認内容 |
|---|---|
| 通常の検索 | RAGや検索機能が従来どおり動くか |
| 不正な引数 | 予期しない文字列、長い文字列、記号を拒否できるか |
| ファイル操作 | 許可外パスへの書き込みが失敗するか |
| ツール呼び出し | AIモデルから見える関数が最小限になっているか |
| ログ | 拒否された操作が監査ログに残るか |
| 権限 | エージェントホストが不要な資格情報を持っていないか |
「攻撃が成功しない」だけでなく、「失敗した操作を検知できる」状態にすることが重要です。検知できない失敗は、別の経路で再試行されると気づけないためです。
すでに脆弱な状態で運用していた場合の調査ポイント
Microsoftは、修正により脆弱性は閉じられるものの、過去に悪用された可能性の確認は別問題だと説明しています。まず、脆弱なバージョンをデプロイした時点から、修正版へ更新した時点までの「脆弱だった期間」を定義し、その期間のホストレベルの痕跡を調査する必要があります。(Microsoft)
調査では、次の観点を優先します。
| 調査対象 | 見るべき痕跡 |
|---|---|
| プロセス | エージェントプロセスから cmd.exe、powershell.exe、bash、curl などが起動していないか |
| ファイル | スタートアップフォルダ、テンポラリ、スクリプト保存先に不審ファイルがないか |
| ネットワーク | エージェントホストから通常と異なる外部通信がないか |
| 資格情報 | エージェントが参照できるAPIキー、トークン、マネージドIDが悪用されていないか |
| 永続化 | 自動起動設定、スケジュールタスク、サービス登録が追加されていないか |
Microsoftは、Semantic Kernelエージェントホストからの不審な子プロセス起動などを検出するAdvanced Huntingの考え方も示しています。Defenderを利用している組織では、エージェントホストのプロセス名、コマンドライン、親子プロセス関係をもとに調査クエリを作成するとよいでしょう。(Microsoft)
更新できない場合の暫定対策
理想は修正版への更新です。ただし、互換性検証やリリース手続きの都合で即時更新できない場合は、暫定対策を重ねてリスクを下げます。
| 対象 | 暫定対策 |
|---|---|
| Python版Semantic Kernel | 本番環境で InMemoryVectorStore を使わない。Search Pluginの既定構成に依存していないか確認する |
| .NET版Semantic Kernel | SessionsPythonPlugin の利用を一時停止、またはファイル転送系関数の引数をFunction Invocation Filterで制限する |
| エージェントホスト | 管理者権限で実行しない。書き込み可能なディレクトリを最小化する |
| ネットワーク | 不要な外部通信を制限する。特にエージェントから任意の宛先へ送信できる状態を避ける |
| 資格情報 | エージェントに長期トークンや高権限キーを持たせない |
| ログ | ツール呼び出し、引数、拒否結果、子プロセス起動を記録する |
暫定対策でありがちな失敗は、「プロンプトを強化したから大丈夫」と考えることです。プロンプトで「ファイルを書き込まないでください」と指示しても、攻撃者が外部文書や入力欄に別の指示を混ぜれば、モデルが意図しないツール呼び出しを生成する可能性があります。必ずコード側で制限してください。
AIエージェント設計で見直すべきセキュリティ原則
今回の件から得られる教訓は、Semantic Kernelに限られません。LangChain、CrewAI、独自フレームワークなど、AIモデルにツールを接続する設計全般に当てはまります。Microsoftも、今後はMicrosoft以外のエコシステムにある類似の脆弱性についても扱う予定だと説明しています。(Microsoft)
実務で見直すべき原則は、次の5つです。
LLMをセキュリティ境界にしない
AIモデルは、入力された自然言語や外部コンテンツを解釈して応答します。そこに悪意ある指示が混じる可能性を前提に設計します。
ツールの公開範囲を最小化する
モデルに見せるツールは、必要最小限にします。内部処理用のヘルパー関数やファイル転送関数をそのまま公開しないでください。
引数検証を必ずコードで行う
AIが生成した引数は、すべて外部入力として扱います。型、長さ、形式、許可値、パス、宛先を検証します。
最小権限で実行する
エージェントホストは、必要なファイル、API、ネットワークにだけアクセスできるようにします。侵害された場合の被害範囲を小さくすることが重要です。
監査ログと検知を前提にする
ツール呼び出し、引数、実行結果、拒否結果、子プロセス、外部通信を追跡できるようにします。AIエージェントは通常のアプリよりも意思決定経路が見えにくいため、ログ設計が後回しになると調査が難しくなります。
30分でできる初動チェックリスト
まずは、次の順に確認すると効率的です。
| 順番 | やること | 完了条件 |
|---|---|---|
| 1 | リポジトリ全体で semantic-kernel、Microsoft.SemanticKernel を検索 | 利用プロジェクト一覧を作る |
| 2 | Python版のバージョンを確認 | 1.39.4以上、または未使用と判断できる |
| 3 | .NET版のバージョンを確認 | 1.71.0以上、または未使用と判断できる |
| 4 | In-Memory Vector StoreとSearch Pluginの利用を確認 | 本番利用の有無を把握する |
| 5 | SessionsPythonPlugin の利用を確認 | ファイル転送系関数のリスクを把握する |
| 6 | エージェントの実行権限を確認 | 管理者権限や高権限トークンを避ける |
| 7 | 修正版への更新計画を決める | 本番、検証、PoCの更新日を決める |
| 8 | 脆弱だった期間のログを確認 | 不審な子プロセス、外部通信、ファイル作成を調べる |
まとめ：まず依存関係を確認し、ツール設計を見直す
今回の「When prompts become shells」で重要なのは、プロンプトインジェクションがAIの回答品質だけでなく、ホスト上のコード実行やファイル操作に直結し得ることです。Semantic Kernelを使っている組織は、Python版 semantic-kernel 1.39.4以上、.NET版Semantic Kernel 1.71.0以上への更新を優先してください。
そのうえで、AIモデルに公開しているツール、ツール引数の検証、ファイル操作の許可範囲、エージェントホストの権限、監査ログを見直します。AIエージェントの安全性は、プロンプトの書き方だけでは決まりません。モデルが呼び出せるツールと、そのツールが持つ権限によって決まります。
次に取るべき行動はシンプルです。自社のリポジトリとデプロイ済み環境でSemantic Kernelの利用有無を確認し、該当バージョンがあれば更新します。更新後は、AIエージェントが「何を実行できるか」を棚卸しし、不要なツールを閉じ、危険な引数をコード側で拒否できる状態にしてください。
コメント