「AIエージェントを本番環境に投入しているが、セキュリティ面は本当に大丈夫だろうか」——そう感じている方も多いのではないでしょうか。エンタープライズAIエージェントは、実験段階から本番導入へと急速に移行しています。Microsoft Copilot Studioのようなツールを使えば、社内システムを参照し、業務データを取得し、実際にアクションを実行するエージェントを、チームがごくわずかな開発工数で構築できるようになりました。

ただし、この手軽さには代償もあります。見過ごされがちな、しかし年々増えているセキュリティ上のミスを生み出しているのです。こうしたエージェントを基幹システムへどう安全につなぐかという設計判断こそが、本記事で取り上げるセキュリティ課題の出発点です。具体的な接続設計の考え方は、AIエージェントを基幹システムに安全に接続する方法でも解説しています。

そもそもプロンプトインジェクションとは、細工した入力によってAIエージェントに本来の指示を上書き・無視させ、想定外のデータ開示や操作を引き出す攻撃手法です。エンタープライズ環境では、アクセス制御を強制力のある権限設定ではなくプロンプトに頼っているときに、この一手だけで防御が崩れてしまう点が問題になります。

先日、Tenableが公開した記事で、単純なプロンプトインジェクションによってCopilot Studioエージェントが機密データを漏えいさせた事例が報告されました。この事例で顧客対応エージェントは、クレジットカード情報を含む社内SharePointのコンテンツにアクセスできる状態にあり、頼みの綱は「他の顧客のデータを不適切に共有しない」という指示ただ一つでした。この特定の構成を多くの本番環境で見かけることは少なく、どこまで一般的な事例なのか疑問に思う方もいるでしょう。

それでも、この事例はTenableが選んだシナリオを超えて広く当てはまる、より深刻な問題を浮き彫りにしています。問題はSharePointやクレジットカードそのものではありません。問題は、言語モデルをセキュリティの境界として頼ってしまうことにあります。

なぜモデルにセキュリティを任せられないのか？

モデルはプロンプトの指示に忠実に従うよう設計されているため、アクセス制御の代わりにはなりません。セキュリティは、モデルが呼び出される前のプラットフォーム層で強制してこそ意味を持ちます。

多くの企業がエンタープライズAIエージェントの構築を急ぐ中、モデルに本来担うべきではない役割を暗黙のうちに背負わせているケースが目立ちます。エージェントが取得すべきデータや実行すべきアクションを制限しようと、プロンプトに指示を書き加える。ガードレールは自然言語で表現され、モデルが常にそれを守ってくれることを期待する、という具合です。

しかし、その期待は実際には成り立ちません。

プロンプトが定義するのはユーザー体験であって、アクセス制御ではありません。プロンプトインジェクションは驚くほど簡単に成立しますし、モデルはそもそも「役に立ち、柔軟であること」を優先するよう最適化されています。エージェントがあるデータを見られる状態にある限り、十分に工夫されたプロンプトはいずれそのデータを引き出す方法を見つけ出すでしょう。実際、セキュリティ診断企業のGMO Flatt Securityは、インストラクション・ディフェンス、ポスト・プロンプティング、XMLタギングといったプロンプト側の防御策を最新モデルで検証し、いずれも回避できることを実証しています。プロンプトの工夫は緩和策にはなっても、防御の土台にはならないのです。

プロンプトインジェクションが単なるモデルの問題ではなく、エンタープライズAIのセキュリティアーキテクチャの問題である理由はここにあります。モデル自体に悪意があるわけではありません。与えられた権限の範囲内で、忠実に動いているだけなのです。

これは、まさにTenableの調査が示した内容です。このエージェントは、プラットフォームレベルで機密データへの正当なアクセス権を持っていました。データ漏えいを防いでいたのは、たった一つの指示だけです。その指示が回避された瞬間、モデルは設計どおりに動作しただけでした。

Tenableのシナリオはなぜ非現実的でも重要なのか？

Tenableが使用した「社内SharePointデータにアクセスできる顧客対応エージェント」という具体的なシナリオは、実際の企業がシステムを設計する際の一般的な構成ではありません。顧客対応エージェントは通常、社内のコラボレーションシステムから切り離されており、機密データもそれに応じて区分されています。

とはいえ、シナリオが多分に理論的だからといって、その調査結果の価値が下がるわけではありません。

この事例の本当の価値は、その実行モデルにあります。エージェントは広範なアクセス権を持つIDで動作しており、セキュリティは「何を開示すべきでないか」という指示をモデルが守ることに依存していました。エージェントがこの立場に置かれた時点で、結果はほぼ決まっているのです。

