Políticas extensibles en Agent Gateway

A medida que los agentes escalan desde los prototipos iniciales hasta las implementaciones empresariales, la necesidad de integrar controles internos, canalizaciones de datos de propiedad exclusiva y políticas de seguridad empresarial crece con rapidez. A veces, las decisiones de autorización complejas no se pueden expresar con facilidad solo con las políticas de IAM estándar.

Para abordar estos requisitos, Agent Gateway presenta un nuevo framework de políticas que te permite respaldar la aplicación de medidas con los servicios de Google, los motores de autorización personalizados o las plataformas de seguridad de terceros, aplicando las mismas políticas de forma universal en todas tus puertas de enlace. En este documento, se describen los casos de uso clave de riesgo de agentes y se explica cómo configurar políticas extensibles.

Casos de uso de extensibilidad de políticas para riesgos de agentes

Los controles determinísticos estándar suelen ser insuficientes para las cargas de trabajo de IA probabilísticas. Las canalizaciones de servicios extensibles ayudan a las organizaciones a insertar lógica avanzada adaptada a los riesgos únicos de los agentes:

• Limpieza de contenido y barreras de seguridad: Protección contra inyecciones de instrucciones, jailbreaks, resultados tóxicos y pérdida de información confidencial (por ejemplo, con Model Armor).
• Prevención de pérdida de datos (DLP): Supervisión en tiempo real de las cargas útiles y los fragmentos de transmisión para evitar la filtración de datos de código de propiedad o IIP a sistemas externos.
• Administración de identidades de confianza cero: Valida las credenciales y aplica los controles de acceso antes de que un agente pueda acceder a backends sensibles o herramientas externas (por ejemplo, con IAP).
• Cumplimiento empresarial personalizado: Aplica reglas de ocultación de datos personalizadas, traducción de tokens o mecanismos de cumplimiento específicos para las arquitecturas internas.

Framework para la extensibilidad de políticas en Agent Gateway

Agent Gateway te permite adjuntar vinculaciones de extensiones para delegar las decisiones de autorización a Policy Engines especializados, como proveedores de identidad, filtros de seguridad de contenido o plataformas de seguridad de terceros personalizadas.

El framework de extensibilidad de políticas opera en una separación entre roles y recursos:

• Consumidores: Operadores de Agent Gateway que desean agregar extensiones de seguridad y administración a sus puertas de enlace con un esfuerzo de configuración mínimo.

• Productores: Son los equipos de plataformas internas, los servicios de Google propios (como IAP y Model Armor) y los socios ISV externos que compilan y publican extensiones de servicio para que otros las consuman.

• ExtensionBinding: Es un recurso creado por el consumidor que vincula un ProducerExtension a una Agent Gateway de destino, junto con condiciones de coincidencia que determinan cuándo se invoca la extensión. Este es el único recurso que un consumidor necesita crear para comenzar a usar una extensión.

• ProducerExtension: Es un recurso creado por el productor que empaqueta un motor de autorización compatible con ext_proc en una sola unidad administrada. Encapsula todos los parámetros de ejecución y la configuración de conectividad subyacentes para que los consumidores no tengan que configurar la mecánica del plano de datos de bajo nivel.

Extensiones de Google propias integradas

Los servicios de Google propios (1P), como IAP y Model Armor, ofrecen capacidades de extensión empaquetadas con un modelo operativo optimizado.

• Consumidor: Los desarrolladores de aplicaciones y los operadores de seguridad actúan como consumidores. Para habilitar la autenticación de confianza cero o la protección contra la inyección de instrucciones, crea un recurso ExtensionBinding que se oriente a los URIs de extremos de servicio predefinidos de Google directamente desde tu proyecto de consumidor.
• Productor: Google actúa como productor. Google compila, aloja y administra la infraestructura de servicios subyacente y los extremos de extensión de forma global (como iap.googleapis.com o modelarmor.us.rep.googleapis.com). No necesitas crear ni administrar un recurso ProducerExtension.

Extensiones empresariales y de socios (2P/3P)

Para la lógica de Custom Governance, la extensibilidad de las políticas permite un modelo de integración flexible de dos lados entre los equipos empresariales y los socios de seguridad.

• Productor: Los equipos internos de ingeniería de plataformas (2P) o los proveedores de seguridad de ISV externos (3P) actúan como productores. El productor compila un servicio de gRPC compatible con el protocolo ext_proc de Envoy, lo aloja en un proyecto de productor dedicado (como un servicio de Cloud Run detrás de un balanceador de cargas de aplicaciones), lo expone con un adjunto de servicio de Private Service Connect (PSC) y publica un recurso ProducerExtension.

