Delega la autorización con Service Extensions

Usa esta página para aprender a delegar la autorización de Agent Gateway a Identity-Aware Proxy, Model Armor y otros motores de autorización personalizados con Service Extensions.

Políticas y extensiones de autorización

Las políticas de autorización te permiten aplicar políticas de administración y control de acceso centralizados en el tráfico que pasa por los extremos publicados por Agent Gateway. Para controlar las decisiones complejas de control de acceso, seguridad del contenido y administración, Agent Gateway te permite configurar políticas de autorización con extensiones de autorización que te permiten delegar las decisiones de autorización y seguridad del contenido a los motores de autorización designados que elijas.

Una extensión de autorización intercepta las solicitudes que pasan por una implementación de Agent Gateway y realiza una llamada de gRPC en tiempo real al servicio de autorización designado. Esto permite que el servicio inspeccione, modifique o bloquee el tráfico antes de que continúe hacia su destino. Puedes delegar la autorización a servicios de Google Cloud , como Identity-Aware Proxy, Model Armor y políticas de gobernanza semánticas, o a cualquier motor de autorización personalizado que elijas.

Las políticas de autorización usan perfiles de política para determinar el tipo de datos de tráfico que se envían a la extensión de autorización:

  • Autorización basada en solicitudes (REQUEST_AUTHZ): Evalúa los encabezados de la solicitud HTTP antes de que se procese cualquier carga útil de la aplicación. Este perfil se usa para la verificación de identidad y el control de acceso, como delegar la autorización a Identity-Aware Proxy.
  • Autorización basada en contenido (CONTENT_AUTHZ): Evalúa las cargas útiles completas de solicitud y respuesta HTTP. Este perfil se usa para la inspección profunda de contenido y la seguridad de la IA, como delegar a Model Armor para la seguridad de las instrucciones y las respuestas, o a las políticas de gobernanza semánticas para la aplicación de restricciones de lenguaje natural.

Los motores de autorización personalizados pueden usar extensiones REQUEST_AUTHZ o CONTENT_AUTHZ, según si inspeccionan encabezados o cargas útiles completas de la aplicación.

Puedes configurar las extensiones de autorización por separado para las políticas basadas en solicitudes y en el contenido, o combinar ambas en una puerta de enlace para obtener una seguridad integral. Para conocer los parámetros de configuración recomendados, consulta Configuración recomendada de entrada y salida.

Para obtener más información sobre las políticas de autorización, los perfiles de políticas y sus casos de uso, consulta Descripción general de las políticas de autorización.

Para obtener una seguridad integral en todo el ciclo de vida del agente, recomendamos el siguiente patrón de arquitectura de varias puertas de enlace:

  • Puertas de enlace de cliente a agente: Las puertas de enlace de cliente a agente (entrada) solo admiten una sola política de CONTENT_AUTHZ. Esto significa que no puedes usar Model Armor y las políticas de gobernanza semántica juntas en la entrada. Te recomendamos que uses una política de Model Armor CONTENT_AUTHZ para protegerte contra los ataques de inyección de instrucciones. Sin embargo, si quieres usar una extensión de política de gobernanza semántica, debes asegurarte de que Model Armor no esté configurado en la puerta de enlace. No se admiten otros tipos de extensiones de servicio para las puertas de enlace de entrada.

  • Puertas de enlace de agente a cualquier lugar: Las puertas de enlace de agente a cualquier lugar (salida) admiten hasta cuatro políticas de autorización. Las puertas de enlace de salida admiten los perfiles de política REQUEST_AUTHZ y CONTENT_AUTHZ, y puedes configurar varias políticas de cada tipo dentro de este límite.

    Te recomendamos la siguiente configuración:

    • Una política de REQUEST_AUTHZ que delega en Identity-Aware Proxy (IAP) para autorizar la identidad del agente.
    • Una o más políticas de CONTENT_AUTHZ que delegan decisiones adicionales a Model Armor o políticas de gobernanza semánticas para proteger contra la exposición de datos sensibles y aplicar restricciones de lenguaje natural en las llamadas y respuestas de herramientas salientes.

    Consulta Evaluación de políticas en la salida para obtener más información sobre cómo se evalúan las políticas.

