AIエージェントのデータセキュリティ：エージェントがシステムに接続すると何が起きるのか？

AIは、答えを生成する段階から実システムでアクションを起こす段階へと移りつつあります。この変化により、セキュリティ上の中心的な問いも変わります。モデルが正確かどうか、信頼できるかどうかを問うだけでは十分ではありません。モデルが指示を誤解したり、悪意ある入力に遭遇したり、タスクに必要な以上の権限を与えられたりした場合、周辺のシステムがどのように振る舞うかも問わなければなりません。MCPのようなプロトコルはエージェントとシステムの接続を構築しやすくしますが、同時にその接続設計を無視できなくします。

AIエージェントを業務システムに接続すると、AIホスト、ツールサーバー、IDプロバイダー、下流のアプリケーションといった異なるコンポーネントに、異なる種類のデータが露出する可能性があります。MCPは接続の各部分がどのように通信するかを定義しますが、各実装がどのデータを保存し、公開し、保持するかまでは決めません。

応答から結果へ

エージェントを接続しても信頼境界は一つにはなりません。AIホストがリクエストを解釈し、プロトコルクライアントが機能を選び、ツールサーバーが呼び出しを検証・変換し、IDプロバイダーが実行者を確定し、下流のシステムが権限を適用して結果を記録する──こうした連鎖が生まれます。MCPはその通信の一部を標準化しますが、連鎖全体をそれだけで安全にするわけではありません。セキュリティは各レイヤーでの設計判断に依存します。

広く使われた第一世代の生成AIは、主に人がレビューするためのテキスト、画像、要約、コードなどを出力していました。現在はエージェントがツールを操作することが増えています。メッセージを送信し、記録を修正し、ワークフローを起動し、送金を行い、物理的なプロセスを制御するのです。もっともらしいが不正確な回答は不便にとどまりますが、もっともらしいが不正確なアクションは即座に現実的な影響を及ぼす可能性があります。

MCPのような標準により、ツールは構造化されたインターフェースを通じて発見・呼び出し可能になります。画面スクレイピングや応急的な統合に比べて重要な前進ですが、構造があるだけではセキュリティポリシーとはなりません。どのアクションを用意し、どんな入力を受け入れ、誰のIDを使い、どんな証跡を返すかは依然としてツール設計者の判断です。

私たちはezeepのMCPサーバーを構築する過程で、この区別に直面しました。印刷は問題が分かりやすいケースです。エージェントの判断が数秒で物理的な出力になることがあるからです。ただし、この教訓はあらゆる運用システムに当てはまります。

データは実際にどこへ行くのか

「モデルがパスワードを見ない」は便利な説明ですが、データフローの全容を示すものではありません。典型的なエージェント接続には、認証レイヤーで扱われる認証情報、ユーザーのリクエストから作られるツールの引数、モデルに返される運用結果、下流サービスへ転送される業務ペイロード、そして一つ以上のコンポーネントに保持されるログなど、複数の情報カテゴリが関与します。モデルが通常受け取るのは、会話の内容、利用可能なツールの説明、選択したツールを呼び出すための引数、そしてそのツールが返す結果です。

これらの情報カテゴリは必ずしも同じ経路をたどるわけではありません。OAuthによりパスワードやベアラートークンをモデルの文脈外に保つことはできますが、ツールの結果は顧客名、デバイスの位置、金額、あるいは内部システムのメタデータを露出する可能性があります。ドキュメント自体はサービス間で直接転送される一方で、そのファイル名、宛先、ステータスが会話に現れることもあります。AIホスト、ツールサーバー、IDプロバイダー、ターゲットシステムは、それぞれ異なるログ記録や保持ポリシーを持っている場合もあります。

したがって「AIはデータを見ない」といった一律の主張は成り立ちません。問うべきは、各レイヤーがどのデータを受け取り、それをなぜ必要とし、どのくらいの期間保持し、ユーザーがその境界を理解しているかです。私たちのMCP実装はこれらの違いを示す具体例を提供しますが、この設計上の問題はエージェント接続されたすべてのシステムに共通しています。

IDが影響範囲を決める

