Agent Gateway 的可擴充政策

隨著代理從初始原型擴充至企業部署，整合內部控管、專屬資料管道和企業安全政策的需求也迅速增加。有時，複雜的授權決策無法僅使用標準 IAM 政策輕鬆表達。

為滿足這些需求，Agent Gateway 推出新的政策架構，可讓您透過 Google 服務、自訂授權引擎或第三方安全平台強制執行政策，並在所有閘道套用相同政策。本文將概述重要的代理風險用途，並說明如何設定可擴充的政策。

代理風險的政策擴充性用途

標準確定性控制項通常不足以因應機率性 AI 工作負載。可擴充的服務管道可協助組織插入進階邏輯，專門因應獨特的代理風險：

• 內容清理和安全防護機制：防範提示詞注入、越獄、有害輸出內容和機密資訊遺失 (例如使用 Model Armor)。
• 資料遺失防護 (DLP)：即時監控酬載和串流區塊，防止專屬程式碼或 PII 資料外洩至外部系統。
• 零信任身分治理：先驗證憑證並強制執行存取控管，再允許代理存取機密後端或外部工具 (例如使用 IAP)。
• 客製化企業法規遵循：強制執行自訂資料遮蓋規則、權杖翻譯，或內部架構專屬的法規遵循機制。

Agent Gateway 政策擴充性架構

Agent Gateway 可讓您附加擴充功能繫結，將授權決策委派給專門的政策引擎，例如身分識別提供者、內容安全篩選器或自訂第三方安全平台。

政策擴充性架構會區分角色和資源：

• 消費者：Agent Gateway 營運商，希望以最少的設定工作，為閘道新增安全性和管理擴充功能。

• 生產者：內部平台團隊、第一方 Google 服務 (例如 IAP 和 Model Armor)，以及建構和發布服務擴充功能供他人使用的第三方 ISV 合作夥伴。

• ExtensionBinding：由用戶建立的資源，可將 ProducerExtension 繫結至目標 Agent Gateway，並提供比對條件，決定何時叫用擴充功能。這是消費者需要建立的唯一資源，建立後即可開始使用擴充功能。

• ProducerExtension：由生產者建立的資源，可將與 ext_proc 相容的授權引擎封裝成單一代管單位。這項服務會封裝所有基礎執行參數和連線設定，因此使用者不必設定低階資料層機制。

內建第一方 Google 擴充功能

第一方 (1P) Google 服務 (例如 IAP 和 Model Armor) 提供預先封裝的擴充功能，並採用簡化的作業模式。

• 消費者：應用程式開發人員和資安營運人員扮演消費者的角色。如要啟用零信任驗證或提示詞注入防護功能，請直接從用戶專案建立 ExtensionBinding 資源，並指定 Google 預先定義的服務端點 URI。
• 生產者：Google 扮演生產者的角色。Google 會在全球建構、託管及管理基礎 Service Infrastructure 和擴充功能端點 (例如 iap.googleapis.com 或 modelarmor.us.rep.googleapis.com)。您不需要建立或管理 ProducerExtension 資源。

企業和合作夥伴 (2P/3P) 擴充功能

如需 Custom Governance 邏輯，政策擴充性可讓企業團隊和資安合作夥伴，彈性採用雙向整合模式。

• 製作者：內部平台工程團隊 (2P) 或第三方 ISV 安全性供應商 (3P) 扮演製作者的角色。供應商會建構與 Envoy ext_proc 通訊協定相容的 gRPC 服務，並託管於專屬供應商專案 (例如應用程式負載平衡器後方的 Cloud Run 服務)，然後使用 Private Service Connect (PSC) 服務連結公開該服務，並發布 ProducerExtension 資源。

• 消費者：消費者專案中的應用程式開發人員和安全性管理員，都屬於消費者。供應商透過 PSC 授予存取權後，用戶會在專案中建立 ExtensionBinding，並參照特定 ProducerExtension 資源 URI，對工作負載強制執行自訂控管機制 (例如 Semantic Governance Policies 或第三方防火牆規則)。

部署模式

擴充功能繫結支援彈性的部署模式，可在所有流量路徑強制執行一致的控管機制，確保無論代理部署在何處，控管政策都能以相同方式運作。ExtensionBinding API 統一適用於所有 Agent Gateway 部署模型。

端對端流量攔截路徑

您可以套用擴充功能繫結，攔截代理生態系統中下列通訊路徑的流量：