Esta topología de varias puertas de enlace garantiza que Model Armor filtre los prompts entrantes, mientras que IAP, Model Armor y las políticas de gobernanza semántica filtran las respuestas salientes.

Evaluación de políticas en la salida

Cuando se configuran varias políticas de autorización en una puerta de enlace de salida, se evalúan de forma secuencial según su tipo de perfil de política:

  1. Políticas REQUEST_AUTHZ (basadas en encabezados): Estos tipos de políticas se evalúan primero. Por ejemplo, una extensión de IAP verifica la identidad de mTLS del agente que realiza la llamada y valida sus políticas de permisos de IAM antes de que se procese cualquier contenido. Si la solicitud no pasa esta verificación, se rechaza de inmediato.
  2. Políticas de CONTENT_AUTHZ (basadas en el contenido): Estos tipos de políticas se evalúan a continuación. Si la solicitud pasa la verificación basada en encabezados, la carga útil se transmite a la extensión de autorización basada en contenido (como el motor de políticas de gobernanza semántica) para la inspección profunda del contenido y la evaluación del cumplimiento.

Antes de comenzar

Antes de comenzar, asegúrate de cumplir con los siguientes requisitos:

  • Se implementa Agent Gateway. Consulta Configura Agent Gateway.

  • Debes tener el permiso de IAM networkservices.agentGateways.use en el recurso de Agent Gateway implementado para poder adjuntar políticas de autorización a la puerta de enlace.

Configura políticas de autorización con extensiones

En esta sección, se muestra cómo configurar políticas de autorización que delegan las decisiones de autorización y seguridad del contenido a Identity-Aware Proxy, Model Armor y otros servicios personalizados.

Delega la autorización a IAP

Puedes configurar una extensión de autorización de solicitudes para delegar las decisiones de acceso de las políticas de autorización a IAP.

En los siguientes pasos, se muestra cómo configurar una extensión de autorización con una política de autorización para una instancia de Agent Gateway.

  1. Antes de comenzar: Desactiva la aplicación de la restricción de la política de la organización administrada Inhabilitar la vinculación de la política de acceso al recurso (constraints/iam.managed.disableAccessPolicyBindings). De forma predeterminada, esta restricción booleana está habilitada para las organizaciones nuevas y evitará que vincules una política de acceso unificado de IAM a un recurso. Para obtener más información, consulta Actualiza políticas con reglas booleanas.

  2. Crea las políticas de salida de IAM necesarias para tus agentes y herramientas. Para obtener más información, consulta Crea políticas de agentes de IAM.

  3. Consulta Configura Agent Gateway en el modo de agente a cualquier lugar (salida) para habilitar IAP mientras creas Agent Gateway (con el parámetro Autorización de acceso).

  4. Configura una extensión de autorización para que apunte a IAP.

    1. Define la extensión en un archivo YAML. Usa los valores de muestra proporcionados. Si deseas implementar la extensión en un modo de ejecución de prueba solo de auditoría para probar la política de autorización sin aplicarla, puedes especificar el campo iamEnforcementMode dentro del bloque metadata.

      cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

      Si deseas implementar la extensión en un modo de solo auditoría de ejecución de prueba para probar la política de autorización sin aplicarla, puedes especificar el campo iamEnforcementMode dentro del bloque metadata. Esto te permite verificar tu política y minimizar el riesgo de interrumpir el tráfico debido a errores de configuración:

      cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
  iamEnforcementMode: "DRY_RUN"
EOF

      Quita el campo iamEnforcementMode: "DRY_RUN" del bloque metadata cuando tengas todo listo para comenzar a aplicar las políticas.

    2. Importa la extensión de autorización. Usa el comando gcloud service-extensions authz-extensions import con los siguientes valores de ejemplo.

      gcloud service-extensions authz-extensions import my-iap-request-authz-ext \
    --source=iap-request-authz-extension.yaml \
    --location=LOCATION

  5. En el mismo proyecto, configura una política de autorización que delegue la decisión a la extensión.

    1. Define una política de autorización que asocie la extensión my-iap-request-authz-ext con tu puerta de enlace. Usa los valores de muestra proporcionados.

      cat >iap-request-authz-policy.yaml <<EOF