エージェントは独立した権限を持つべきではありません。エージェントは共有のサービスIDを使って行動するか、個々のユーザーに代わって行動するかのどちらかになりますが、どちらも常に正しいわけではありません。共有IDは無人のワークフローに適していますが、そこで行われるすべての操作がそのアカウントの権限範囲を受け継ぎます。ユーザーごとの認可はアクセスを限定し帰属を明確にしますが、全ユーザーの認証とアプリケーション側での個別セッション管理が必要です。エージェントによるリクエストの解釈が、ターゲットシステムで強制される認可の代わりになることは決してあってはなりません。

重要なエンジニアリング上の判断は、どのモデルが抽象的により「安全」に聞こえるかではありません。重要なのは、アイデンティティがワークフローに合っているか、そしてその権限がミスの影響よりも狭く抑えられているかどうかです。ezeep MCPの開発作業では、自動化された倉庫サービスと従業員の対話的な印刷では求められるアイデンティティ要件が実際に異なるため、両方のモデルをサポートしています。

AIエージェントがアクションを実行したとき、誰が責任を負うのか？

これは単にモデルをどれだけ信頼するかの問題ではなく、システム設計の問題です。より安全なアーキテクチャは次のような複数の制御を組み合わせます：最小権限のアイデンティティ、限定的かつ型付けされた機能、下流システムでの検証、重大なアクションの確認、信頼できる指示と信頼できないコンテンツの分離、そして実際に何が起こったかを示す監査証跡です。スコープを限定することで潜在的な損害を抑え、可観測性と帰属によってアクション後の説明責任を確立します。

可逆性を考慮した設計

エージェントの機能を評価する際、有効なテストはそのアクションが許可されているかだけでなく、誤った場合に何が起きるかを含みます。読み取り操作、回復可能な変更、金銭的なコミットメント、外部への通信、破壊的な管理操作は、それぞれ異なる制御を必要とします。確認が必要なアクションもあれば、ロールバックをサポートすべきアクションもあります。逆に、エージェントに一切公開してはいけないアクションもあります。

ezeepのMCPサーバーを構築する際、関連するREST APIが存在していても、ユーザー、グループ、プリンターの削除を公開しないという選択をしました。これで残りのツールが無害になるわけではありません（印刷は物理的な出力を生み、管理ツールはアクセス権を変更できます）が、取り返しのつかないミスの一類を排除できます。この原則は印刷に限りません。機能設計は単に技術的に可能かどうかではなく、その結果の重大さを反映すべきです。

プロンプトインジェクションはAIエージェントに誤った行動をさせるか？

はい。エージェントはドキュメント、ウェブページ、メール、サポートチケット、あるいはツールの出力に隠れた指示に遭遇する可能性があります。これは一般に間接的プロンプトインジェクションと呼ばれ、データとして扱うべきコンテンツがエージェントの次の行動に影響を与えようとするものです。

そのリスクはモデルに「注意するように」と指示するだけでは解決しません。信頼できないコンテンツが権限を付与したり、ユーザーの目的を変更したり、より高権限のアイデンティティを選択したり、確認を回避したりしてはなりません。ツール入力には決定論的な検証が必要であり、重大なアクションにはモデル外でのポリシーチェックが必要です。機密性の高いワークフローでは、信頼できる指示と信頼できない素材を明確に分離してください。

ツールのサプライチェーンも重要です。ツールの説明はモデルの振る舞いに影響を与えるため、新しいサーバーを接続すること自体が単なる利便性の設定ではなくセキュリティ上の判断になります。

セキュリティはあらゆるレイヤーで決まる

エージェントを実システムに接続する設計判断は、どのアクションを用意するか、どのアイデンティティを使うか、各コンポーネントがどのデータを見るか、何が元に戻せるか、何を記録するか、などあらゆるレイヤーで行われます。MCPはその会話の一部を標準化しますが、残りは接続を構築する人々の判断に委ねられます。ezeepのMCPサーバーでは、サービス用とユーザーごとの両方のアイデンティティをサポートしつつ、ユーザー、グループ、プリンターの削除を公開しないという方針を取りました。どのエージェントもいずれは誤りを犯すため、接続はその瞬間を想定して設計される必要があり、ezeepのMCPサーバーはまさにそのように構築されています。

ezeep MCPを使ってみませんか？

今すぐお使いのエージェントにezeep MCPを接続してください。

無料で試す