• Consumidor: Los desarrolladores de aplicaciones y los administradores de seguridad de los proyectos de consumidor actúan como consumidores. Una vez que el productor otorga acceso con PSC, los consumidores crean un ExtensionBinding en su proyecto que hace referencia al URI del recurso ProducerExtension específico para aplicar controles personalizados (como políticas de gobernanza semánticas o reglas de firewall de terceros) en sus cargas de trabajo.

Patrones de implementación

Las vinculaciones de extensiones admiten patrones de implementación flexibles para aplicar una administración coherente en todas las rutas de tráfico y garantizar que tus políticas de administración actúen de forma idéntica, independientemente de dónde se implementen tus agentes. La API de ExtensionBinding se aplica de manera uniforme en todos los modelos de implementación de Agent Gateway.

Rutas de intercepción de tráfico de extremo a extremo

Puedes aplicar vinculaciones de extensiones para interceptar el tráfico en las siguientes rutas de comunicación dentro de tu ecosistema de agentes:

• Usuario → Agente (entrada): Intercepta las solicitudes entrantes de los usuarios finales o las aplicaciones cliente que se dirigen a Agent Gateway para aplicar la autenticación de usuarios, la administración de identidades o la limpieza de inyecciones de instrucciones.
• Agente → Herramienta / MCP (salida): Intercepta las llamadas salientes de los agentes a los servidores del Protocolo de contexto del modelo (MCP) o a las APIs externas para validar los permisos y limpiar las entradas de las herramientas.
• Agente → Modelo de LLM (salida): Analiza las instrucciones antes de que lleguen a los modelos de base y filtra las respuestas del modelo para evitar la pérdida de datos o los resultados tóxicos.

• Agente → Agente (salida de A2A): Controla la comunicación entre agentes y aplica límites de políticas cuando los agentes autónomos colaboran en proyectos.

De cliente a agente

Del agente a cualquier lugar

Consumidores: Vincula extensiones a Agent Gateways

Los consumidores (como los desarrolladores de aplicaciones o los operadores de seguridad) adjuntan la lógica de administración y seguridad a sus Agent Gateways creando un ExtensionBinding. Este recurso vincula la carga de trabajo de destino a una extensión y declara condiciones de coincidencia para definir exactamente cuándo se debe invocar la extensión (por ejemplo, interceptar el tráfico vinculado a herramientas externas o servidores de MCP específicos). Puedes especificar las condiciones de coincidencia directamente de forma intercalada (como se muestra en los ejemplos de esta sección) o en un archivo YAML independiente.

Según el proveedor de la extensión, el consumo sigue una de estas dos rutas:

Configuración del consumidor de 1P

Para los servicios de Google, como IAP o Model Armor, Google administra la infraestructura de backend y el registro de forma global. Como consumidor, no necesitas orientar tus solicitudes a un URI de recurso ProducerExtension específico. Puedes vincular directamente estos servicios a tus cargas de trabajo pasando sus cadenas de extremos predefinidas (p.ej., iap.googleapis.com o modelarmor.us.rep.googleapis.com) como el destino en tu ExtensionBinding.

Vincula una extensión de IAP a un Agent Gateway

En el siguiente ejemplo, se muestra un recurso ExtensionBinding que vincula un servicio de Google propio (IAP) a una Agent Gateway en un proyecto de consumidor. Según el campo matchConditions especificado, esta extensión se invoca cuando se envía tráfico a un servidor de MCP.

1. Crea un archivo YAML con la siguiente configuración:

   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"
   

   Reemplaza lo siguiente:

   • EXTENSION_BINDING_NAME: Es el nombre del recurso de vinculación de la extensión.
   • PROJECT_ID: Es el ID del proyecto de Cloud de Confiance by S3NS .
   • LOCATION: Es la ubicación de la puerta de enlace y la vinculación de la extensión.
   • AGENT_GATEWAY_NAME: Es el nombre del Agent Gateway de destino.

2. Importa la configuración de vinculación de la extensión:

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

   Reemplaza EXTENSION_BINDING_FILE_PATH por la ruta de acceso al archivo de configuración YAML.

Vincula una extensión de Model Armor a un Agent Gateway

Para proteger tus agentes de la inyección de instrucciones, el contenido tóxico y la filtración de datos sensibles, puedes vincular Model Armor directamente a tu carga de trabajo. Según el campo matchConditions especificado, esta extensión se invoca cuando se envía tráfico a un servidor de MCP.