name: my-iap-request-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-iap-request-authz-ext"
EOF

      Reemplaza PROJECT_ID por el ID del proyecto.

    2. Importa la política de autorización al proyecto. Usa el comando gcloud network-security authz-policies import con los siguientes valores de ejemplo.

      gcloud network-security authz-policies import my-iap-request-authz-policy \
    --source=iap-request-authz-policy.yaml \
    --location=LOCATION

Delega la autorización a Model Armor

Puedes configurar una extensión de autorización para delegar las decisiones de seguridad del contenido de las políticas de autorización a Model Armor.

En el siguiente ejemplo, se muestra cómo configurar una extensión de autorización de este tipo con una política de autorización para Agent Gateway.

Console

Para usar la consola de Google Cloud y habilitar Model Armor para Agent Gateway, sigue estos pasos:

  1. Crea las plantillas de Model Armor necesarias.

  2. Consulta Configura Agent Gateway para habilitar Model Armor mientras creas Agent Gateway (con la casilla de verificación Habilitar Model Armor). Las plantillas de Model Armor se admiten en los modos de cliente a agente y de agente a cualquier lugar.

  3. Cuando usas Model Armor, debes otorgar a la cuenta de servicio de Agent Gateway los permisos necesarios para poder usar las plantillas de Model Armor. La cuenta de servicio tiene el formato service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número del proyecto en el que creaste la puerta de enlace.

    Debes completar este paso, incluso si la puerta de enlace y las plantillas están en el mismo proyecto. Otorga los siguientes roles:

    • Los roles roles/modelarmor.calloutUser y roles/serviceusage.serviceUsageConsumer en el proyecto que contiene la puerta de enlace.
    • El rol roles/modelarmor.user en el proyecto que contiene las plantillas de Model Armor.

    Deberás usar gcloud CLI para completar este paso.

    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

    Reemplaza lo siguiente:

    • GATEWAY_PROJECT_ID: Es el ID del proyecto en el que creaste la puerta de enlace.
    • GATEWAY_PROJECT_NUMBER: Es el número del proyecto en el que creaste la puerta de enlace.
    • MODEL_ARMOR_PROJECT_ID: Es el ID del proyecto que contiene la plantilla de Model Armor.

    Si usas la puerta de enlace para Agent Runtime, el agente de servicio de Agent Runtime también requiere estos permisos, como se documenta en Enruta el tráfico de Agent Runtime a través de Agent Gateway.

gcloud

  1. Crea las plantillas de Model Armor necesarias.

  2. Cuando usas Model Armor, debes otorgar a la cuenta de servicio de Agent Gateway los permisos necesarios para poder usar las plantillas de Model Armor. La cuenta de servicio tiene el formato service-PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número del proyecto en el que creaste la puerta de enlace.

    Debes completar este paso, incluso si la puerta de enlace y las plantillas están en el mismo proyecto. Otorga los siguientes roles:

    • Los roles roles/modelarmor.calloutUser y roles/serviceusage.serviceUsageConsumer en el proyecto que contiene la puerta de enlace.
    • El rol roles/modelarmor.user en el proyecto que contiene la plantilla de Model Armor.
    gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep.iam.gserviceaccount.com \
    --role=roles/modelarmor.user

    Reemplaza lo siguiente:

    • GATEWAY_PROJECT_ID: Es el ID del proyecto en el que creaste la puerta de enlace.
    • GATEWAY_PROJECT_NUMBER: Es el número del proyecto en el que creaste la puerta de enlace.
    • MODEL_ARMOR_PROJECT_ID: Es el ID del proyecto que contiene la plantilla de Model Armor.

  3. Configura la extensión de autorización para que apunte a Model Armor.

    1. Define la extensión en un archivo YAML. Usa los valores de muestra proporcionados.

      cat >ma-content-authz-extension.yaml <<EOF