しかも、これは机上のリスクではありません。Vanna（CVE-2024-5565）やPandasAI（CVE-2024-12366）では、プロンプトインジェクションを起点とした任意コード実行の脆弱性が実際に報告されています。三菱総研DCSの検証でも、GPT-3.5環境で役割変更やシステムプロンプトの抽出が現に成立しました。過剰な権限を持つIDと組み合わされば、こうした攻撃はそのまま実害につながります。

モデルが門番の役割を担わされてしまいますが、モデルはその役割のために作られてはいません。そして、この同じ設計ミスは、はるかに現実的で、はるかにありふれた社内ユースケースにも繰り返し現れます。

現場でありがちな失敗パターンとは？

営業担当者が取引先を分析し、進行中の商談を確認し、次のアクションを計画するのを助ける、社内向けのSales Copilotを例に考えてみましょう。このパターンは、営業・サポート・財務・オペレーションで使われる社内AIエージェントで繰り返し見られます。

開発を早めるため、エージェントは広範な権限を持つアカウントでSalesforceに接続されます。そしてプロンプトの指示には、「ログインユーザーの担当地域に関連するデータだけを返すように」と書かれています。

一見すると安全に思えます。エージェントは社内向けで、利用者は自社の従業員だからです。

しかし実際には、すべてのクエリが同じIDで実行されています。そのIDはすべての取引先、すべての商談、さらには関連する多くのオブジェクトまで見ることができ、結果を正しく絞り込む役目は指示だけを頼りにモデルへ委ねられているのです。

この時点で、根本的な問題はプロンプトインジェクションではありません。過剰な権限を持つIDそのものが問題の正体です。

ユーザーが予想外の質問をしたり、意図的にエージェントを探ったりするだけで、本来見えるはずのないデータが表面化する可能性があります。エージェントに書き込みや削除の権限まで与えられていれば、リスクは意図しない情報開示から意図しない操作へと一気にエスカレートします。こうした条件下でモデルに振る舞いの制限を委ねるのは、根本的に危険です。同様の課題はSalesforceに限らず、Db2やSnowflakeのような基幹データベースにエージェントを接続する場合にも共通しており、Db2・SnowflakeとAIエージェントを安全に連携させる実装例が参考になります。

なぜプラットフォーム層で守るべきなのか？

AIエージェントのセキュリティを考える正しい出発点は、プロンプトの言い回しではなく、IDと実行コンテキストです。セキュリティは、データがAIツールに届く前の、独立したプラットフォーム層で管理してこそ機能します。エージェントのすべての操作は、共有アカウントや権限昇格したアカウントではなく、特定のユーザーIDとして実行されるべきです。エージェントを人間のユーザーと同じ発想でIDに紐づけて管理するこの考え方は、エージェントをアプリと同じIDモデルで扱う設計思想とも共通しています。

Aliceが質問をすれば、エージェントが見せてよいのはAliceに許可された範囲のデータだけです。同じ質問をBobがした場合は、Bobのアクセス権が狭い分、見えるデータも少なくなります。SalesforceやSharePointのようなシステムが備えるネイティブな権限モデルは、自動的に強制されるべきです。

データソースのシステムが十分な粒度の権限管理を提供していない場合は、エージェントとデータをつなぐプラットフォーム側でそれを補う必要があります。最小権限を強制する場所は、モデルではなく、このプラットフォームであるべきです。

ここで重要になるのが、CData Connect AIのようなマネージドMCPプラットフォームです。

IDが違うと、結果はどう変わるのか？

今度は、同じSales Copilotをマネージド型のMCPプラットフォーム上に構築した場合を考えてみましょう。

このエージェントは、取引先と商談を扱い、分析とレコメンデーションを提供する範囲に明示的にスコープが絞られています。Salesforceのスキーマ全体に無制限にアクセスできるわけではありません。

システム管理者のAliceが、パイプラインのリスクについて質問します。エージェントがAliceのIDでデータを取得するため、彼女は自分の役割が許可する範囲で、すべての取引先と商談を確認できます。

西日本エリアの営業担当であるBobが、まったく同じ質問を投げかけます。今度はBobのIDに紐づく権限で処理されるため、確認できるのは自分の担当エリアに割り当てられた取引先と商談だけです。

Bobはプロンプトインジェクションを試すこともできます。関連のないオブジェクトや機密フィールドを取得するようエージェントに依頼することも可能です。モデルはそれに応じようとするかもしれませんが、アクセス制御はクエリが実行される前の段階で強制されています。Bobに許可されていない範囲であれば、何も返ってきません。

Connect AIならではの特長として、承認済みのオブジェクトだけを含む専用のワークスペースや派生ビューにエージェントを限定することで、さらに露出を抑えられます。Bobが他の場所でより広い権限を持っていたとしても、このエージェントにその権限は引き継がれません。