1. Crea un archivo YAML con la siguiente configuración:

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

   Reemplaza lo siguiente:

   • EXTENSION_BINDING_NAME: Es el nombre del recurso de vinculación de la extensión.
   • PROJECT_ID: Es el ID del proyecto de Cloud de Confiance .
   • LOCATION: Es la ubicación de los recursos.
   • AGENT_GATEWAY_NAME: Es el nombre del Agent Gateway de destino.
   • TEMPLATE_PROJECT_ID: Es el ID del proyecto en el que se encuentran tus plantillas de Model Armor.
   • REQUEST_TEMPLATE_ID: Es el ID de la plantilla de Model Armor que se usa para evaluar las solicitudes.
   • RESPONSE_TEMPLATE_ID: Es el ID de la plantilla de Model Armor que se usa para evaluar las respuestas.

2. Importa la configuración de vinculación de la extensión:

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

   Reemplaza EXTENSION_BINDING_FILE_PATH por la ruta de acceso al archivo de configuración YAML.

Configuración del consumidor de 2P/3P

Como consumidor de una extensión de servicio creada por otro equipo interno (2P) o un proveedor externo (3P), tu responsabilidad es asegurarte de que a tu proyecto de consumidor se le haya otorgado acceso de forma explícita para usar el servicio. El productor controla el acceso con su configuración de adjunto de servicio de Private Service Connect. Una vez que se te otorgue acceso, vincula la carga de trabajo haciendo referencia al URI del recurso ProducerExtension específico que proporciona el productor en tu ExtensionBinding.

Vincula motores de autorización personalizados

En el siguiente ejemplo, se muestra un recurso ExtensionBinding que vincula una extensión personalizada de un proyecto de productor de 2P o 3P a una Agent Gateway en un proyecto de consumidor. Según el campo matchConditions especificado, esta extensión se invoca cuando se envía tráfico a un agente.

1. Crea un archivo YAML con la siguiente configuración:

   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"
   

   Reemplaza lo siguiente:

   • EXTENSION_BINDING_NAME: Es el nombre del recurso de vinculación de la extensión.
   • CONSUMER_PROJECT_ID: Es el ID del proyecto del consumidor que aloja la puerta de enlace del agente.
   • LOCATION: Es la ubicación de los recursos.
   • AGENT_GATEWAY_NAME: Es el nombre del Agent Gateway de destino.
   • PRODUCER_PROJECT_ID: Es el ID del proyecto del productor que aloja el ProducerExtension.
   • PRODUCER_EXTENSION_NAME: Es el nombre del recurso ProducerExtension.

2. Importa la configuración de vinculación de la extensión:

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

   Reemplaza EXTENSION_BINDING_FILE_PATH por la ruta de acceso al archivo de configuración YAML.

Puntos de conexión de vinculación de extensiones

Las vinculaciones de extensiones se pueden configurar en diferentes niveles de la jerarquía de recursos, según tus requisitos de administración:

• Nivel de Agent Gateway: Adjunta políticas directamente a un recurso de Agent Gateway para controlar todo el tráfico que pasa por la puerta de enlace.
• Nivel de proyecto: Crea ExtensionBindings que se apliquen de forma global a todos los recursos de un tipo determinado dentro de un proyecto, lo que simplifica la administración para los administradores empresariales que aplican el cumplimiento en todo el proyecto.

Vincula una extensión de Model Armor a todas las Agent Gateways de un proyecto

1. Crea un archivo YAML con la siguiente configuración:

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

   Reemplaza lo siguiente:

   • EXTENSION_BINDING_NAME: Es el nombre del recurso de vinculación de la extensión.
   • PROJECT_NUMBER: Es el número de tu proyecto de Cloud de Confiance .
   • TEMPLATE_PROJECT_ID: Es el ID del proyecto en el que se encuentran tus plantillas de Model Armor.
   • LOCATION: Es la ubicación de los recursos.
   • REQUEST_TEMPLATE_ID: Es el ID de la plantilla de Model Armor que se usa para evaluar las solicitudes.
   • RESPONSE_TEMPLATE_ID: Es el ID de la plantilla de Model Armor que se usa para evaluar las respuestas.

2. Importa la configuración de vinculación de la extensión:

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

   Reemplaza EXTENSION_BINDING_FILE_PATH por la ruta de acceso al archivo de configuración YAML.

Para las solicitudes que coinciden con una carga de trabajo específica, se ejecutan las vinculaciones de extensiones a nivel de proyecto y de recurso. Si la misma extensión se configura a nivel del recurso y del proyecto, se invocará dos veces.

Condiciones de coincidencia para invocar extensiones