name: my-ma-content-authz-ext
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

    2. Importa la extensión de autorización. Usa el comando gcloud service-extensions authz-extensions import con los siguientes valores de ejemplo.

      gcloud service-extensions authz-extensions import my-ma-content-authz-ext \
   --source=ma-content-authz-extension.yaml \
   --location=LOCATION

  4. Configura una política de autorización con la extensión.

    1. Define una política de autorización que asocie la extensión my-ma-content-authz-ext con un Agent Gateway.

      Del agente a cualquier lugar 

      cat >ma-content-authz-policy.yaml <<EOF
name: my-ma-content-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext"
httpRules:
  - to:
      operations: [ { "paths": [ { "prefix": "/" } ] } ]
    when: >
      request.headers['content-type'] == 'application/json' ||
      request.headers['content-type'].startsWith('text/')
EOF

      Ten en cuenta lo siguiente:

      • El valor de policyProfile se establece en CONTENT_AUTHZ. Esto indica que el proveedor de políticas personalizadas procesa el tráfico de solicitudes y respuestas, incluido el cuerpo de la solicitud.

      • El parámetro httpRules demuestra cómo usar atributos de CEL para crear condiciones que coincidan con el tráfico específico que deseas reenviar a Model Armor para su evaluación. En este ejemplo, las reglas coinciden con todo el tráfico con los tipos de contenido application/json o text/. Te recomendamos usar estas reglas para limitar la evaluación de Model Armor al tráfico relevante. Esto te permite enrutar el tráfico de la API de LLM, MCP y A2A compatible a Model Armor, mientras se excluye el tráfico interno, como las llamadas de gRPC del agente.

      De cliente a agente 

      cat >ma-content-authz-policy.yaml <<EOF
name: my-ma-content-authz-policy
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext"
EOF

      El valor de policyProfile se establece en CONTENT_AUTHZ. Esto indica que el proveedor de políticas personalizadas procesa el tráfico de solicitudes y respuestas, incluido el cuerpo de la solicitud.

    2. Importa la política de autorización al proyecto. Usa el comando gcloud network-security authz-policies import con los siguientes valores de ejemplo.

      gcloud network-security authz-policies import my-ma-content-authz-policy \
  --source=ma-content-authz-policy.yaml \
  --location=LOCATION

Delega la autorización a extensiones de autorización personalizadas

Puedes configurar extensiones de autorización personalizadas para delegar decisiones a servicios personalizados. Estas extensiones personalizadas solo pueden orientarse a nombres de dominio completamente calificados (FQDN).

Cuando usas destinos de FQDN, la extensión usa el protocolo HTTP2 con encriptación TLS para comunicarse con los extremos en el puerto 443. Sin embargo, la extensión no valida el certificado del servidor. Por lo tanto, para una mejor seguridad, debes asegurarte de que los extremos resueltos estén dentro de la red de VPC. También asegúrate de tener configurado el intercambio de tráfico de DNS entre el proyecto de Agent Gateway y tu red de VPC.

  1. Para configurar una extensión de autorización con una política de autorización para un FQDN específico, como mycustomauthz.internal.net, especifícalo como el valor de service en el archivo YAML de la extensión, como se muestra en el siguiente ejemplo. En este ejemplo, se supone que implementaste un servidor en tu red de VPC que implementa el protocolo ext_proc en el modo de procesamiento del cuerpo FULL_DUPLEX_STREAMED.

    cat >custom-authz-extension.yaml <<EOF
name: my-custom-authz-ext
service: mycustomauthz.internal.net
failOpen: false
timeout: 1s
EOF

  2. Crea la extensión de autorización para que apunte al servicio personalizado.

    gcloud beta service-extensions authz-extensions import custom-authz-extension \
  --source=custom-authz-extension.yaml \
  --location=LOCATION

  3. Después de crear la extensión, configura una política de autorización de CUSTOM que delegue las decisiones a la extensión de autorización.

      cat >authz-policy.yaml <<EOF
  name: authz-with-extension
  target:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
  policyProfile: CONTENT_AUTHZ
  action: CUSTOM
  customProvider:
    authzExtension:
      resources:
        - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/custom-authz-extension"
  EOF

  4. Crea la política de autorización.

    gcloud network-security authz-policies import authz-policy-with-extension \