Bobが商談の更新をエージェントに依頼しても、Connect AI層で書き込み権限が制限されていれば、エージェントはSalesforceに直接ログインするよう案内するだけです。セキュリティは、モデルが関与する前の段階で強制されているのです。

AIエージェントを守る4原則とは？

AIエージェントを安全に運用できている企業には、共通する一連の原則があります。これらの原則は、分散システムにおいてセキュリティが従来から効果的に強制されてきた方法そのものです。

1. アクセス制御をプロンプトに頼らない
   指示やプロンプトが定義するのは、エージェントがどう振る舞うかであって、何にアクセスできるかではありません。アクセス制御は、モデルが実行される前の、インフラまたはプラットフォーム層で強制すべきものです。モデルがデータを取得できる状態にある限り、プロンプトはいずれそのデータを引き出す方法を見つけ出すでしょう。

2. すべてのリクエストをエンドユーザーのIDとして実行する
   エージェントのすべての操作は、特定のID、理想的にはエンドユーザー本人のIDのコンテキストで実行されるべきです。そのIDが、エージェントが持ちうる権限の上限を決めます。共有IDや権限昇格したIDは被害範囲を大幅に広げ、規模が大きくなるほど正しい制御を不可能にします。

3. データソースのシステムを越えて最小権限を適用する
   データソースのシステムが備えるネイティブな権限は、可能な限り強制すべきです。それらのシステムの権限管理が十分な粒度を持たない場合は、その手前の段階で追加の制御を適用する必要があります。データセットの範囲を絞り込み、アクセス可能なオブジェクトを制限し、許可するアクションを限定する——これらはすべて、エージェントを承認された範囲内だけで動作させるために欠かせません。

4. 包括的な監査可能性を維持する
   エージェントのすべてのやり取りは、完全なコンテキスト付きで記録すべきです。誰がリクエストを開始したか、どのデータにアクセスしたか、どのアクションが試みられたか——ここまで残しておく必要があります。監査可能性は、コンプライアンスのためだけでなく、エージェントが想定外の振る舞いをした際にその原因を理解し、修正するためにも欠かせません。

これらの原則を組み合わせることで、企業は言語モデルを門番にすることなく、AIエージェントを安全にスケールさせられます。代表的なリスク類型ごとに、プロンプト頼みの防御がどこで破綻し、ID起点の設計がどう効くのかを整理すると次のとおりです。

なぜ「モデル実行前の制御」が鍵になるのか？

Tenableの調査から得られる本当の教訓は、「プロンプトインジェクションが存在する」ということではありません。AIエージェントは、企業システムにもともと存在していたIDと権限設定のミスを、増幅させてしまうということです。

セキュリティがインフラおよびプラットフォーム層で強制されていれば、プロンプトインジェクションの脅威度は大きく下がります。プロンプトの言い回しがどれだけ巧妙であっても、エージェントが実行時のIDに許可された範囲を超えてアクセスすることはありません。

これらの原則を実際に一貫して適用するには、その場しのぎの連携やプロンプトレベルの制御ではなく、エンタープライズAIエージェント向けに設計されたインフラが必要です。CData Connect AIのようなマネージドプラットフォームを使えば、この考え方を現場のチームが実践しやすくなります。実際に、ClaudeのようなAIアシスタントとConnect AIを組み合わせる具体的な方法は、Connect AIとClaudeを連携させる方法で紹介しています。

IT部門はID起点のアクセス制御・最小権限・監査可能性をアーキテクチャレベルで強制できます。その一方で開発者やシチズンインテグレーターは、役立つエージェントを素早く安全に構築できるようになるのです。実際に、あるテクノロジー企業では、給与や財務といった機密データをダウンロードさせることなく、経営陣がライブダッシュボードへ安全にアクセスできる仕組みを実現しています（テクノロジー企業の導入事例）。

最も安全なAIエージェントとは、最も入念に書き込まれたプロンプトを持つエージェントではありません。そもそもアクセス権のないデータを一度も目にすることのないエージェントです。プロンプトインジェクション対策はID起点のアクセス制御が核心ですが、より広範なガバナンスの観点まで含めた全体設計については、AIエージェントガバナンスのベストプラクティスで体系的に解説しています。

プロンプトインジェクションに関するよくある質問

AIエージェントの権限をIDで制御する

プロンプトの巧妙さに頼ったセキュリティは、いずれ突破されます。CData Connect AIなら、エージェントのすべての操作をユーザーIDに紐づけて実行し、モデルが呼び出される前にアクセス範囲を制御できます。SDKの実装やアクセス権限の個別設定に追われることなく、IT部門は最小権限と監査証跡をアーキテクチャレベルで組織全体に強制できるようになります。

Connect AIの14日間無料トライアルを今すぐ開始して、モデル実行前にアクセスを制御する仕組みを試してみてください。