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

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

始める前に

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
Firestore セキュリティ ルール
アプリケーションのロジックまたはリクエストしているユーザーのコンテキストに基づいて、ドキュメント レベルまたはフィールド レベルのアクセスを制限します。

Bigtable
IAM ロール
Bigtable では、プロジェクト、インスタンス、テーブルの各レベルで IAM ロールを使用してきめ細かい制御が可能です。

安全なエージェントの設計

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

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

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

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

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

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

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

エージェントは、タスクに必要なツールのみを呼び出す必要があります。オーケストレーション コードで次の処理が防止されていることを確認します。

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

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

Cloud SQL for PostgreSQL は、プラットフォーム レベルで安全性の境界を適用する 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

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

機密データのオペレーションに最小限の安全しきい値を適用する

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 などの破壊的なコマンドを実行したり、データを破損させたりする可能性があります（「エージェントのみ」のリスク）。

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

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

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

Cloud Audit Logs を有効にする

MCP と、BigQuery、Cloud SQL、AlloyDB、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: リクエストを開始したエンドユーザーの識別子。