--source=authz-policy.yaml \
--location=LOCATION

Ten en cuenta que, cuando una extensión de autorización se asocia con una política de autorización con el perfil CONTENT_AUTHZ, como se muestra en este ejemplo, la puerta de enlace invoca la extensión para las cargas útiles de solicitud y respuesta (encabezados y cuerpos), lo que permite la inspección profunda del contenido, las protecciones de instrucciones y la limpieza de datos para el tráfico de tu agente. De forma predeterminada, las políticas de CONTENT_AUTHZ usan el protocolo ext_proc de Envoy en el modo FULL_DUPLEX_STREAMED para procesar los eventos del cuerpo.

Combina la autorización de IAP con las barreras de seguridad de Model Armor

Para obtener una seguridad integral, te recomendamos que configures una política de autorización PERSONALIZADA con un perfil de política REQUEST_AUTHZ y otra política de autorización PERSONALIZADA con un perfil de política CONTENT_AUTHZ.

En el siguiente ejemplo, se usa IAP como un sistema centralizado de autorización de solicitudes y Model Armor para las protecciones de IA. Como se muestra en los ejemplos anteriores, puedes intercambiar cada uno de estos con extensiones de servicio para usar tus propias soluciones personalizadas.

  1. Configura una extensión de autorización de REQUEST_AUTHZ que delegue en IAP y una política de autorización que apunte a la extensión.

    1. Define la extensión de autorización. El campo iapPolicyVersion en metadata es obligatorio.

      cat >iap-extension.yaml <<EOF
name: iap-extension
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

    2. Crea la extensión de autorización.

      gcloud service-extensions authz-extensions import iap-extension \
--source=iap-extension.yaml \
--location=LOCATION

      Reemplaza LOCATION por la región de la extensión.

    3. Configura la política de autorización REQUEST_AUTHZ que delega en la extensión.

      cat >authz-policy-request-authz.yaml <<EOF
name: authz-iap
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/iap-extension"
EOF

      Reemplaza lo siguiente:

      • PROJECT_ID: ID del proyecto
      • LOCATION: Es la ubicación de los recursos.
      • AGENT_GATEWAY_NAME: Es el nombre de la puerta de enlace del agente.

    4. Crea la política de autorización.

      gcloud network-security authz-policies import authz-iap \
--source=authz-policy-request-authz.yaml \
--location=LOCATION

  2. Configura una extensión de autorización de CONTENT_AUTHZ que delegue en Model Armor y una política de autorización que apunte a la extensión.

    1. Define la extensión.

      cat >ma-extension-file.yaml <<EOF
name: ma-extension
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
    }
  ]'
failOpen: false
timeout: 1s
EOF

      Reemplaza lo siguiente:

      • LOCATION: Es la región en la que residen tus plantillas de Model Armor.
      • MODEL_ARMOR_PROJECT_ID: Es el ID del proyecto que contiene las plantillas de Model Armor.
      • RESPONSE_TEMPLATE_ID: Es el ID de la plantilla de respuesta.
      • REQUEST_TEMPLATE_ID: Es el ID de la plantilla de solicitud.

    2. Crea la extensión de autorización.

      gcloud service-extensions authz-extensions import ma-extension \
--source=ma-extension-file.yaml \
--location=LOCATION

    3. Configura la política de autorización CONTENT_AUTHZ que delega en la extensión.

      cat >authz-policy-content-authz.yaml <<EOF
name: authz-ma
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
EOF

    4. Crea la política de autorización.

      gcloud network-security authz-policies import ma-authz-policy \
--source=authz-policy-content-authz.yaml \
--location=LOCATION

Cuando una extensión de autorización se asocia con un perfil de CONTENT_AUTHZ, recibe todos los eventos de ext_proc, incluidos los encabezados de solicitud y respuesta, el cuerpo y los finales. Si tu extensión de autorización basada en ext_proc puede controlar la autorización en el momento de la solicitud y la autorización basada en el contenido, te recomendamos configurar una sola política de autorización de CUSTOM con el perfil de política de CONTENT_AUTHZ. Esta política debe apuntar a tu extensión de autorización versátil. Este enfoque habilita ambos tipos de autorización a través de una sola extensión y una conexión ext_proc, lo que puede mejorar los perfiles de latencia.

