透過 Model Context Protocol 確保代理程式互動安全的最佳做法

MySQL   |  PostgreSQL   |  SQL Server

Model Context Protocol (MCP) 標準化生成式 AI 代理連至 SQL Server 適用的 Cloud SQL 的方式。由於自主代理本身存在風險，因此必須採用共同責任模式，結合平台控管機制和安全的應用程式設計，才能降低提示詞注入等安全漏洞的風險。
如要設計及部署使用 Google Cloud Model Context Protocol (MCP) 工具的 AI 應用程式，請遵循本指南的最佳做法。

事前準備

使用 MCP 工具時，應用程式的資安態勢取決於代理的互動模型。如要瞭解使用代理對整合 MCP 伺服器安全風險的影響，請參閱「AI 安全性與安全防護」。

資安責任

身為客戶，您必須負責代理平台安全設定和作業。

遵循最小權限原則

使用範圍最小的服務帳戶執行代理。這是第一道也是最重要的防線。

• 專屬身分：為每個使用 MCP 工具的代理或應用程式，建立獨立的專屬服務帳戶。請勿重複使用現有的服務帳戶，尤其是權限廣泛的服務帳戶。
• 最小範圍：僅授予服務帳戶必要的 Identity and Access Management (IAM) 角色，例如 alloydb.viewer，而非 alloydb.admin。如果代理只需要特定資料集的讀取權限，請使用自訂 IAM 角色，將存取權限制在執行功能所需的絕對最低限度。
• 分散權責：如果代理程式需要資料的讀取權限，以及記錄檔或暫存空間的寫入權限，請使用兩個不同的服務帳戶，一個用於高風險資料存取 (範圍最小)，另一個用於低風險作業工作。

使用資料庫原生的精細控制項

如要達到最強防護效果，請結合 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 角色，進行精細控管。
Oracle Database@Google Cloud	IAM 角色	Oracle Database@Google Cloud 可讓您在專案和資源層級，透過 IAM 角色精細控管權限。

安全代理設計

Agent-Only 模型需要強大的應用程式層級防禦機制，防範試圖覆寫系統提示詞的提示詞注入式攻擊。詳情請參閱「AI 安全與防護」。

將資料和使用者輸入內容視為不受信任

將使用者輸入的內容，或代理從外部來源 (例如網頁搜尋結果或第三方文件) 擷取的資料，視為不受信任。

導入動作選取模式

避免採用開放式的規劃和執行架構，因為系統會將高階工作規格與機械執行作業分離。請改用限制模型自由度的設計模式。

• 動作選取器模式：模型唯一的工作是將使用者要求轉譯為一組預先定義的小型安全函式。動作邏輯是硬式編碼，無法由 LLM 修改。這有助於防止代理受到針對控制流程的注入式攻擊。
• 雙 LLM 模式：使用主要 LLM (動作 LLM) 執行核心工作，並使用次要、高度安全的 LLM (防護機制 LLM) 預先篩選使用者提示詞，找出惡意意圖，並在動作 LLM 輸出內容後篩選，找出未經授權的動作或資料外洩。

防止未經授權的工具鍊結

代理只能呼叫工作所需的工具。請確保自動化調度管理程式碼可防止下列情況：

• 動態工具：代理不得動態註冊新工具，或變更現有工具的權限。
• 強制執行許可清單：在代理的初始系統提示和後端程式碼中，宣告代理可存取的函式或資料庫資料表許可清單。如需 Gemini CLI 範例，請參閱「限制工具存取權」。

限制多租戶資料庫的資料存取權

execute_sql 這類一般工具可讓呼叫端執行資料庫查詢，讀取 IAM 和資料庫權限允許存取的任何資料。建立代理時，如果代理會存取多租戶應用程式中的資料，且沒有可信任的人工介入迴路，您可能需要進一步限制資料存取權。

為確保代理只能讀取有權存取的資料子集，建議您使用 MCP Toolbox for Databases 等架構建立自訂工具。詳情請參閱「預建工具與自訂工具」。

舉例來說，假設資料庫將所有使用者的訂單儲存在 Orders 資料表中。您正在開發一個對話代理，可與使用者互動並查詢訂單。對話代理有權讀取整個 Orders 資料表，但使用者不得要求其他使用者的訂單資訊。

在不安全的情況下，您只為代理提供 execute_sql 工具，這會造成資料外洩風險。惡意使用者可以欺騙代理，讓代理讀取並傳回其他使用者的訂單。指示代理強制執行存取規則，通常不足以保護資料。

在安全的情況下，您會為代理提供更具體的自訂工具 (例如 lookup_active_order)，其中查詢篩選器中的使用者身分是在代理的控制範圍外設定。

安全性與安全防護設定

SQL Server 適用的 Cloud SQL 提供 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 可能會參照資料遺失防護範本：

{
  "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	支援隨選和自動備份。這些備份由系統全代管，可還原至新資料表。
Oracle Database@Google Cloud	支援自動備份和時間點復原。

啟用 Cloud 稽核記錄

請確認 MCP 和所有相關 Google Cloud 服務 (例如 BigQuery、Cloud SQL、AlloyDB、Firestore、Spanner 和 Oracle Database@Google Cloud) 都已啟用資料存取稽核記錄。根據預設，系統只會啟用管理員活動稽核記錄。資料存取稽核記錄會記錄代理執行的每項讀取和寫入作業。詳情請參閱「MCP 的資料存取稽核記錄」。

稽核敏感動作

在 Cloud Logging 中設定警告，偵測異常或高風險動作。Logs Explorer 查詢會找出在 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 稽核記錄，請務必在應用程式程式碼中，記錄代理做出的每項決策，包括下列資料：

• 工具執行：呼叫的 MCP 工具。
• 原始指令：LLM 生成的確切指令，例如 SQL 查詢或文件路徑。
• 最終動作：動作是否執行 (僅限代理模式) 或核准 (人機迴圈)。詳情請參閱「瞭解代理程式使用情形」。
• 使用者和工作階段 ID：發出要求的使用者 ID。