Erweiterbare Richtlinien im Agent Gateway

Wenn Agenten von ersten Prototypen zu Unternehmensbereitstellungen skaliert werden, steigt der Bedarf an der Integration interner Kontrollen, proprietärer Datenpipelines und Sicherheitsrichtlinien für Unternehmen rasant. Manchmal können komplexe Autorisierungsentscheidungen nicht einfach nur mit Standard-IAM-Richtlinien ausgedrückt werden.

Um diese Anforderungen zu erfüllen, wird mit Agent Gateway ein neues Richtlinien-Framework eingeführt, mit dem Sie die Durchsetzung mit Google-Diensten, benutzerdefinierten Autorisierungs-Engines oder Sicherheitsplattformen von Drittanbietern unterstützen können. Dabei werden dieselben Richtlinien universell auf Ihre Gateways angewendet. In diesem Dokument werden wichtige Anwendungsfälle für agentische Risiken beschrieben und es wird erläutert, wie Sie erweiterbare Richtlinien konfigurieren.

Anwendungsfälle für die Erweiterbarkeit von Richtlinien für agentische Risiken

Standardmäßige deterministische Kontrollen reichen für probabilistische KI-Arbeitslasten oft nicht aus. Erweiterbare Dienstpipelines helfen Unternehmen, erweiterte Logik einzufügen, die auf die spezifischen Risiken von KI-Agents zugeschnitten ist:

• Inhaltsbereinigung und Sicherheitsvorkehrungen: Schutz vor Prompt Injections, Jailbreaks, toxischen Ausgaben und dem Verlust vertraulicher Informationen (z. B. mit Model Armor).
• Schutz vor Datenverlust (Data Loss Prevention, DLP): Echtzeit-Monitoring von Nutzlasten und Streaming-Blöcken, um die Weitergabe von proprietärem Code oder personenidentifizierbaren Informationen an externe Systeme zu verhindern.
• Zero-Trust-Identitätsverwaltung: Validierung von Anmeldedaten und Erzwingung von Zugriffssteuerungen, bevor ein Agent auf sensible Back-Ends oder externe Tools zugreifen darf (z. B. mit IAP).
• Maßgeschneiderte Compliance für Unternehmen: Erzwingen benutzerdefinierter Regeln für die Datenentfernung, Tokenübersetzung oder Compliance-Mechanismen, die für interne Architekturen spezifisch sind.

Framework für die Erweiterbarkeit von Richtlinien im Agent Gateway

Mit dem Agent Gateway können Sie Erweiterungsbindungen anhängen, um Autorisierungsentscheidungen an spezialisierte Policy Engines wie Identitätsanbieter, Filter für Inhaltssicherheit oder benutzerdefinierte Sicherheitsplattformen von Drittanbietern zu delegieren.

Das Framework für die Richtlinienerweiterbarkeit basiert auf einer Trennung zwischen Rollen und Ressourcen:

• Nutzer: Agent Gateway-Betreiber, die ihren Gateways mit minimalem Konfigurationsaufwand Sicherheits- und Governance-Erweiterungen hinzufügen möchten.

• Produzenten: Interne Plattformteams, Google-Dienste von Erstanbietern (z. B. IAP und Model Armor) und ISV-Partner von Drittanbietern, die Diensterweiterungen für andere erstellen und veröffentlichen.

• ExtensionBinding: Eine vom Nutzer erstellte Ressource, die eine ProducerExtension an ein Ziel-KI-Agenten-Gateway bindet, zusammen mit Übereinstimmungsbedingungen, die bestimmen, wann die Erweiterung aufgerufen wird. Dies ist die einzige Ressource, die ein Nutzer erstellen muss, um eine Erweiterung zu verwenden.

• ProducerExtension: Eine vom Ersteller erstellte Ressource, die eine mit ext_proc kompatible Autorisierungs-Engine in einer einzigen verwalteten Einheit verpackt. Sie kapselt alle zugrunde liegenden Ausführungsparameter und Verbindungseinstellungen, sodass Nutzer keine Low-Level-Mechanismen der Datenebene konfigurieren müssen.

Integrierte Google-Erweiterungen

Eigene Google-Dienste wie IAP und Model Armor bieten vordefinierte Erweiterungsfunktionen mit einem optimierten Betriebsmodell.