Delega la autorización a las políticas de gobernanza semánticas

Puedes configurar una extensión de autorización para delegar las decisiones de restricción de lenguaje natural y de control de intents de las políticas de autorización al motor de políticas de gobernanza semántica (semanticGovernancePolicyEngine).

Para aprender a aprovisionar el Policy Engine y crear la política de autorización de CONTENT_AUTHZ y la vinculación de la extensión de autorización necesarias en tu puerta de enlace, consulta Conecta el Policy Engine a Agent Gateway.

Autorización basada en atributos del protocolo MCP

Agent Gateway analiza la carga útil del protocolo MCP en una solicitud y pone a disposición los atributos extraídos para las políticas de autorización.

Puedes restringir el acceso según los parámetros del método de MCP, como los nombres de herramientas específicas. En esta sección, se muestran dos ejemplos: uno para una política de ALLOW y otro para DENY.

  1. Configura la política de autorización.

    Ejemplo de política de ALLOW

    Este ejemplo permite el acceso a un conjunto específico de herramientas en el servidor de MCP y a las funciones del protocolo base, pero no permite el acceso a las instrucciones ni a los recursos.

    Cuando escribas una política de ALLOW, asegúrate de especificar baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS para que las RPC de MCP específicas que no sean de acceso, como la inicialización, el registro, la finalización, las notificaciones y el ping, sigan funcionando. De lo contrario, no se podrá establecer una sesión de MCP.

    cat >authz-policy-restrict-tools.yaml <<EOF
name: my-authz-policy-restrict-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
        methods:
        - name: "tools/list"
        - name: "tools/call"
          params:
          - exact: "get_weather"
          - exact: "get_location"
action: ALLOW
EOF

    Ejemplo de política de DENY

    En este ejemplo, se inhabilita todo el acceso de prompts/method a un servidor de MCP detrás de un Agent Gateway.

    cat >authz-policy-disallow-prompts.yaml <<EOF
name: my-authz-policy-disallow-prompts
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        methods:
        - name: "prompts"
action: DENY
EOF

  2. Crea la política de autorización.

    gcloud network-security authz-policies import AUTHZ_POLICY_NAME \
--source=AUTH_POLICY_YAML_FILE_PATH \
--location=LOCATION

    Reemplaza lo siguiente:

    • AUTHZ_POLICY_NAME: Es el nombre de la política de autorización.
    • AUTH_POLICY_YAML_FILE_PATH: Es la ruta de acceso al archivo YAML de la política de autorización.
    • LOCATION: Es la ubicación de los recursos.

Limitaciones

Se aplican las siguientes limitaciones cuando usas políticas de autorización:

  • La cantidad máxima de políticas de autorización por puerta de enlace depende del modo de puerta de enlace:

    • Para las puertas de enlace de agente a cualquier lugar (salida), puedes configurar un máximo de cuatro políticas de autorización por puerta de enlace, independientemente del perfil de política (REQUEST_AUTHZ o CONTENT_AUTHZ).
    • Para las puertas de enlace de cliente a agente (entrada), puedes configurar un máximo de una política CONTENT_AUTHZ.

    Para obtener más información, consulta Configuración recomendada de entrada y salida.

  • Si usas extensiones de autorización personalizadas con el perfil CONTENT_AUTHZ, deben admitir el protocolo ext_proc y el modo FULL_DUPLEX_STREAMED para los eventos de cuerpo.

  • Si configuras varias políticas de autorización personalizadas que usan el mismo perfil, no se garantiza su orden de ejecución.

Además, consulta las siguientes secciones para obtener más información sobre las limitaciones de las extensiones de autorización:

¿Qué sigue?

Codelab

Aprende a administrar las cargas de trabajo de agentes con Agent Gateway en Gemini Enterprise Agent Platform.

Guía

Aprende a supervisar Agent Gateway.

Solución de problemas

Aprender a solucionar problemas de conectividad de Agent Gateway