Model Context Protocol を使用したエージェントのインタラクションを保護するためのベストプラクティス

MySQL | PostgreSQL | SQL Server

Model Context Protocol（MCP）は、生成 AI エージェントが Cloud SQL for SQL Server に接続する方法を標準化します。自律型エージェントには固有のリスクがあるため、プロンプトインジェクションなどの脆弱性を軽減するには、プラットフォーム制御と安全なアプリケーション設計を組み合わせた責任共有モデルが必要です。
Model Context Protocol（MCP）ツールを使用する AI アプリケーションを設計してデプロイするには、このガイドのベストプラクティスに従ってください。 Google Cloud

始める前に

MCP ツールを使用する場合、アプリケーションのセキュリティポスチャーはエージェントのインタラクションモデルによって異なります。エージェントの使用が、エージェントと MCP サーバーの統合に関連するセキュリティリスクにどのように影響するかについては、AI のセキュリティと安全性をご覧ください。

セキュリティの責任

お客様は、エージェントプラットフォームの安全な構成と運用に責任を負います。

最小権限の原則に従う

最小限のスコープのサービスアカウントでエージェントを実行します。これは、最初で最も重要な防御レイヤです。

専用の ID: MCP ツールを使用して、一意のエージェントまたはアプリケーションごとに専用のサービスアカウントを個別に作成します。既存の SA、特に広範な権限を持つ SA は再利用しないでください。
最小限のスコープ: サービスアカウントに必要な Identity and Access Management（IAM）ロールのみを付与します（alloydb.admin ではなく alloydb.viewer など）。エージェントが特定のデータセットへの読み取りアクセスのみを必要とする場合は、カスタム IAM ロールを使用して、その機能に必要な最小限のアクセスに制限します。
職務の分離: エージェントがデータへの読み取りアクセスとログまたは一時ストレージへの書き込みアクセスの両方を必要とする場合は、2 つの別々のサービスアカウントを使用します。1 つはリスクの高いデータアクセス用（最小限のスコープ）、もう 1 つはリスクの低い運用タスク用です。

データベースネイティブのきめ細かい制御を使用する

最も強力な防御を行うには、IAM ロールとデータベース自体が提供するきめ細かいアクセス制御を組み合わせます。これにより、攻撃者がエージェントの IAM トークンを侵害した場合でも、損害の範囲はデータベースエンジンの内部権限によって制限されます（DROP TABLE コマンドの防止など）。

プロダクト	粒度制御メカニズム	焦点
Cloud SQL と AlloyDB	PostgreSQL と MySQL の CREATE ROLE などのデータベースレベルのロール。	特定のデータベースインスタンスとスキーマの権限を管理します。
BigQuery	列レベルのアクセス制御（ポリシータグを使用）	承認されたテーブルでも、機密性の高い列（PII など）へのエージェントアクセスを制限します。
Spanner	きめ細かいアクセス制御（`GRANT/REVOKE` を使用したデータベースロール）	テーブルと列に対する正確な読み取り/書き込み/更新権限を適用します。
Firestore	IAM ロールと IAM 条件	IAM ロールと IAM 条件を使用して、データベースごとのアクセス権を構成します。
Bigtable	IAM ロール	Bigtable では、プロジェクト、インスタンス、テーブルのレベルで IAM ロールを使用してきめ細かい制御が可能です。

安全なエージェント設計

エージェント専用モデルでは、システムプロンプトをオーバーライドしようとするプロンプトインジェクション攻撃に対して、アプリケーションレベルで堅牢な防御が必要です。詳細については、AI の安全性とセキュリティをご覧ください。

データとユーザー入力を信頼できないものとして扱う

エンドユーザーからの入力、またはエージェントがウェブ検索結果やサードパーティドキュメントなどの外部ソースから取得したデータは、信頼できないものとして扱います。

アクション選択パターンを実装する

システムが高レベルのタスク仕様を機械的な実行から切り離す、オープンエンドの プランと実行 アーキテクチャ は避けてください。代わりに、モデルの自由度を制限する設計パターンを使用します。

アクションセレクタパターン: モデルの唯一のジョブは、ユーザーリクエストを、事前に定義された安全な関数の小さなセットのいずれかに変換することです。アクションロジックはハードコードされており、LLM で変更することはできません。これにより、エージェントは制御フローをターゲットとするインジェクション攻撃に対して免疫を持つことができます。
デュアル LLM パターン: コアタスクを実行するプライマリ LLM（アクション LLM）と、悪意のある意図がないかユーザープロンプトを事前スクリーニングし、不正なアクションやデータ漏洩がないかアクション LLM の出力を事後スクリーニングするセカンダリの安全性の高い LLM（ガードレール LLM）を使用します。

不正なツールチェーンを防止する

エージェントは、タスクに必要なツールのみを呼び出す必要があります。オーケストレーションコードで次のことを防ぐようにしてください。

動的ツール: エージェントは、新しいツールを動的に登録したり、既存のツールの権限を変更したりすることはできません。
許可リストの適用: エージェントがアクセスできる関数またはデータベーステーブルの許可リストを、初期システムプロンプトとバックエンドコードで宣言します。Gemini CLI の例については、ツールへのアクセスを制限するをご覧ください。

マルチテナントデータベースでのデータアクセスを制限する

execute_sql などの一般的なツールを使用すると、呼び出し元は、IAM とデータベースの権限でアクセスが許可されている任意のデータを読み取ることができるデータベースクエリを実行できます。信頼できる人間参加型ではないマルチテナントアプリケーションのデータにアクセスするエージェントを作成する場合は、データアクセスをさらに制限する必要がある場合があります。