• Nutzer: Anwendungsentwickler und SecOps agieren als Nutzer. Wenn Sie die Zero-Trust-Authentifizierung oder den Schutz vor Prompt-Injection aktivieren möchten, erstellen Sie direkt in Ihrem Nutzerprojekt eine ExtensionBinding-Ressource, die auf die vordefinierten Dienstendpunkt-URIs von Google verweist.
• Produzent:Google fungiert als Produzent. Google erstellt, hostet und verwaltet die zugrunde liegende Dienstinfrastruktur und die Erweiterungsendpunkte global (z. B. iap.googleapis.com oder modelarmor.us.rep.googleapis.com). Sie müssen keine ProducerExtension-Ressource erstellen oder verwalten.

Unternehmens- und Partnererweiterungen (2P/3P)

Für Custom Governance-Logik ermöglicht die Richtlinienerweiterbarkeit ein flexibles zweiseitiges Integrationsmodell für Unternehmensteams und Sicherheitspartner.

• Producer: Interne Platform Engineering-Teams (2P) oder externe ISV-Sicherheitsanbieter (3P) fungieren als Producer. Der Ersteller erstellt einen gRPC-Dienst, der mit dem ext_proc-Protokoll von Envoy kompatibel ist, hostet ihn in einem dedizierten Erstellerprojekt (z. B. einem Cloud Run-Dienst hinter einem Application Load Balancer), stellt ihn über einen Private Service Connect-Dienstanhang (PSC) bereit und veröffentlicht eine ProducerExtension-Ressource.

• Nutzer: Anwendungsentwickler und Sicherheitsadministratoren in Nutzerprojekten fungieren als Nutzer. Sobald der Ersteller den Zugriff über PSC gewährt hat, erstellen Nutzer in ihrem Projekt eine ExtensionBinding, die auf den spezifischen ProducerExtension-Ressourcen-URI verweist, um benutzerdefinierte Kontrollen (z. B. semantische Governance-Richtlinien oder Firewallregeln von Drittanbietern) für ihre Arbeitslasten zu erzwingen.

Bereitstellungsmuster

Erweiterungsbindungen unterstützen flexible Bereitstellungsmuster, um eine einheitliche Governance für alle Trafficpfade zu erzwingen. So wird sichergestellt, dass Ihre Governance-Richtlinien unabhängig davon, wo Ihre Agenten bereitgestellt werden, identisch funktionieren. Die ExtensionBinding API gilt einheitlich für alle Agent Gateway-Bereitstellungsmodelle.

End-to-End-Pfade zum Abfangen von Traffic

Sie können Erweiterungsbindungen anwenden, um Traffic über die folgenden Kommunikationspfade in Ihrem agentischen Ökosystem abzufangen:

• Nutzer → Agent (Ingress): Fängt eingehende Anfragen von Endnutzern oder Clientanwendungen ab, die an das Agent Gateway gerichtet sind, um die Nutzerauthentifizierung, Identitätsverwaltung oder Bereinigung von Prompt-Injections zu erzwingen.
• Agent → Tool / MCP (ausgehend): Abfangen ausgehender Aufrufe von Agenten an MCP-Server (Model Context Protocol) oder externe APIs, um Berechtigungen zu prüfen und Tool-Eingaben zu bereinigen.
• Agent → LLM-Modell (ausgehend): Prompts werden gescannt, bevor sie Foundation Models erreichen, und Modellantworten werden gefiltert, um Datenverlust oder toxische Ausgaben zu verhindern.

• Agent → Agent (A2A-Ausgang): Steuert die Kommunikation zwischen Agenten und erzwingt Richtliniengrenzen, wenn autonome Agenten projektübergreifend zusammenarbeiten.

Client zu Agent

Agent zu beliebigem Ziel

Nutzer: Erweiterungen an KI-Agenten-Gateways binden

Nutzer (z. B. Anwendungsentwickler oder Sicherheitsexperten) hängen Governance- und Sicherheitslogik an ihre Agent Gateways an, indem sie eine ExtensionBinding erstellen. Diese Ressource bindet die Zielarbeitslast an eine Erweiterung und deklariert Übereinstimmungsbedingungen, um genau festzulegen, wann die Erweiterung aufgerufen werden soll (z. B. Abfangen von Traffic, der an bestimmte externe Tools oder MCP-Server gebunden ist). Sie können Übereinstimmungsbedingungen direkt inline (wie in den Beispielen in diesem Abschnitt gezeigt) oder in einer separaten YAML-Datei angeben.

