脅威調査：エージェント型AIが残した秘密

ユーザーが Copilot に保護されたリソースを使用するように指示すると、Copilot Al はリクエストを分析し、関連する「スキル」（プラグインマニフェストで定義されている）をアドバタイズするプラグインを特定します。Copilot は、保存された認証情報を使用してサードパーティApplication （アプリケーション）への認証された API 呼び出しを行い、データを取得またはアクションを実行し、結果を Copilot に返します。これらの保護されたリソース（セキュリティApplication （アプリケーション））を Microsoft Copilot に接続するために、どのような認証方法が使用されたかを理解しようとしました。 5

GitHubで公開されているサードパーティ製プラグインのマニフェストを分析した結果、次のことがわかりました。

• 20%がBasic Authenticationをサポート
• 75％はApiKeyメソッドをサポートしています
• 5%がOAuth2フローをサポート

Copilot AIプラグインの使用に伴うリスクは、主に、（a）この認証方法の選択と（b）エージェントに提供されるアクセスコープにかかっています。

基本認証

基本認証を使用すると、管理者はサードパーティApplication （アプリケーション）でサービスアカウントを作成し、ユーザー名とパスワードを Microsoft サーバーにアップロードする必要があります。Copilot は、（ユーザーのプロンプトに基づいて Copilot がそのツールを選択するたびに）セキュリティアプリへのすべてのリクエストのヘッダーにユーザー名とパスワードを送信します。

定義上、Alエージェントがhttp:basicスキーム（基本認証）を使用してリソースにアクセスできるように構成されたユーザーまたはサービスアカウントは、多要素認証をサポートできません。

このスキームを使用している顧客は、結果として、機密データへの広範なアクセスを許可されていることが多いユーザーまたはサービスアカウントを、クレデンシャル・スタッフィングおよびパスワードスプレー攻撃にさらす必要があります。

APIKey

Microsoft Security Copilotプラグインの4分の3は、APIKeyメソッドを使用して承認できます。

構成中、管理者は保護されたリソースに有効期間の長いAPIトークンを作成します。これは通常、ユーザーまたはサービスアカウントのコンテキストで作成され、APIトークンを手動でMicrosoftサーバーにアップロードします。Copilotは、保護されたリソースに対して行うすべてのHTTPリクエストのヘッダーでAPIトークンを送信します（つまり、Copilotがユーザーのプロンプトに基づいてそのセキュリティツールを選択するたびに）。

静的APIキーは、基本認証よりもいくつかの利点があります。

• APIキーは、マシン-to-マシンのフローに適しています。多くの場合、一意のAPIトークンごとに、非アクティブ後または設定された期間後に期限切れになるように構成できます。キーを取り消しても、キーを作成したユーザーまたはサービスアカウントには影響しません。
• APIトークンの作成に使用されるサービスアカウントへのアクセスは、多要素認証（MFA）を使用して保護できるようになりました。
• 管理者は、基本認証に使用されるサービスアカウントの権限と比較して、APIトークンを使用して読み取りまたは変更できる「範囲」を制限する可能性が高くなります。

残存リスクは、これらのAPIトークンが通常、長期にわたって有効であることです。APIキーは、ソース管理システムに日常的にチェックインされます。APIキーは、クエリパラメータとして設定された場合、ログに日常的に保存されます。APIキーは、開発者のワークステーション上のテキストファイルに保存され、デバイスに感染する次の一般的な情報窃盗犯によって収集されるのを待っています。

静的なAPIトークンは攻撃者にとって非常に価値があり、多くの攻撃者がシステムを侵害した後に最初に探すものです。いったん傍受されると、これらのトークンは通常、長期間有効であるため、オンラインマーケットでの再販に最適です。

静的 API トークンは、少なくとも OAuth フローで作成された一時トークンと比較して、可用性のリスクも伴います。静的トークンは、Application （アプリケーション）ではなく、ユーザーのコンテキストで作成される傾向があるためです。

多くの場合、トークンを作成したユーザーまたはサービスアカウントが削除またはプロビジョニング解除されると、トークンも一緒に削除され、M2M統合が中断されます。

OAuth 2

Microsoft Security Copilotプラグインの残りの少数は、エンタープライズレベルのOAuth2フローを使用しているようです。

これらのスキームでは、クライアントIDとクライアントシークレット（Microsoftと共有）が認可サーバーと交換され、有効期間の短いアクセストークンを取得します。このアクセストークンは、リソースサーバーによって個別に検証されます。

これらのフローがOktaで作成された場合、結果として得られるアクセストークンは、IP制限（構成されたIP範囲からのみ有効）およびクライアント制限（リクエストしたクライアントからのみ有効）できます。スコープはサービスApplication （アプリケーション）レベルで設定され、ユーザーレベルでは設定されません。つまり、管理アカウントまたはサービスアカウントがプロビジョニング解除されたときに、管理者が誤ってマシン-to-マシン統合を無効にすることはありません。

