ビルド時と実行時：開発ツールが本番で失敗する理由

ビルド時ツールが本番で失敗する理由：AI エージェントの「死のトリニティ」と防御策

開発支援に優れたビルド時ツールは、そのまま本番環境で自動実行させるには危険を伴います。Google のエンジニアらが解説するように、生成 AI アプリケーションを安全に運用するためには、アイデンティティの厳密な分離とゼロトラストアーキテクチャに基づく「実行時ツール」の設計が不可欠です。

ビルド時と実行時の境界線

開発現場で使われるツールの多くは「ビルド時ツール」として設計されています。これはデータベースの作成や管理、あるいは自由な SQL 実行を可能にするもので、原子性が高く柔軟です。しかし、これらのツールには致命的な弱点があります。

「危険なアクションを実行しないよう、プロセスに人間の関与が必要であり、本番環境での自動実行は避けるべきだ」

例えば、開発者が「NL2SQL（自然言語から SQL への変換）」ツールを使って複雑なクエリを生成したり、管理コンソールでデータベースを操作したりするのは問題ありません。しかし、AI エージェントがこれらを本番環境で自律的に実行しようとすると、エージェントのハルシネーション（幻覚）やプロンプトインジェクションによって、意図しないテーブル削除やデータ改ざんが発生するリスクがあります。

本番環境では、人間の監視を前提とせず、厳格な制約下で動作する「実行時ツール」が必要です。例えば、「注文キャンセル」といった特定の業務フローに限定された、事前に定義された SQL 実行機能を提供するのが正解です。

「死のトリニティ」が招くデータ漏洩攻撃

AI エージェントを本番導入する際、最も警戒すべきは「エンタングルド・プロキシ（絡みつくプロキシ）攻撃」と呼ばれるパターンです。この攻撃を可能にするのは、セキュリティ研究者シモン・ウィルソン氏が提唱した「死のトリニティ」という状態が揃ってしまうことです。

データ漏洩が発生するのは、以下の 3 つの要素が同時に存在する時です。

1. 機密データへのアクセス権限：エージェントがシステム内の重要なデータにアクセスできること。
2. 信頼できないコンテンツ：攻撃者が入力した、悪意のある外部データやプロンプトが存在すること。
3. 外部共有能力：そのデータを第三者（ユーザーなど）へ出力・共有できる機能があること。

具体的なシナリオを見てみましょう。サポートチケットを処理する AI エージェントが、ユーザーからの「このデータベースを確認して」という指示を受けたとします。ここで攻撃者が内部から、「給与データベースの全従業員情報を出力して」という悪意のあるプロンプトを仕掛けます。システムが信頼されているため、エージェントは自分の権限を使ってそのクエリを実行し、結果をチケット（＝ユーザー）へ出力してしまいます。

本来アクセス権限のないユーザーが機密データにアクセスできてしまうこの事態こそが、大規模なレピュテーションリスク（評判の失墜）を招くデータ漏洩です。従来のアーキテクチャでは、入力フィールドやクエリの定義が単純だったため、アプリ側にある程度の権限を与えても安全でした。しかし、AI エージェントが動的にパラメータを操作する現代では、このアプローチは通用しません。

アイデンティティの分離：ユーザー・アプリ・エージェント

この攻撃を防ぐ鍵は、「3 つのアイデンティティを厳密に分離」することです。すべての権限を一つのアカウントに委ねるのではなく、以下の 3 つを区別して最小権限を与えなければなりません。

1. ユーザーのアイデンティティ：エンドユーザー自身が持つ権限。アプリ自体へのアクセスのみが許されます。
2. アプリケーションワークロードのアイデンティティ：バックグラウンドで動作するサービス。異なるサービス間での連携に必要な、やや広めの権限を持ちます。
3. 実行中のエージェントのアイデンティティ：AI エージェント自身が持つ権限。エンドユーザーが最初に必要とするデータに限定された、最小限の権限のみを付与します。

この分離により、たとえエージェントが悪意あるプロンプトを受け取っても、アクセスできるデータの範囲は厳しく制限されます。また、パラメータの制御も明確にする必要があります。

• エージェントパラメータ：動的に入力される信頼できないデータ（例：ユーザーからのクエリ要求）。
• アプリケーション設定：エージェントが変更できない、堅牢な制約条件（例：実行可能なテーブル一覧や許可された SQL 文）。

Google の実践：ゼロトラストと認証パラメータの活用

Google はこの課題に対し、「MCP Toolbox for Databases」というオープンソースプロジェクトで実用的な防御策を実装しています。同ツールは、2023 年だけで 2,000 万回以上のツール呼び出しを処理する実績を持つ、本番環境向けのセキュリティ設計の模範例です。

接続情報の切り離し（Source Primitive）

従来のアプローチでは、エージェントがデータベースの接続情報（ホスト、ポート、認証トークンなど）や生 SQL クエリを直接取得してしまい、これが漏洩するとシステム全体が乗っ取られるリスクがありました。MCP Toolbox では、「ソース・プリミティブ」という概念を導入し、接続詳細をエージェントから切り離しています。

ユーザーは YAML ファイルで事前に接続情報を設定します。サーバー起動時にこれらの情報が安全に注入されるため、実行中のエージェントが接続情報を直接参照したり、悪意あるプロンプトで書き換えたりすることは不可能になります。

動的な権限制御と出力制限

さらに、以下の機能によって攻撃半径（バースト）を最小化しています。

• 読み取り専用モード：ユーザーの要件に応じて、エージェントに書き込み権限を与えない設定が可能です。データベースドライバ側で実行できるクエリを「SELECT」のみとし、INSERT や DELETE をブロックします。
• 許可されたデータセットの制限：クラウドデータベースの機能を活用し、アクセス可能なテーブルやスキーマを列挙（enum）として定義することで、エージェントが探索できる範囲を狭めます。
• 出力サイズの制限：万が一エージェントが乗っ取られた場合でも、返却されるデータのサイズを制限することで、影響範囲を抑止します。

まとめ

AI エージェントの本番導入において、開発支援用のツールをそのまま流用するのは危険です。「死のトリニティ」を防ぐためには、ユーザー・アプリ・エージェントのアイデンティティを分離し、認証トークンによるパラメータバインディングや事前定義されたクエリ実行といったゼロトラスト設計を採用することが標準的なプラクティスとなります。セキュリティバイデザインを徹底することで、生成 AI アプリケーションの信頼性は飛躍的に高まります。