• 使用者 → 代理 (輸入)：攔截來自使用者或用戶端應用程式、傳送至 Agent Gateway 的傳入要求，強制執行使用者驗證、身分治理或提示詞注入清理。
• 代理 → 工具 / MCP (輸出)：攔截代理傳送至 Model Context Protocol (MCP) 伺服器或外部 API 的外撥通話，驗證權限並清理工具輸入內容。
• 代理 → LLM 模型 (輸出)：在提示詞傳送至基礎模型前進行掃描，並篩選模型回覆，防止資料遺失或有害輸出。

• 代理 → 代理 (A2A 輸出)：控管代理之間的通訊，並在自動代理跨專案協作時，強制執行政策界限。

用戶端至代理

代理至任意目的地

消費者：將擴充功能繫結至 Agent Gateway

消費者 (例如應用程式開發人員或資安營運人員) 建立 ExtensionBinding，將管理和安全邏輯附加至 Agent Gateway。這項資源會將目標工作負載繫結至擴充功能，並宣告比對條件，明確定義叫用擴充功能的時機 (例如攔截傳送至特定外部工具或 MCP 伺服器的流量)。您可以直接在內嵌中指定比對條件 (如本節範例所示)，或在獨立的 YAML 檔案中指定。

視擴充功能供應商而定，使用方式分為以下兩種：

第一方消費者設定

如果是 IAP 或 Model Armor 等 Google 服務，Google 會在全球管理後端基礎架構和註冊作業。身為消費者，您「不需要」指定特定 ProducerExtension 資源 URI。您可以將這些服務的預先定義端點字串 (例如 iap.googleapis.com 或 modelarmor.us.rep.googleapis.com) 做為 ExtensionBinding 中的目標傳遞，直接將這些服務繫結至工作負載。

將 IAP 擴充功能繫結至 Agent Gateway

以下範例說明如何使用 ExtensionBinding 資源，將第一方 Google 服務 (IAP) 繫結至用戶專案中的 Agent Gateway。根據指定的 matchConditions 欄位，當流量傳送至 MCP 伺服器時，系統會叫用這項擴充功能。

1. 使用下列設定建立 YAML 檔案：

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "iap.googleapis.com"
   

   更改下列內容：

   • EXTENSION_BINDING_NAME：擴充功能繫結資源的名稱。
   • PROJECT_ID：您的 Cloud de Confiance by S3NS 專案 ID。
   • LOCATION：閘道和擴充功能繫結的位置。
   • AGENT_GATEWAY_NAME：目標 Agent Gateway 的名稱。

2. 匯入擴充功能繫結設定：

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   將 EXTENSION_BINDING_FILE_PATH 替換為 YAML 設定檔的路徑。

將 Model Armor 擴充功能繫結至 Agent Gateway

為保護代理，防範提示詞注入、有害內容和敏感資料外洩，您可以將 Model Armor 直接繫結至工作負載。根據指定的 matchConditions 欄位，當流量傳送至 MCP 伺服器時，系統會叫用這項擴充功能。

1. 使用下列設定建立 YAML 檔案：

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "modelarmor.us.rep.googleapis.com"
   failOpen: true
   producerMetadata:
     model_armor_settings: '[{
       "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
       "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
     }]'
   

   更改下列內容：

   • EXTENSION_BINDING_NAME：擴充功能繫結資源的名稱。
   • PROJECT_ID：您的 Cloud de Confiance 專案 ID。
   • LOCATION：資源的位置。
   • AGENT_GATEWAY_NAME：目標 Agent Gateway 的名稱。
   • TEMPLATE_PROJECT_ID：Model Armor 範本所在的專案 ID。
   • REQUEST_TEMPLATE_ID：用於評估要求的 Model Armor 範本 ID。
   • RESPONSE_TEMPLATE_ID：用於評估回覆的 Model Armor 範本 ID。

2. 匯入擴充功能繫結設定：

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   將 EXTENSION_BINDING_FILE_PATH 替換為 YAML 設定檔的路徑。

2P/3P 用戶設定

如果您是其他內部團隊 (2P) 或外部第三方供應商 (3P) 建立的服務擴充功能使用者，則有責任確保您的用戶端專案已明確獲得使用服務的權限。存取權由供應商使用其 Private Service Connect 服務連結設定控管。取得存取權後，請在 ExtensionBinding 中參照供應商提供的特定 ProducerExtension 資源 URI，藉此繫結工作負載。