ごく少数のCopilotエージェントがエンタープライズレベルの認証向けに設計されていることは残念ですが、多くの点で、これらの選択はセキュリティアプリが利用できるようにした既存の認証方法を反映しています。単一の独自のAIツールとの統合というコンテキストでは、これらのセキュリティベンダーは利用可能な認証方法の更新に投資する準備ができていなかったことは明らかです。

しかし、すべてのAlアプリケーションに対してプラグインマニフェストを作成する代わりに、開発者がすべてのフレーバーのAlアプリケーションでサポートされている業界標準に基づいて単一のサーバーを構築できるとしたらどうでしょうか？

モデルコンテキストプロトコルを入力してください。

モデルコンテキストプロトコルへの脅威のモデリング

エンタープライズアプリのdeveloperにとって、Al モデルのすべての種類に対して新しいカスタムコネクター (Microsoft Copilot プラグインなど) を作成する必要がある場合、経済的とは言えません。

サービスプロバイダーは、どのデータとツールをどのAIモデルと共有する意思があるかを最初から宣言し、これらのリソースが公開される条件を定義し、顧客がアクセスを承認する方法を定義し、これらのリソースにアクセスできるAIアプリケーションを許可リストに登録することを希望するでしょう。

このため、エージェントAlの勢いは現在、Model Context Protocol（MCP）を中心に構築されています。MCPは、AIアプリケーション（ホスト）を、クラウドプラットフォーム、SaaSアプリケーション、コードリポジトリ、データベース、さらには決済サービスといった多様なエンタープライズサービスに接続するための標準化されたインターフェースです。MCPのクライアント/サーバーアーキテクチャにより、AI Application （アプリケーション）を、コンテキストを提供するデータソースおよびツールに「プラグアンドプレイ」できます。

エンタープライズでは、MCPは次のことを約束します。

• 利用可能なエンタープライズ所有のデータソースとツールを特定する、
• エージェント型AIアプリケーションが、データの相互汚染なしに、複数のApplication （アプリケーション）からデータソースとツールにアクセスできるようにします。
• これらのデータソースやツールにアクセスするさまざまなAIアプリケーションの実験コストを削減します。

MCPサーバーは、ローカルまたはリモートで展開できます。特定のユースケースに対するこの展開モデルの選択は、結果として得られる脅威モデルに大きな影響を与えます。

{"en-US":"The scope of our research was constrained to understanding how Al applications (hosts), MCP clients and MCP servers handle credentials.","ja-JP":"私たちの調査範囲は、AIアプリケーション（ホスト）、MCPクライアント、およびMCPサーバーが資格情報をどのように処理するかを理解することに限定されました。"}{"en-US":"The core components we assessed were:","ja-JP":"評価した主なコンポーネントは次のとおりです："}

• MCPホスト：Cursor、VS Code、Claudeなどの統合開発環境（IDE）を含むすべてのアプリケーション。MCPサーバーによってアドバタイズされるツールへのアクセスが必要です。
• MCPクライアント: MCPホストがペアのMCPサーバーとの通信に使用する複数のクライアント。
• MCP サーバー：MCP サーバーは、外部サービスで利用可能なツールとリソースをアドバタイズし、これらのサービスへの API 呼び出しを行います。

ローカルMCPサーバー

MCPモデルは、ソフトウェア開発のユースケースに特に魅力的です。

CursorやVS CodeのようなAI対応IDEを使用するソフトウェアエンジニアは、ローカルでコードを構築しながら、リモートAIモデルの支援を受けて、開発者がコードを書く際に提案を受けることができます。

AnthropicのClaude AIエージェントは「Claude Desktop」としてローカルにデプロイ可能になりました。Claude DesktopはローカルにデプロイされたMacOSおよびWindowsクライアントであり、ブラウザ経由でAnthropicのAIモデルにアクセスする代替手段です。ローカルMCPサーバーの利点の1つは、クライアントがリモートAIモデルとローカルファイル（ドキュメント、画像など）の両方と対話できることです。

これらのデスクトップアプリケーションは、多くの場合、LLM（通常はAPIキーが必要）とリモートデータソース（パーソナルアクセストークンが必要なコードリポジトリなど）の両方に対して認証を行う必要があります。

ユーザーがClaudeやCursorなどのホストApplication （アプリケーション）を起動すると、MCPクライアントはMCPサーバーを生成し、ローカル構成ファイルから操作に必要なすべての認証情報（APIキー、データベースの認証情報、パスワード、OAuthクライアントシークレットなど）をサーバーに渡します。これには、MCPサーバーがリモートサービスへのアクセスに必要な認証情報も含まれます。

たとえば、MCPサーバーがGithubリソースへのアクセス用に設計されている場合、ホストはローカル構成ファイルで利用可能なGithub Personal アクセストークン（PAT）を必要とします。Github PATが提供されていない場合、サーバーはエラーになります。

Alを使用する最も一般的な開発Application （アプリケーション）3つの構成ファイルの場所を以下に示します。