Las condiciones de coincidencia determinan cuándo se invoca tu extensión. Puedes especificar las condiciones de coincidencia directamente intercaladas (como se muestra en los ejemplos anteriores de esta página) o en un archivo YAML.

En esta sección, se proporcionan parámetros de configuración de archivos YAML de muestra para situaciones comunes en función del flujo de tráfico, los URN de recursos de destino o los hosts de destino:

• Salida a servidores de herramientas de MCP (agente → herramienta): Intercepta el tráfico enviado desde un agente a servidores de herramientas remotos del Protocolo de contexto del modelo (MCP):

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

• Tráfico de entrada (usuario → agente): Intercepta las solicitudes entrantes de los usuarios finales o las aplicaciones cliente que se dirigen a los agentes que rige Agent Gateway (por ejemplo, para aplicar la autenticación de usuarios finales o la limpieza de inyecciones de instrucciones en la entrada):

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

• Salida a modelos de LLM (agente → modelo de LLM): Intercepta las solicitudes enviadas desde los agentes a los modelos de LLM de base o a los servidores de modelos haciendo coincidir el host de destino:

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

Productores: Compila y publica extensiones

Como productor personalizado (2P o 3P), aloja tu implementación de extensión de servicio basada en ext_proc detrás de un adjunto de Private Service Connect. Una vez que el adjunto esté listo, crea un recurso ProducerExtension especificando la fase de procesamiento de la solicitud en la que opera tu extensión, la autoridad que se usará y el URI del adjunto de PSC para tu servicio de ext_proc:

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"

Reemplaza lo siguiente:

• PRODUCER_EXTENSION_NAME: Es el nombre del recurso ProducerExtension.
• PRODUCER_PROJECT_ID: Es el ID del proyecto del productor.
• REGION: Es la región del adjunto de servicio de Private Service Connect.
• PSC_ATTACHMENT_NAME: Es el nombre del adjunto de servicio de Private Service Connect.

Aloja extensiones personalizadas en Cloud Run

Para los productores que desean ejecutar su servicio de gRPC de ext_proc personalizado sin administrar clústeres o VMs dedicados, Cloud Run es una alternativa ideal sin servidores.

Para publicar tu extensión sin servidores como un ProducerExtension, exponla con Private Service Connect (PSC). Debido a que los recursos de ProducerExtension requieren un URI de adjunto de servicio de PSC y los adjuntos de servicio se orientan a las reglas de reenvío del balanceador de cargas en lugar de a los servicios de Cloud Run directamente, coloca un balanceador de cargas de aplicaciones (con un backend de NEG sin servidores) frente a tu servicio de Cloud Run.

Este es el flujo de trabajo de implementación de alto nivel para alojar tu extensión en Cloud Run:

1. Implementa tu extensión en Cloud Run: Aloja tu extensión de gRPC ext_proc personalizada como un servicio alojado en contenedores en Cloud Run.

2. Crea un NEG sin servidores: Implementa un grupo de extremos de red (NEG) sin servidores que apunte a la extensión que se ejecuta en Cloud Run.

3. Configura un balanceador de cargas con el backend de NEG sin servidores: Configura un balanceador de cargas de aplicaciones regional dentro de tu red de VPC, con el NEG sin servidores como backend.

4. Publica tu servicio con PSC: Crea un adjunto de servicio de Private Service Connect que apunte directamente a la regla de reenvío del balanceador de cargas. Esto genera un URI de adjunto de servicio único (por ejemplo, projects/.../regions/.../serviceAttachments/...).

5. Crea tu Producer Extension: Usa este URI generado para crear una instancia de tu recurso ProducerExtension.

6. Vincula las cargas de trabajo de los consumidores: Los consumidores ahora pueden vincular sus puertas de enlace a tu extensión haciendo referencia al URI del recurso ProducerExtension.

Apéndice: Metadatos contextuales para extensiones personalizadas

Para ayudar a que tus extensiones personalizadas tomen decisiones de autorización y procesamiento teniendo en cuenta el contexto,los planos de datos de Cloud de Confiance pasan el contexto del ciclo de vida y de los recursos directamente a los servidores deext_proc.

Esta información se agrupa como metadatos sin tipo dentro del campo metadata_context del ProcessingRequest de gRPC ext_proc. Estos metadatos residen en el espacio de nombres com.google.serviceextensions.invocation_info y usan el formato estándar google.protobuf.Struct.

Puedes decodificar o convertir estos metadatos en JSON para su procesamiento posterior. A continuación, se muestra un ejemplo de formato JSON para una solicitud dirigida a una Agent Gateway con tráfico vinculado a un servidor de MCP:

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

El esquema del JSON es el siguiente:

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