繫結自訂授權引擎

以下範例示範 ExtensionBinding 資源，將 2P/3P 供應商專案的自訂擴充功能，繫結至用戶端專案的 Agent Gateway。根據指定的 matchConditions 欄位，系統會在流量傳送至代理時叫用這項擴充功能。

1. 使用下列設定建立 YAML 檔案：

   name: EXTENSION_BINDING_NAME
   target:
     resources:
     - "projects/CONSUMER_PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:agent"
   producerExtension: "projects/PRODUCER_PROJECT_ID/locations/LOCATION/producerExtensions/PRODUCER_EXTENSION_NAME"
   

   更改下列內容：

   • EXTENSION_BINDING_NAME：擴充功能繫結資源的名稱。
   • CONSUMER_PROJECT_ID：託管 Agent Gateway 的用戶專案 ID。
   • LOCATION：資源的位置。
   • AGENT_GATEWAY_NAME：目標 Agent Gateway 的名稱。
   • PRODUCER_PROJECT_ID：託管 ProducerExtension 的生產者專案 ID。
   • PRODUCER_EXTENSION_NAME：ProducerExtension 資源的名稱。

2. 匯入擴充功能繫結設定：

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   將 EXTENSION_BINDING_FILE_PATH 替換為 YAML 設定檔的路徑。

擴充功能繫結附加點

您可以根據管理需求，在資源階層結構的不同層級設定擴充功能繫結：

• Agent Gateway 層級：直接將政策附加至 Agent Gateway 資源，控管通過閘道的所有流量。
• 專案層級：建立 ExtensionBindings，全域套用至專案中特定類型的所有資源，簡化企業管理員的工作，輕鬆在整個專案強制執行法規遵循。

將 Model Armor 擴充功能繫結至專案中的所有 Agent Gateway

1. 使用下列設定建立 YAML 檔案：

   name: EXTENSION_BINDING_NAME
   target:
     scope:
       parent: "projects/PROJECT_NUMBER"
       resourceTypes: "AGENT_GATEWAY"
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   producerExtension: "modelarmor.us.rep.googleapis.com"
   failOpen: true
   producerMetadata:
     model_armor_settings: '[{
       "request_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID",
       "response_template_id": "projects/TEMPLATE_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID"
     }]'
   

   更改下列內容：

   • EXTENSION_BINDING_NAME：擴充功能繫結資源的名稱。
   • PROJECT_NUMBER：Cloud de Confiance 專案的專案編號。
   • TEMPLATE_PROJECT_ID：Model Armor 範本所在的專案 ID。
   • LOCATION：資源的位置。
   • REQUEST_TEMPLATE_ID：用於評估要求的 Model Armor 範本 ID。
   • RESPONSE_TEMPLATE_ID：用於評估回覆的 Model Armor 範本 ID。

2. 匯入擴充功能繫結設定：

   gcloud beta service-extensions extension-bindings import EXTENSION_BINDING_NAME \
    --location=LOCATION \
    --source=EXTENSION_BINDING_FILE_PATH

   將 EXTENSION_BINDING_FILE_PATH 替換為 YAML 設定檔的路徑。

如果要求符合特定工作負載，系統會執行專案層級和任何資源層級的擴充功能繫結。如果同時在資源層級和專案層級設定相同的擴充功能，系統會叫用兩次。

叫用擴充功能的比對條件

比對條件會決定叫用擴充功能的時機。您可以直接在內嵌中指定比對條件 (如本頁前述範例所示)，也可以在 YAML 檔案中指定。

本節提供常見情況的 YAML 檔案設定範例，依據流量、目標資源 URN 或目的地主機分類：

• 傳出至 MCP 工具伺服器 (代理 → 工具)：攔截從代理傳送至遠端 Model Context Protocol (MCP) 工具伺服器的流量：

  # Invoke extension for all agent traffic to remote MCP servers
  - to:
      destination:
        resources:
        - prefix: "urn:mcp"
  

• 輸入流量 (使用者 → 代理)：攔截來自使用者或用戶端應用程式的傳入要求，這些要求會指定由 Agent Gateway 管理的代理 (例如，強制執行使用者驗證或提示詞注入清理)：

  # Invoke extension on incoming user requests targeting agents
  - to:
      destination:
        resources:
        - prefix: "urn:agent"
  