Je nach Anbieter der Erweiterung gibt es zwei Möglichkeiten für die Nutzung:

Nutzerkonfiguration für eigene Daten

Bei Google-Diensten wie IAP (IAP) oder Model Armor verwaltet Google die Backend-Infrastruktur und die Registrierung global. Als Nutzer müssen Sie nicht auf einen bestimmten ProducerExtension-Ressourcen-URI abzielen. Sie können diese Dienste direkt an Ihre Arbeitslasten binden, indem Sie ihre vordefinierten Endpunktstrings (z.B. iap.googleapis.com oder modelarmor.us.rep.googleapis.com) als Ziel in Ihrer ExtensionBinding übergeben.

IAP-Erweiterung an ein KI-Agenten-Gateway binden

Das folgende Beispiel zeigt eine ExtensionBinding-Ressource, die einen Google-Dienst eines Erstanbieters (IAP) an ein Agent Gateway in einem Nutzerprojekt bindet. Basierend auf dem angegebenen matchConditions-Feld wird diese Erweiterung aufgerufen, wenn Traffic an einen MCP-Server gesendet wird.

1. Erstellen Sie eine YAML-Datei mit der folgenden Konfiguration:

   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"
   

   Ersetzen Sie Folgendes:

   • EXTENSION_BINDING_NAME: der Name der Ressource für die Erweiterungsbindung.
   • PROJECT_ID: Projekt-ID in Cloud de Confiance by S3NS .
   • LOCATION: der Standort des Gateways und der Erweiterungsbindung.
   • AGENT_GATEWAY_NAME: der Name des Ziel-Agent-Gateways.

2. Importieren Sie die Konfiguration der Erweiterungsbindung:

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

   Ersetzen Sie EXTENSION_BINDING_FILE_PATH durch den Pfad zur YAML-Konfigurationsdatei.

Model Armor-Erweiterung an ein Agent Gateway binden

Um Ihre KI-Agenten vor Prompt Injections, toxischen Inhalten und dem Verlust sensibler Daten zu schützen, können Sie Model Armor direkt an Ihre Arbeitslast binden. Basierend auf dem angegebenen matchConditions-Feld wird diese Erweiterung aufgerufen, wenn Traffic an einen MCP-Server gesendet wird.

1. Erstellen Sie eine YAML-Datei mit der folgenden Konfiguration:

   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"
     }]'
   

   Ersetzen Sie Folgendes:

   • EXTENSION_BINDING_NAME: der Name der Ressource für die Erweiterungsbindung.
   • PROJECT_ID: Projekt-ID in Cloud de Confiance .
   • LOCATION: der Standort der Ressourcen.
   • AGENT_GATEWAY_NAME: der Name des Ziel-Agent-Gateways.
   • TEMPLATE_PROJECT_ID: die Projekt-ID, in der sich Ihre Model Armor-Vorlagen befinden.
   • REQUEST_TEMPLATE_ID: Die ID der Model Armor-Vorlage, die zum Bewerten von Anfragen verwendet wird.
   • RESPONSE_TEMPLATE_ID: die ID der Model Armor-Vorlage, die zum Bewerten von Antworten verwendet wird.

2. Importieren Sie die Konfiguration der Erweiterungsbindung:

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

   Ersetzen Sie EXTENSION_BINDING_FILE_PATH durch den Pfad zur YAML-Konfigurationsdatei.

Nutzerkonfiguration für Erstanbieter/Drittanbieter

Als Nutzer einer Diensterweiterung, die von einem anderen internen Team (2P) oder einem externen Drittanbieter (3P) erstellt wurde, sind Sie dafür verantwortlich, dass Ihrem Nutzerprojekt explizit Zugriff auf den Dienst gewährt wurde. Der Zugriff wird vom Ersteller über die Konfiguration des Private Service Connect-Dienstanhangs gesteuert. Sobald Sie Zugriff erhalten haben, binden Sie die Arbeitslast, indem Sie in Ihrer ExtensionBinding auf den spezifischen ProducerExtension-Ressourcen-URI verweisen, der vom Ersteller bereitgestellt wurde.

Benutzerdefinierte Autorisierungs-Engines binden

Das folgende Beispiel zeigt eine ExtensionBinding-Ressource, die eine benutzerdefinierte Erweiterung aus einem 2P/Drittanbieter-Produzentenprojekt an ein Agent Gateway in einem Nutzerprojekt bindet. Basierend auf dem angegebenen matchConditions-Feld wird diese Erweiterung aufgerufen, wenn Traffic an einen Agent gesendet wird.

