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 centralizadas al tráfico que pasa por los extremos publicados por Agent Gateway. Para controlar el control de acceso complejo, la seguridad del contenido y las decisiones de 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 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ántica, 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 las solicitudes 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 la delegación de autorización a Identity-Aware Proxy.
  • Autorización basada en contenido (CONTENT_AUTHZ): Evalúa las cargas útiles completas de las solicitudes y respuestas HTTP. Este perfil se usa para la inspección profunda del contenido y la seguridad de la IA, por ejemplo, para delegar en Model Armor la seguridad de las instrucciones y las respuestas, o en las políticas de administración semántica 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 contenido, o bien combinar ambas en una puerta de enlace para obtener seguridad integral. Para obtener información sobre la configuración recomendada, 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 la 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 múltiples 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 CONTENT_AUTHZ de Model Armor 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 Agent-to-Anywhere: Las puertas de enlace de Agent-to-Anywhere (salida) admiten hasta cuatro políticas de autorización. Las puertas de enlace de salida admiten perfiles de políticas 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 administración semántica para proteger contra la exposición de datos sensibles y aplicar restricciones de lenguaje natural en las llamadas y respuestas salientes de herramientas.

    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 múltiples puertas de enlace garantiza que Model Armor filtre las instrucciones entrantes, mientras que las políticas de IAP, Model Armor y 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 de 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 llama 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 el 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 implementó Agent Gateway. Consulta Configurar 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 en 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 política de la organización administrada Disable binding access policy to resource (constraints/iam.managed.disableAccessPolicyBindings). De forma predeterminada, esta restricción booleana está habilitada para las organizaciones nuevas y te impedirá vincular 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 requeridas 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 Agent-to-Anywhere (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 ejecución de prueba de solo auditoría 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 esté todo listo para comenzar a aplicar políticas.

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

      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 muestra.

      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 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 Client-to-Agent y Agent-to-Anywhere.

  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 de 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 muestra.

      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 muestra cómo usar los 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 que tiene tipos de contenido application/json o text/. Te recomendamos que uses estas reglas para limitar la evaluación de Model Armor al tráfico pertinente. Esto te permite enrutar el tráfico compatible de la API de LLM, el MCP y el A2A a Model Armor, y excluir el tráfico interno, como las llamadas a 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 muestra.

      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 segmentarse para 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 haber 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 se asocia una extensión de autorización con una política de autorización usando 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 una inspección profunda del contenido, medidas de protección de instrucciones y saneamiento 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 eventos del cuerpo.

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

Para 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 la IAP como un sistema de autorización de solicitudes centralizado y Model Armor para las barreras de protección de la 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 REQUEST_AUTHZ que delega a IAP y una política de autorización que apunta 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 Agent Gateway.

    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 CONTENT_AUTHZ que delega en Model Armor y una política de autorización que apunta 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 tráileres. 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 que configures una sola política de autorización CUSTOM con el perfil de política CONTENT_AUTHZ. Esta política debe apuntar a tu extensión de autorización versátil. Este enfoque permite ambos tipos de autorización a través de una sola extensión y conexión de ext_proc, lo que puede mejorar los perfiles de latencia.

Delega la autorización a las políticas de administración semántica

Puedes configurar una extensión de autorización para delegar las decisiones de restricción de intención y restricción de lenguaje natural para las políticas de autorización en el motor de políticas de administración semántica (semanticGovernancePolicyEngine).

Para obtener información sobre cómo aprovisionar el Policy Engine y crear la política de autorización CONTENT_AUTHZ y la vinculación de extensión de autorización requeridas en tu puerta de enlace, consulta Conecta el Policy Engine a Agent Gateway.

Autorización basada en atributos del protocolo de MCP

Agent Gateway analiza la carga útil del protocolo de MCP en una solicitud y pone los atributos extraídos a disposición de 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 una de DENY.

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

    Ejemplo de política de ALLOW

    En este ejemplo, se permite el acceso a un conjunto específico de herramientas en el servidor de MCP y a las funciones del protocolo base, pero se prohíbe el acceso a instrucciones y recursos.

    Cuando escribas una política de ALLOW, asegúrate de especificar baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS para que las RPC de MCP no específicas del acceso, como las de inicialización, registro, finalización, notificaciones y 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 rechaza el acceso a todos los métodos o instrucciones de 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 la puerta de enlace:

    • En el caso de las puertas de enlace de Agent-to-Anywhere (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).
    • En el caso de las puertas de enlace de cliente a agente (entrada), puedes configurar un máximo de una política de 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 del 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 controlar las cargas de trabajo de agentes con Agent Gateway en Gemini Enterprise Agent Platform.

Guía

Obtén más información para supervisar Agent Gateway.

Solución de problemas

Obtén más información para solucionar problemas de conectividad de Agent Gateway.