エージェントがアクセスできるデータのサブセットのみを読み取れるようにするには、 MCP Toolbox for Databasesなどのフレームワークを使用してカスタムツールを作成することをおすすめします。詳細については、事前構築済みツールとカスタムツールをご覧ください。

たとえば、データベースの Orders テーブルにすべてのエンドユーザーの注文が保存されているとします。ユーザーとやり取りして注文を検索できるチャットエージェントを開発しています。チャットエージェントには Orders テーブル全体を読み取る権限がありますが、あるエンドユーザーが別のユーザーの注文に関する情報をリクエストすることはできません。

安全でないシナリオでは、エージェントに execute_sql ツールのみを装備し、データ漏洩のリスクが生じます。悪意のあるユーザーは、エージェントをだまして他のユーザーの注文を読み取って返すことができます。通常、エージェントにアクセスルールを適用するように指示するだけでは、データを保護するのに十分ではありません。

安全なシナリオでは、エージェントに lookup_active_order などのより具体的なカスタムツールを付与します。このツールでは、クエリフィルタのユーザーの ID はエージェントの制御外に設定されます。

セキュリティと安全に関する構成

Cloud SQL for SQL Server には、プラットフォームレベルで安全性の境界を適用する Model Armor が用意されています。これらの設定を有効にして構成する必要があります。

Model Armor を有効にする

gcloud CLI を使用して、モデルデプロイで Model Armor を有効にします。これにより、インジェクションやジェイルブレイクなどの既知の攻撃ベクトルに対する組み込みの保護が有効になります。

次の例では、Vertex AI エンドポイントで Model Armor を有効にします。

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

詳細と例については、で MCP の Model Armor 保護を構成する Google Cloudをご覧ください。

センシティブデータオペレーションの最小安全しきい値を適用する

Model Armor を使用すると、センシティブデータオペレーション（個人情報（PII）の検出と匿名化など）の最小安全しきい値を適用できます。Sensitive Data Protection DeidentifyTemplate を使用して、モデルが侵害された場合でも、機密情報がユーザーに返される前に秘匿化またはマスキングします。

構成の概念的な例を次に示します。

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

次の例では、model_armor_config.json が DLP テンプレートを参照している可能性があります。

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

監査とオブザーバビリティ

インシデント後の分析と侵害されたエージェントの検出には、エージェントのアクションを可視化することが重要です。

データ復旧戦略を実装する

IAM やデータベースネイティブのロールなどの階層化された制御は、破壊的なアクションを防ぐように設計されていますが、これらの防御が失敗した場合に備えて復旧計画を立てる必要があります。書き込み権限を持つ侵害されたエージェントまたは単純なエージェント（「エージェント専用」のリスク）は、DROP TABLE などの破壊的なコマンドを実行したり、データを破損させたりする可能性があります。

このシナリオに対する主な防御策は、堅牢な復旧戦略です。

ほぼすべてのデータクラウドプロダクトには、従来のバックアップ、ポイントインタイムリカバリ（PITR）、データスナップショットのいずれかを使用してデータを復旧する機能が用意されています。これらの機能を有効にして構成する責任はお客様にあります。

プロダクト	バックアップと復旧のメカニズム
Cloud SQL	オンデマンドバックアップと自動バックアップの両方をサポートしているため、インスタンスを以前の状態に復元できます。ポイントインタイムリカバリ（PITR）もサポートしています。
AlloyDB	デフォルトで継続的なバックアップと復元を提供します。これにより、マイクロ秒単位の PITR が可能になり、保持期間内の任意の時点にクラスタを復元できます。
BigQuery	データ復旧は「タイムトラベル」を使用して行われます。これにより、過去 7 日間の任意の時点からデータにアクセスして復元できます。長期保存の場合は、テーブルスナップショットを作成できます。
Spanner	オンデマンドバックアップと PITR の両方をサポートしています。
Firestore	データベースを以前の状態に復元できる自動バックアップをサポートしています。また、偶発的な削除や書き込みから保護する PITR も提供しています。これらの機能はデフォルトで無効になっています。
Bigtable	オンデマンドバックアップと自動バックアップをサポートしています。これらのバックアップはフルマネージドで、新しいテーブルに復元できます。

Cloud Audit Logs を有効にする

MCP と、BigQuery、Cloud SQL、AlloyDB、Firestore、Spanner などの関連するすべての Google Cloud サービスで、データアクセス監査ログが有効になっていることを確認します。デフォルトでは、管理アクティビティ監査ログのみが有効になっています。データアクセス監査ログには、エージェントが実行したすべての読み取りオペレーションと書き込みオペレーションが記録されます。詳細については、MCP のデータアクセス監査ログをご覧ください。

機密情報に関する操作を監査する

Cloud Logging でアラートを構成して、異常なアクションやリスクの高いアクションを検出します。たとえば、ログエクスプローラクエリは、Firestore で データ書き込み オペレーションを実行するサービスアカウントを特定します。これは、引き出し攻撃や破壊的な攻撃の一般的なターゲットです。

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

エージェント固有のロギングを使用する

Cloud Audit Logs に加えて、アプリケーションコードでエージェントの決定ごとに次のデータが記録されるようにします。

ツールの実行: 呼び出された MCP ツール。
未加工のコマンド: LLM によって生成された正確なコマンド（SQL クエリやドキュメントパスなど）。
最終アクション: アクションが実行されるか（エージェント専用モデル）、承認されるか（Human-in-the-Middle）。詳細については、エージェントの使用状況を把握するをご覧ください。
ユーザー ID とセッション ID: リクエストを開始したエンドユーザーの識別子。