1. Erstellen Sie eine YAML-Datei mit der folgenden Konfiguration:

   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"
   

   Ersetzen Sie Folgendes:

   • EXTENSION_BINDING_NAME: der Name der Ressource für die Erweiterungsbindung.
   • CONSUMER_PROJECT_ID: die Projekt-ID des Nutzerprojekts, in dem das Agent Gateway gehostet wird.
   • LOCATION: der Standort der Ressourcen.
   • AGENT_GATEWAY_NAME: der Name des Ziel-Agent-Gateways.
   • PRODUCER_PROJECT_ID: die Projekt-ID des Erstellerprojekts, das die ProducerExtension hostet.
   • PRODUCER_EXTENSION_NAME: der Name der ProducerExtension-Ressource.

2. Importieren Sie die Konfiguration der Erweiterungsbindung:

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

   Ersetzen Sie EXTENSION_BINDING_FILE_PATH durch den Pfad zur YAML-Konfigurationsdatei.

Anhangspunkte für Erweiterungsbindungen

Erweiterungsbindungen können je nach Ihren Governance-Anforderungen auf verschiedenen Ebenen Ihrer Ressourcenhierarchie konfiguriert werden:

• Agent Gateway-Ebene: Sie hängen Richtlinien direkt an eine Agent Gateway-Ressource an, um den gesamten Traffic zu steuern, der das Gateway passiert.
• Projektebene: Erstellen Sie ExtensionBindings, die global für alle Ressourcen eines bestimmten Typs innerhalb eines Projekts gelten. Das vereinfacht die Verwaltung für Unternehmensadministratoren, die die projektweite Compliance erzwingen.

Model Armor-Erweiterung an alle Agent Gateways in einem Projekt binden

1. Erstellen Sie eine YAML-Datei mit der folgenden Konfiguration:

   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"
     }]'
   

   Ersetzen Sie Folgendes:

   • EXTENSION_BINDING_NAME: der Name der Ressource für die Erweiterungsbindung.
   • PROJECT_NUMBER: die Projektnummer IhresCloud de Confiance -Projekts.
   • TEMPLATE_PROJECT_ID: die Projekt-ID, in der sich Ihre Model Armor-Vorlagen befinden.
   • LOCATION: der Standort der Ressourcen.
   • REQUEST_TEMPLATE_ID: die ID der Model Armor-Vorlage, die zum Bewerten von Anfragen verwendet wird.
   • RESPONSE_TEMPLATE_ID: die ID der Model Armor-Vorlage, die zum Bewerten von Antworten verwendet wird.

2. Importieren Sie die Konfiguration der Erweiterungsbindung:

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

   Ersetzen Sie EXTENSION_BINDING_FILE_PATH durch den Pfad zur YAML-Konfigurationsdatei.

Bei Anfragen, die einer bestimmten Arbeitslast entsprechen, werden sowohl die Bindungen auf Projektebene als auch alle Erweiterungsbindungen auf Ressourcenebene ausgeführt. Wenn dieselbe Erweiterung sowohl auf Ressourcen- als auch auf Projektebene konfiguriert ist, wird sie zweimal aufgerufen.

Bedingungen für den Aufruf von Erweiterungen abgleichen

Übereinstimmungsbedingungen bestimmen, wann Ihre Erweiterung aufgerufen wird. Sie können Übereinstimmungsbedingungen direkt inline (wie in den vorherigen Beispielen auf dieser Seite gezeigt) oder in einer YAML-Datei angeben.

In diesem Abschnitt finden Sie Beispielkonfigurationen für YAML-Dateien für gängige Situationen basierend auf Trafficfluss, Zielressourcen-URNs oder Zielhosts:

• Ausgehender Traffic zu MCP-Toolservern (Agent → Tool): Fängt Traffic ab, der von einem Agenten an Remote-MCP-Toolserver (Model Context Protocol) gesendet wird:

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

• Eingehender Traffic (Nutzer → Agent): Abfangen eingehender Anfragen von Endnutzern oder Clientanwendungen, die auf Agenten abzielen, die vom Agent Gateway verwaltet werden (z. B. um die Endnutzerauthentifizierung oder die Bereinigung von Prompt-Injections bei eingehendem Traffic zu erzwingen):

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