{"en-US":"Research by Keith Hoodlet at <a href=\" \">Trail of Bits noted the risks of storing static API keys in plaintext in these files, and cited examples of where these files were world-readable (i.e.","ja-JP":"Keith Hoodlet氏による<a href=\" \">Trail of Bits の調査では、これらのファイルに静的なAPIキーをプレーンテキストで保存するリスクが指摘され、これらのファイルがワールドリーダブル（つまり、"}{"en-US":"able to be accessed by any user of the system).","ja-JP":"システムのすべてのユーザーがアクセスできる）である例が挙げられました。"}

この調査を拡張して、Claude Desktop、Cursor、および VS Code のデフォルト設定ファイルを評価したところ、同じ許可が観察されました。

[1] 安全でない認証情報ストレージが MCP を悩ませる

同じ許可が、多数の公式MCPサーバーの実装に含まれる構成ファイルにも適用されるようで、これらは「本番環境対応」と説明されており、問題のサービスプロバイダーによって承認されていないサードパーティによって開発されたほぼすべてのコミュニティ統合にも適用されます。

脅威モデリングでは、これまで共有されたMCPサーバーの大部分が承認されていないことを予測する必要があります。これにより、開発者が不正なMCPサーバーを使用することに関するリスクが高まります。

GitHubにアップロードされたMCPサーバーの予備的なVirusTotal分析[2]により、それらの8％が疑わしいことが判明しました。開示されていない数には、プロンプト内のシークレット（キー、パスワードなど）を識別し、それらを外部エンドポイントに投稿しようとするコードが含まれていました。

APIキーの安全でないストレージは、以下に示すように、さまざまなリスクをもたらします。

[2] What 17,845 GitHub Repos Taught Us About Malicious MCP Servers

[3] A Look Into the Secrets of MCP: The New Secret Leak Source

キーがコンテナメタデータで公開されています

{"en-US":"Running MCP servers in containers shifts rather than mitigates the issue.","ja-JP":"コンテナ内でMCPサーバーを実行すると、問題が軽減されるのではなく、場所が移動するだけです。"}{"en-US":"The secret must be passed to the container in a format that the MCP server supports.","ja-JP":"シークレットは、MCPサーバーがサポートする形式でコンテナに渡される必要があります。"}

コンテナ構成を確認すると、クリアテキストのシークレットへの直接的な参照が得られます。ホスト上のファイルのフォームであるか、docker inspect（dockerリソースの検査を可能にするコマンドラインツール）を実行することで公開できるコンテナ内の関連する環境変数を識別できるかです。

{"en-US":"Keys accessed by malware","ja-JP":"マルウェアによってアクセスされたキー"}

コモディティな情報窃取マルウェアは、認証情報が保存されている特定のパスとファイルタイプを特定するように設計されています。

以下に例を示します。

• {"en-US":"Windows infostealers, such as Vidar Stealer, will search for secrets stored at ~\\AppData\\Roaming","ja-JP":"Windowsのインフォスティーラー（Vidar Stealerなど）は、〜\\AppData\\Roamingに保存されているシークレットを検索します。"}
• Atomic StealerなどのMacOS情報窃盗犯は、~/Library/Application （アプリケーション） サポートに保存されているシークレットを検索します

これらの場所に静的APIトークンを安全でない方法で保存すると、影響の大きいイベントが発生する可能性が非常に高くなります。この場所に保存されたセッショントークンは、攻撃者がリソースへのユーザーレベルのアクセスを取得できる短い時間枠を提供するのに対し、静的APIトークンは、組織全体のリソースへの永続的なアクセスを提供します。

外部システムにバックアップされたキー。

管理者が機密フォルダー（Windows の場合は~\AppData\Roaming、MacOS の場合は~/Library/Application （アプリケーション） サポートなど）を除外しない場合、キーがバックアップ ボリュームに公開されます。

複数のユーザー間で共有されるワークステーション

指定された構成ファイルが誰でも読み取り可能であることが判明したため、共有デバイス上の1人のユーザーによって保存されたキーは、同じデバイスにログインする他のユーザーもアクセスできます。

デフォルトでは、認証後、認証情報はMacOS Keychainに保存され、管理者がMCPサーバーからサインアウトすると、キーチェーンから削除されます。

さらに、デフォルトではスコープは選択されていません。管理ユーザーはスコープを選択するように求められます。

[4] Auth0 MCPサーバーはこちら

このプラグインの作成者は、セキュリティよりもdeveloperの利便性を優先して最適化したことを明言しています。

対照的に、Atlassianの公式リモートMCPサーバーには、CursorのようなローカルIDEから接続するユーザーを含むすべてのユーザーに、OAuthベースのログインと同意を提供するために、localhost サポートが含まれています。

これにより、developerがローカル構成ファイルにシークレットをコピー＆ペーストする必要が効果的になくなります。構成ファイルはリモートサービスを参照するだけで、ユーザーは認証に成功するとOAuthの同意を求められます。

また、特定のセキュリティ成果よりも認証方法の選択に最適化されたMicrosoft Copilotとは異なり、OAuthはAtlassianのリモートMCPサーバーで利用可能な唯一の認証方法です。Atlassianは、どのホスト（Alアプリケーション）がこのリモートMCPサーバーに接続できるかを許可リストに登録しています。