エンドポイントでは、目に見えないAIエージェントが実行されています

エンドポイントにおけるシャドーAIとは？

エンドポイント上のシャドーAIとは、調達、セキュリティレビュー、アイデンティティガバナンスを経ずに、従業員のハードウェアに直接展開されるローカルのAIソフトウェア、LLM、Model Context Protocol（MCP）サーバーの統合を指します。ブラウザーベースのAIにはデータ漏洩のリスクがありますが、エンドポイントのAIエージェントは、バックグラウンドでMCPサーバーを介してローカルのファイルシステムやSaaSシステムと直接やり取りします。

もはやリスクは、エージェントがブラウザ経由で接続することだけにとどまりません。今や、すべての従業員が自分のノートパソコンで複数のAIエージェントを起動できるようになりました。非常に使いやすいため、もはや技術職だけのものではありません。誰でもできます。

こうしたエージェントはベロシティを飛躍的に向上させますが、アイデンティティに関する厄介な問題も生み出します。つまり、アイデンティティの一元的な強制、スコープ、監査証跡、アクセスレビューが存在しないという問題です。

MCPサーバーがエンドポイントの攻撃対象領域を拡大する仕組み

AIエージェントは単独で動作するわけではありません。エージェントが何らかの有用なタスクを実行するには、さまざまなシステムにアクセスする方法が必要であり、今日ではほとんどの場合、MCPサーバーを介してアクセスすることになります。エージェントと、エージェントがアクセスできるすべてのものとをつなぐ結合組織の役割を果たします。

MCPサーバーを介して、わずか数クリックでこれらのエージェントを組織の最も機密性の高いアプリケーションに接続できます。エージェントはデバイス上に存在しますが、CRM、SaaSアプリ、クラウドインフラストラクチャなどに直接アクセスするための呼び出しを行います。

OWASP Foundationは、「MCPツールのポイズニング」を重大な攻撃ベクトルとして文書化しており、ツールの説明は通常、最初の接続時にのみレビューされるため、攻撃者が制御する、または侵害されたMCPサーバーが実行時にツールのメタデータを変更できると述べています。接続されると、変更されたツール定義がモデルのコンテキストウィンドウに読み込まれ、実行を乗っ取ってデータを流出させます。

インシデントが発生した場合、貴社のセキュリティチームは、これらのエージェントの名前、所有者、アクセス可能なアプリとデータを特定できますか？多くの組織ではそれが不可能です。

この問いに答えられない場合、セキュアなエージェント型エンタープライズのブループリントで最初に挙げられている「自社のエージェントはどこにいるのか」という問いにも答えることはできません。

これがすべてのデバイスに拡大すると、リスクは急速に増大します。

監視されていないAIエージェントは、どのようにしてエンタープライズのセキュリティコントロールをバイパスするのでしょうか？

ローカルAIエージェントは、未レビューのMCP接続を使用し、個別のエージェントアイデンティティを持たずに人間のユーザー権限を継承し、永続的なスタンディングアクセスを維持し、実行時にツールを改変することで、エンタープライズのセキュリティコントロールをバイパスします。これらすべてのアクティビティは、IT部門が集中管理する監査ログを生成することなく実行されます。

こうした脆弱性の背景には、エンドポイントの可視性の欠如という1つの根本原因があります。セキュリティチームがAIエージェントや、エージェントが接続するMCPサーバーを可視化できない場合、標準的なアイデンティティとアクセス管理のフレームワークは機能しません。 

エージェントが制御を回避する主な5つの方法を以下に示します。

1. MCPサーバーは、ユーザーが知らないうちにエージェントをビジネスシステムに接続します。

機密システムにアクセスするMCPサーバーの構築と接続は非常に簡単であり、それを使用するには、ターミナルでコマンドを1つ実行するだけで済みます。承認されていないエンドポイントエージェントを、Snowflakeテナントなどのアプリケーションに接続するのは、ほんの数分で完了します。そのAIエージェントは、最も機密性の高いシステムで稼働するようになり、あなたが承認したり把握したりすることなく、閲覧できるすべてのテーブルにクエリを実行できます。