• Ausgehender Traffic zu LLM-Modellen (Agent → LLM-Modell): Fängt Anfragen ab, die von Agents an Foundation-LLM-Modelle oder Modellserver gesendet werden, indem der Zielhost abgeglichen wird:

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

Produzenten: Erweiterungen erstellen und veröffentlichen

Als benutzerdefinierter (2P- oder 3P-)Produzent hosten Sie Ihre ext_proc-basierte Implementierung der Diensterweiterung hinter einem Private Service Connect-Anhang. Sobald der Anhang bereit ist, erstellen Sie eine ProducerExtension-Ressource und geben Sie die Anfrageverarbeitungsphase an, in der Ihre Erweiterung ausgeführt wird, die zu verwendende Autorisierung und den URI zum PSC-Anhang für Ihren ext_proc-Dienst:

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"

Ersetzen Sie Folgendes:

• PRODUCER_EXTENSION_NAME: der Name der ProducerExtension-Ressource.
• PRODUCER_PROJECT_ID: die Projekt-ID des Erstellerprojekts.
• REGION: die Region des Private Service Connect-Dienstanhangs.
• PSC_ATTACHMENT_NAME: der Name des Private Service Connect-Dienstanhangs.

Benutzerdefinierte Erweiterungen in Cloud Run hosten

Für Ersteller, die ihren benutzerdefinierten ext_proc-gRPC-Dienst ausführen möchten, ohne dedizierte Cluster oder VMs zu verwalten, ist Cloud Run eine ideale, serverlose Alternative.

Wenn Sie Ihre serverlose Erweiterung als ProducerExtension veröffentlichen möchten, müssen Sie sie über Private Service Connect (PSC) verfügbar machen. Da ProducerExtension-Ressourcen einen PSC-Dienstanhang-URI erfordern und Dienstanhänge auf Weiterleitungsregeln für Load Balancer und nicht direkt auf Cloud Run-Dienste abzielen, platzieren Sie einen Application Load Balancer (mit einem serverlosen NEG-Backend) vor Ihrem Cloud Run-Dienst.

Hier ist der allgemeine Bereitstellungs-Workflow für das Hosten Ihrer Erweiterung in Cloud Run:

1. Erweiterung in Cloud Run bereitstellen: Hosten Sie Ihre benutzerdefinierte ext_proc-gRPC-Erweiterung als containerisierten Dienst in Cloud Run.

2. Serverlose NEG erstellen: Stellen Sie eine serverlose Netzwerk-Endpunktgruppe (NEG) bereit, die auf die in Cloud Run ausgeführte Erweiterung verweist.

3. Load Balancer mit dem serverlosen NEG-Backend einrichten: Richten Sie einen regionalen Application Load Balancer in Ihrem VPC-Netzwerk mit der serverlosen NEG als Backend ein.

4. Dienst mit PSC veröffentlichen: Erstellen Sie einen Private Service Connect-Dienstanhang, der direkt auf die Weiterleitungsregel des Load Balancers verweist. Dadurch wird ein eindeutiger Dienstanhang-URI generiert (z. B. projects/.../regions/.../serviceAttachments/...).

5. Produzentenerweiterung erstellen: Verwenden Sie diesen generierten URI, um Ihre ProducerExtension-Ressource zu instanziieren.

6. Nutzerarbeitslasten binden: Nutzer können jetzt ihre Gateways an Ihre Erweiterung binden, indem sie auf den Ressourcen-URI ProducerExtension verweisen.

Anhang: Kontextbezogene Metadaten für benutzerdefinierte Erweiterungen

Damit Ihre benutzerdefinierten Erweiterungen kontextsensitive Autorisierungs- und Verarbeitungsentscheidungen treffen können,übergeben die Datenebenen von Cloud de Confiance Lebenszyklus- und Ressourcenkontext direkt an ext_proc-Server.

Diese Informationen werden als nicht typisierte Metadaten im Feld metadata_context des ext_proc-gRPC-ProcessingRequest gebündelt. Diese Metadaten befinden sich im Namespace com.google.serviceextensions.invocation_info und verwenden das Standardformat google.protobuf.Struct.

Sie können diese Metadaten für die nachgelagerte Verarbeitung in JSON decodieren oder konvertieren. Hier ist ein Beispiel für ein JSON-Format für eine Anfrage an ein Agent Gateway mit Traffic, der an einen MCP-Server gebunden ist:

{
 "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"
 }
}

Das Schema des JSON-Objekts sieht so aus:

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;
}