• 輸出至 LLM 模型 (代理 → LLM 模型)：比對目的地主機，攔截從代理傳送至基礎 LLM 模型或模型伺服器的要求：

  # Invoke extension on traffic sent to a specific model server
  - to:
      destination:
        hosts:
        - exact: "myexamplemodelserver.com"
  

開發人員：建構及發布擴充功能

自訂 (2P 或 3P) 供應商可將 ext_proc 型服務擴充功能實作項目，託管於 Private Service Connect 連結後方。連結準備就緒後，請建立 ProducerExtension 資源，指定擴充功能運作的要求處理階段、要使用的授權單位，以及 ext_proc 服務的 PSC 連結 URI：

gcloud beta service-extensions producer-extensions create PRODUCER_EXTENSION_NAME \
  --phase authz \
  --extension-settings=service=projects/PRODUCER_PROJECT_ID/regions/REGION/serviceAttachments/PSC_ATTACHMENT_NAME,authority="example.provider.net"

更改下列內容：

• PRODUCER_EXTENSION_NAME：ProducerExtension 資源的名稱。
• PRODUCER_PROJECT_ID：供應商專案的專案 ID。
• REGION：Private Service Connect 服務連結的區域。
• PSC_ATTACHMENT_NAME：Private Service Connect 服務連結的名稱。

在 Cloud Run 託管自訂擴充功能

如果生產者想執行自訂 ext_proc gRPC 服務，但不想管理專屬叢集或 VM，Cloud Run 是理想的無伺服器替代方案。

如要將無伺服器擴充功能發布為 ProducerExtension，請使用 Private Service Connect (PSC) 公開。由於 ProducerExtension 資源需要 PSC 服務連結 URI，且服務連結會指定負載平衡器轉送規則，而非直接指定 Cloud Run 服務，因此請在 Cloud Run 服務前方，放置使用無伺服器 NEG 後端的應用程式負載平衡器。

以下是在 Cloud Run 託管擴充功能的高階部署工作流程：

1. 在 Cloud Run 部署擴充功能：將自訂 ext_proc gRPC 擴充功能，以容器化服務的形式託管於 Cloud Run。

2. 建立無伺服器 NEG：部署無伺服器網路端點群組 (NEG)，指向在 Cloud Run 執行的擴充功能。

3. 設定具有無伺服器 NEG 後端的負載平衡器：在虛擬私有雲網路中設定區域性應用程式負載平衡器，並將無伺服器 NEG 設為後端。

4. 使用 PSC 發布服務：建立 Private Service Connect 服務連結，直接指向負載平衡器轉送規則。這會產生專屬的服務連結 URI (例如 projects/.../regions/.../serviceAttachments/...)。

5. 建立供應商擴充功能：使用產生的 URI 例項化 ProducerExtension 資源。

6. 繫結用戶工作負載：用戶現在可以參照 ProducerExtension 資源 URI，將閘道繫結至您的擴充功能。

附錄：自訂擴充功能的內容中繼資料

為協助自訂擴充功能做出內容感知授權和處理決策， Cloud de Confiance 資料層會將生命週期和資源內容直接傳遞至 ext_proc 伺服器。

這項資訊會以非類型中繼資料的形式，封裝在 ext_proc gRPC ProcessingRequest 的 metadata_context 欄位中。這項中繼資料位於 com.google.serviceextensions.invocation_info 命名空間下，並使用標準 google.protobuf.Struct 格式。

您可以將這項中繼資料解碼或轉換為 JSON，以便進行下游處理。以下是 JSON 格式範例，用於將流量傳送至 MCP 伺服器的 Agent Gateway 要求：

{
 "binding_selector" : {
   "target" : "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME",
   "project_number" : PROJECT_NUMBER,
   "to_resource": "urn:mcp:projects-PROJECT_NUMBER:projects:PROJECT_NUMBER:locations:LOCATION:agentregistry:services:SERVER_ID"
 }
}

JSON 的結構定義如下：

message ServiceExtensionsInvocationInfo {
  message ExtensionBindingSelector {
    // The target (gateway ID, etc) in fully qualified name format.
    // For example:
    // "//networkservices.googleapis.com/projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
    string target = 1;
    // Project number associated with the target.
    uint64 project_number = 2;
    // The destination resource within the Agent Registry that traffic is directed to.
    string to_resource = 3;
  }
  ExtensionBindingSelector binding_selector = 1;
}