生産性の向上という魅力に後押しされ、従業員はセキュリティへの影響を考慮せずに、こうしたサーバーをAIエージェントに接続してしまいます。

セキュリティ対策が追いつかないと、重要な接続が監視もレビューもされないまま放置されてしまいます。つまり、機密性の高いデータへの接続がいつまでも維持され、その接続が何にアクセスしたかについて責任を負う者がおらず、最終的に問題が発生したときに確認できる記録もない、という状態になりかねません。それは、いつ侵害が起きてもおかしくない状態です。

2. 一元的にレビューされていないシステム間でデータが移動する

エージェントは、目の前のタスクに何が有用かを自ら判断し、データを移動させます。その判断では、データの分類、データレジデンシー規則、誰が何に対する閲覧権限を持っているのかといった点は考慮されません。その決定は承認もされていません。エージェントがアクセスできる対象を統制するポリシーがないため、エージェントは一度に複数のシステムに接続することになり、その組み合わせがリスクを生み出します。 

たとえば、顧客データを読み取れるエージェントが、誰にでもメールを送信できる可能性があります。これが広範な権限の例です。エージェントは1つのアクションを完了するために必要なデータ以上のデータを閲覧できてしまいます。その結果、たった1つの侵害されたプロンプトが大規模な侵害の引き金となります。

3. エージェントは自身のアイデンティティを持たず、他者のアクセスを介して動作する

エージェントは通常、OAuthグラント、またはMCPサーバーの構成ファイルに保存されているAPIキーを介してシステムに対して認証を行います。一度エージェントが関与すると、あるアクションが本人によるものなのか、本人に代わって実行しているエージェントによるものなのかを確実に判断する方法がありません。同じアイデンティティの下で紐付けられています。そのため、何か問題が発生した場合に、誰もが最初に尋ねるであろう「それは本人によるものか、エージェントによるものか」という問いに答えることができません。

例えば、経理担当者のエージェントが夜間にベンダーの支払記録を更新する場合などです。ログには、従業員の認証情報によって変更が行われたことが示されていますが、その変更を従業員本人が行ったのか、それとも従業員のエージェントが行ったのか、また、その変更がレビューされたかどうかを判断する方法がありません。

誰がアクションを実行したかという問いに答えるには、エージェントがアクセスしたすべてのシステムからログを収集し、相互に連携するように作られていない形式のタイムスタンプを手動で相互参照する必要があります。本来なら数分で終わるはずの作業が、分断されたシステムをまたいで単一のアクションを再構築するために何日もかかってしまいます。

4. エージェントは一度だけ権限を求め、永続的なアクセス権を取得する

数か月前まで、私たちのほとんどはAIエージェントが何をしているのかについて、まだ懐疑的でした。エージェントが追加の権限を必要としたり、システムAPIを呼び出そうとしたりするたびに、プロセスを停止してチェックを行いました。今では、自律的に実行できるようになっています。エージェント型ツールには、一度設定した許可/拒否ルールに基づいて、エージェントがツール呼び出しを自律的に実行し続ける自動モードが搭載されています。

例えば、従業員が複雑で時間のかかるタスクをエージェントに割り当て、自動的に実行されるように設定したとします。その過程で、エージェントはタスクを完了するためにSalesforceやSnowflakeのレコードを変更することが正しい方法だと自ら判断し、それを実行します。従業員はその特定のアクションを承認しておらず、そのアクションが発生したことさえ認識していない可能性があります。何かが壊れたり、見た目がおかしくなったりするまで、誰も変更内容をレビューしません。

5. MCPサーバーは、管理者が制御できないアクセス権をエージェントに付与します

MCPサーバーは、エージェントにツールのリストを提供します。各ツールには、いつ、どのように使用するかを説明する記述が含まれています。そのサーバーを作成した担当者がこれらの説明を記述したのであり、IT部門やセキュリティチームではありません。ユーザーはメニューに表示された名前を見て、サーバーを構築したのが誰か、あるいはサーバーで何が実行されているかを確認することなく「承認」をクリックしました。

また、説明は固定されたものではありません。MCPサーバーの所有者が説明を編集したり、権限を変更したり、ツールを追加したりすると、エージェントは再承認やレビューなしでそれを自動的に取得します。月曜日に実行されたものが、金曜日に実行されるものと必ずしも同じとは限りません。

次に例を示します。従業員が自分のエージェントにツールを追加します。MCPサーバーの所有者が、その動作を変更するアップデートをプッシュします。次回エージェントが接続すると、アラートや再承認なしで新しい機能が継承されます。

セキュリティチームがOkta for AI Agentsを使用してエンドポイントのシャドーAIを検出・保護する方法

これまで見たことのないエージェントのスコープ設定、レビュー、取り消しはできません。また、アイデンティティガバナンス下にないエージェントを完全に信頼することもできません。

Okta for AI Agentsは、このギャップを埋めるために構築されています。

1. エンドポイントのディスカバリー：エンドポイントで実行されている各エージェントとMCPサーバーを確認します。

Oktaは、既存のエンドポイントセンサーと連携して、AIエージェントと接続されたMCPサーバーを検出します。この機能は現在、CrowdStrike Falcon EDRで利用できるようになりました。追加のエンドポイントエージェントは必要ありません。これにより、Oktaのディスカバリー機能の対象が、ブラウザ外で稼働するエージェントや、OAuthの同意付与では表面化しないエージェントにまで拡大されます。Okta Verifyは、次に連携・提供を開始するソースです。これにより、エンドポイントのディスカバリーが特定のEDRに依存しなくなり、今後、他のEDRプラットフォームへも対応する予定です。

2. 正規のアイデンティティとして登録：一元化されたディレクトリへの登録

エージェントは、他の非人間アイデンティティ、AIエージェント、さらには人間アイデンティティとともにUniversal Directoryに登録されます。各エージェントには一意のアイデンティティが与えられます。これにより、エージェントがアクセスできる対象を定義し、完全な監査証跡を取得できます。

3. アイデンティティのマッピングと関連付け：エージェントと人間のオーナーの紐付け

検出されたエージェントは、特定の認証済み人間アカウントにリンクされるため、セキュリティチームは人間と非人間のエンティティを一元的に完全に可視化できます。このマッピングは変更があっても維持されます。所有者が役割を変更したり退職したりした場合や、委任チェーンでサブエージェントが作成された場合でも、所有権のコンテキストは失われることなく、相関関係が保たれます。

4. ランタイム認可：アクションポイントでのポリシー適用

Agent Gatewayを使用すると、セットアップ時に一度だけでなく、ツール呼び出しが実行されるたびにアクセスポリシーを適用できます。エージェントは、永続的な認証情報ではなく、有効期間の短いトークンのみを保持します。また、アクセス権は、次回のアクセスレビューで変更が検出されるのを待つことなく、ゲートウェイで即座に取り消すことができます。

5. 継続的なアクセスガバナンス：アクセスレビューとアクセス権の取り消し

人間のアイデンティティとともにエージェントも対象とした定期的なアクセスレビューを実施することで、セキュリティチームはエージェントのアクセスがすべてレビュー・承認されたことを監査人に証明できます。また、エージェントが逸脱したり、侵害されたりした場合は、キルスイッチがそのエージェントを無効化し、接続されているすべてのシステムへの新たなアクセスを終了させます。

エンタープライズAIを自在に制御

セキュアなエージェント型エンタープライズの青写真を入手して、エンタープライズAIをセキュアにスケールさせる方法の詳細をご覧ください。

提供状況：Shadow AI Agent Discovery for Endpoints機能は、Identity Security Posture ManagementおよびOkta for AI Agentsをご利用のお客様向けに、CrowdStrike Falcon EDRとの連携を通じて早期アクセスで提供されるようになりました。すでにCrowdStrikeを実行されている場合、既存のセンサーがソースとなるため、エンドポイントに新しく追加されるものはありません。

本資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言を意図したものではありません。セキュリティ、プライバシー、コンプライアンス、またはビジネスに関するアドバイスについては、お客様ご自身の専門アドバイザーにご相談ください。本ブログで言及されている将来の製品、機能、仕様、認定に関する記述は、情報提供のみを目的としています。これらは提供を確約するものではなく、購買の意思決定を行う際に依拠すべきものではありません。© Okta, Inc. and/or its affiliates 2026.