Configura Agent Gateway

Para centralizar el control de acceso y proteger la conectividad en tus flujos de trabajo basados en agentes, puedes configurar un recurso de Agent Gateway para administrar el tráfico de entrada o salida.

Antes de configurar una puerta de enlace, revisa los conceptos básicos y los componentes principales en la descripción general de Agent Gateway.

Permisos necesarios

Se requieren los siguientes permisos para crear y administrar Agent Gateways. Puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.

Permisos necesarios

  • agentregistry.agents.list
  • agentregistry.endpoints.list
  • agentregistry.mcpServers.list
  • compute.networkAttachments.create
  • compute.networkAttachments.delete
  • compute.networkAttachments.get
  • compute.networkAttachments.list
  • compute.networkAttachments.update
  • compute.regionOperations.get
  • compute.regions.list
  • modelarmor.templates.list
  • networksecurity.authzPolicies.create
  • networksecurity.authzPolicies.delete
  • networksecurity.authzPolicies.get
  • networksecurity.authzPolicies.list
  • networksecurity.operations.get
  • networkservices.agentConnectivityTemplates.create
  • networkservices.agentConnectivityTemplates.delete
  • networkservices.agentConnectivityTemplates.get
  • networkservices.agentConnectivityTemplates.list
  • networkservices.agentConnectivityTemplates.update
  • networkservices.agentGateways.create
  • networkservices.agentGateways.delete
  • networkservices.agentGateways.get
  • networkservices.agentGateways.list
  • networkservices.agentGateways.update
  • networkservices.agentGateways.use
  • networkservices.authzExtensions.create
  • networkservices.authzExtensions.delete
  • networkservices.authzExtensions.get
  • networkservices.authzExtensions.list
  • networkservices.authzExtensions.update
  • networkservices.authzExtensions.use
  • networkservices.operations.get
  • certificatemanager.trustconfigs.create
  • certificatemanager.trustconfigs.get
  • certificatemanager.trustconfigs.list
  • certificatemanager.trustconfigs.use

APIs requeridas

Habilita las siguientes APIs mínimas requeridas en el proyecto Cloud de Confiance en el que implementas Agent Gateway:

  • API de Compute Engine (compute.googleapis.com): Proporciona infraestructura de redes principal, subredes, enrutamiento y adjuntos de red de Private Service Connect (PSC).
  • API de Network Security (networksecurity.googleapis.com): Crea y aplica políticas de autorización (authzPolicies) para el tráfico de la puerta de enlace.
  • API de Network Services (networkservices.googleapis.com): Administra los recursos de Agent Gateway (agentGateways), las plantillas de conectividad (agentConnectivityTemplates) y las extensiones de autorización (authzExtensions).
  • API de Identity and Access Management (iam.googleapis.com): Administra las cuentas de servicio y las políticas de acceso unificado (UAP) de IAM para las identidades de los agentes.
  • API de Identity-Aware Proxy (iap.googleapis.com): Autentica y verifica el tráfico del agente, el extremo y el servidor.
  • API de Agent Registry (agentregistry.googleapis.com): Registra y administra agentes, servidores de MCP y extremos de herramientas regidos por la puerta de enlace.

Para habilitar las APIs mínimas requeridas, ejecuta el siguiente comando:

gcloud services enable \
    compute.googleapis.com \
    networksecurity.googleapis.com \
    networkservices.googleapis.com \
    iam.googleapis.com \
    iap.googleapis.com \
    agentregistry.googleapis.com \
    --project=PROJECT_ID

Reemplaza PROJECT_ID por el ID del proyecto en el que implementas Agent Gateway.

Según las funciones, las herramientas de observabilidad y los tiempos de ejecución del agente que uses con Agent Gateway, es posible que también debas habilitar las siguientes APIs opcionales:

APIs opcionales por función

  • Conectividad de VPC privada y TLS:
    • API de Cloud DNS (dns.googleapis.com): Solo se requiere si configuras la conectividad de VPC con el intercambio de tráfico de Cloud DNS para la resolución de dominios privados.
    • API de Certificate Manager (certificatemanager.googleapis.com): Solo se requiere si configuras anclajes de confianza de TLS personalizados (TrustConfig) cuando te conectas a back-ends privados que usan AC privadas o certificados autofirmados.
  • Seguridad de la IA y filtrado de contenido:
    • API de Model Armor (modelarmor.googleapis.com): Solo se requiere si habilitas las protecciones de Model Armor para inspeccionar y filtrar la inyección de instrucciones, el contenido tóxico y los datos sensibles.
  • Observabilidad y auditoría:
    • API de Cloud Logging (logging.googleapis.com): Captura registros de acceso a la puerta de enlace, registros de auditoría de seguridad y eventos de evaluación de políticas de ejecución en seco.
    • API de Cloud Monitoring (monitoring.googleapis.com): Realiza un seguimiento del estado, la latencia, la capacidad de procesamiento y las tasas de error de la puerta de enlace, y configura alertas operativas.
    • API de Observabilidad (observability.googleapis.com): Proporciona paneles operativos y de observabilidad unificados para la actividad del agente y la puerta de enlace.
    • API de Telemetry (telemetry.googleapis.com): Recopila y transmite métricas de rendimiento y telemetría del tiempo de ejecución en los componentes de la plataforma.
    • API de Cloud Trace (cloudtrace.googleapis.com): Proporciona un registro de seguimiento distribuido para inspeccionar solicitudes de múltiples saltos en agentes y back-ends.
  • Tiempos de ejecución del agente y administración semántica:
    • API de Vertex AI (aiplatform.googleapis.com): Se requiere en los proyectos que alojan agentes de Agent Runtime o usan políticas de gobernanza semántica.
    • API de Discovery Engine (discoveryengine.googleapis.com): Se requiere en los proyectos que alojan apps y agentes de Gemini Enterprise.
    • API de Agent Identity (agentidentity.googleapis.com): Solo se requiere si administras credenciales salientes con el administrador de autenticación de Agent Identity o si ves proveedores de autenticación de Agent Identity en la consola de Cloud de Confiance .

Planifica la implementación de Agent Gateway

Usa esta sección para planificar la implementación de tu Agent Gateway y comprender los requisitos de la arquitectura de administración. Puedes volver a consultar estos pasos cuando registres destinos nuevos, agregues políticas de control de acceso nuevas o implementes más agentes.

Elige tu modo de implementación

Agent Gateway admite dos modos de implementación:

  • De cliente a agente (entrada): Protege las comunicaciones de los clientes a tus agentes que se ejecutan en Cloud de Confiance.
  • Agente a cualquier lugar (salida): Protege las comunicaciones de tus agentes a destinos externos, APIs públicas y servidores de MCP.

Selecciona tu entorno de ejecución, proyecto y región de implementación

Agent Gateway administra el tráfico de los agentes que se ejecutan en Gemini Enterprise y Runtime.

  • Agent Runtime: Agent Gateway admite los modos Agent-to-Anywhere (salida) y Client-to-Agent (entrada). En el modo Agent-to-Anywhere, los agentes pueden estar en el mismo proyecto que la puerta de enlace o en uno diferente. En el modo Cliente a agente, los agentes deben estar en el mismo proyecto que la puerta de enlace. En cualquiera de los modos, los agentes deben estar en la misma región que la puerta de enlace.

  • Gemini Enterprise: Agent Gateway solo admite el modo de agente a cualquier lugar (salida). Con Gemini Enterprise, cada puerta de enlace rige las interacciones basadas en agentes solo dentro del alcance del proyecto y la región en los que se implementa.

Para controlar los agentes en Gemini Enterprise y Runtime, puedes usar una sola instancia de Agent Gateway. Como alternativa, también puedes implementar instancias independientes de Agent Gateway para Gemini Enterprise y Agent Runtime.

Patrones de implementación de muestra

Estos son algunos patrones de implementación de ejemplo que puedes considerar:

Administración multiproyecto para agentes de Runtime

En este patrón de implementación, implementas una Agent Gateway de Agent-to-Anywhere (salida) en un proyecto de gobernanza dedicado. Los agentes de entorno de ejecución se implementan en proyectos separados en la misma región que la puerta de enlace y pueden pertenecer a cualquier carpeta dentro de tu organización.

Para configurar la administración de la salida entre proyectos, debes configurar los siguientes recursos:

En el proyecto de administración central, haz lo siguiente:

  • Crea Agent Gateway. Asegúrate de que la puerta de enlace esté asociada a una instancia de Agent Registry.
  • Registra agentes entre proyectos junto con cualquier herramienta, servidor o extremo con el Agent Registry adjunto a la puerta de enlace.
  • Otorga permisos de IAM entre proyectos al agente de servicio de ejecución de cada proyecto en el que se basan los agentes para que los agentes de estos proyectos puedan vincularse a la puerta de enlace en el proyecto de gobernanza. Para ver un ejemplo, consulta Enruta el tráfico de Agent Runtime a través de Agent Gateway.
  • Configura políticas del IAP, límites de acceso de la principal e identidades para cargas de trabajo compatibles con SPIFFE para controlar y proteger el tráfico de salida a los extremos autorizados.
  • Crea las plantillas de Model Armor que quieras usar para la salida.
  • Si deseas realizar una salida a una red de VPC, puedes crear la vinculación de red de PSC, anclajes de confianza de TLS personalizados (tlsConfig) para las CA privadas y la configuración del intercambio de tráfico de DNS en el proyecto de administración.

En los proyectos de Agent Runtime, ocurre lo siguiente:

  • Implementa los agentes y vincúlalos a la puerta de enlace central en el proyecto de gobernanza.

Ten en cuenta que la administración entre proyectos solo se admite para las puertas de enlace de tiempo de ejecución con Agent-to-Anywhere (salida). Gemini Enterprise no es compatible.

Administración compartida para los agentes de Gemini Enterprise y de Agent Runtime

En este patrón de implementación, todo el tráfico de las apps de Gemini Enterprise y los agentes de Runtime se enruta a través de un único Agent Gateway.

A continuación, se muestra una muestra de implementación:

  • La app de Gemini Enterprise se implementa como una globalimplementación.
  • Los agentes de tiempo de ejecución se implementan en una sola región (us-central1) que corresponde a la implementación de Gemini Enterprise.
  • El Agent Gateway se implementa en la misma región (us-central1).
  • Ambas instancias de Agent Registry, global y us-central1, se pueden asociar con Agent Gateway. Los agentes y los destinos deben registrarse en las instancias de Agent Registry asociadas con la puerta de enlace.
Administración independiente para los agentes de Gemini Enterprise y Runtime

En este patrón de implementación, cada región tiene un Agent Gateway dedicado para supervisar y controlar el tráfico de agentes, lo que garantiza el aislamiento regional:

  • La app de Gemini Enterprise se implementa como una implementación global o multirregional (en global, us o eu).
  • Los agentes de tiempo de ejecución se implementan en cada región según sea necesario.
  • Las instancias de Agent Gateway se implementan en cada región en la que se encuentran los agentes y las apps.
  • Debes registrar tus agentes y destinos en las instancias de Agent Registry asociadas con cada puerta de enlace.

Configura la identidad del agente

Cada agente que se rige por Agent Gateway requiere su propia identidad de agente (un ID de SPIFFE) único. Dado que las políticas de acceso de IAM dependen de esta identidad de carga de trabajo, el tráfico de agentes no identificados se bloquea de forma predeterminada.

Puedes aprovisionar una identidad del agente cuando implementas un agente en el entorno de ejecución o asignarlo a cargas de trabajo de agentes existentes. Para obtener instrucciones detalladas, consulta Usa Agent Identity con el entorno de ejecución.

Registra tus agentes y recursos de destino

Para habilitar la comunicación segura, debes identificar tu instancia de Agent Registry y registrar los recursos que controlará tu puerta de enlace.

  1. Identifica las instancias del Registro de agentes que usarás. Un Agent Gateway se puede asociar con hasta dos registros (uno global y uno regional o multirregional):

    • Los agentes de Agent Runtime son recursos regionales y, por lo general, se registran en registros regionales que coinciden con su región de implementación. Ten en cuenta que los agentes entre proyectos deben registrarse en el registro asociado con el proyecto de administración central en el que se implementa el Agent Gateway.
    • Los agentes de Gemini Enterprise son recursos globales o multirregionales y se registran en registros globales o multirregionales (como global, us o eu).

    Asegúrate de que las instancias del registro que asocies con tu Agent Gateway sean aquellas en las que estén registrados tus agentes, endpoints y servidores.

  2. Registra tus agentes en Agent Registry. Si aún no creaste el agente, debes completar este paso más adelante. Para obtener instrucciones, consulta Cómo registrar agentes.

  3. Recomendación: Identifica y registra todas las herramientas, los servidores de MCP y los extremos de API a los que llamarán tus agentes (incluidas las APIs esenciales de la plataforma). El acceso del agente a los destinos siempre requiere una política de acceso de IAM que otorgue el permiso iap.resources.egressViaIAP a la identidad del agente. Te recomendamos que registres los recursos en Agent Registry para que puedas aplicar políticas detalladas por recurso y controles a nivel de la herramienta. En el caso de los destinos que no están registrados, debes otorgar este permiso al agente configurando políticas para los extremos no registrados.

    Los destinos que se encuentran en un proyecto diferente del de la puerta de enlace deben registrarse en el Registro de agentes del proyecto de la puerta de enlace. Estos destinos solo son válidos para los agentes de tiempo de ejecución en el modo Agent-to-Anywhere.

    Para obtener instrucciones, consulta las siguientes guías:

Configura las políticas de control de acceso

Cada Agent Gateway requiere una política de autorización asociada.

IAM (solo en el modo del agente a cualquier lugar)

Configura una política de IAM que asigne el permiso iap.resources.egressViaIAP a la identidad principal de tu agente para cada uno de los recursos de destino que registraste en Agent Registry.

De forma predeterminada, Agent Gateway bloquea todo el tráfico, a menos que una política de acceso de IAM autorice explícitamente el acceso del agente a los recursos de destino otorgando el permiso iap.resources.egressViaIAP a la identidad del agente.

Se recomienda registrar destinos en el Registro de agentes porque te permite definir el alcance de las políticas para recursos específicos y aplicar controles detallados de herramientas. Si los destinos no están registrados en Agent Registry, debes otorgar el permiso iap.resources.egressViaIAP al agente configurando una política para los extremos no registrados.

Dado que los registros pueden ser globales, multirregionales o regionales, asegúrate de que cualquier vinculación a nivel del registro coincida con la instancia (o instancias) del registro configurada para tu puerta de enlace de agente.

Para obtener instrucciones, consulta Crea políticas de agentes de IAM.

Para validar tu configuración sin bloquear el tráfico, te recomendamos que implementes el IAP en el modo de ejecución de prueba inicialmente.

Model Armor

(Opcional) Si tu implementación requiere protección contra ataques de inyección de instrucciones, jailbreaks, contenido tóxico o filtración de datos sensibles, debes planificar la integración de las barreras de Model Armor y crear plantillas con los filtros de seguridad que necesites.

Para obtener más información, consulta los siguientes documentos:

Políticas de administración semántica

(Opcional) Puedes optar por agregar controles contextuales basados en lenguaje natural a tus agentes para habilitar protecciones contra combinaciones tóxicas de herramientas.

Te recomendamos que comiences por implementar las políticas de gobierno semántico en modo de prueba para que puedas validar tu configuración sin bloquear el tráfico. Para obtener más información, consulta Cómo configurar políticas de gobernanza semántica.

Motores de autorización personalizados

(Opcional) Si deseas delegar la autorización a motores de autorización personalizados o sistemas de terceros con Service Extensions, debes asegurarte de que los motores de autorización personalizados estén disponibles cuando implementes la puerta de enlace.

Model Armor, las políticas de administración semántica y cualquier otro motor de autorización personalizado se pueden habilitar durante la configuración inicial de Agent Gateway o adjuntar después de la implementación como una actualización incremental de la política de seguridad.

Configura Agent Gateway en el modo Agent-to-Anywhere (salida)

Cuando configures Agent Gateway en el modo Agent-to-Anywhere (salida), podrás establecer cómo el tráfico regulado llega a los extremos y las herramientas de destino. Según tus requisitos de redes y seguridad, elige entre las siguientes opciones de implementación:

  • Salida de Internet: La puerta de enlace enruta de forma segura el tráfico del agente a las APIs y los extremos accesibles de forma pública a través de Internet. Para configurar un Agent Gateway con salida de Internet, puedes seguir las instrucciones de esta página.

  • Salida de red de VPC: La puerta de enlace enruta el tráfico del agente de forma privada a una red de VPC con adjuntos de red de Private Service Connect. Puedes elegir enrutar todo el tráfico a través de la red de VPC (ALL_TRAFFIC) o solo el tráfico destinado a rangos de direcciones IP privadas (PRIVATE_RANGES_ONLY).

    Para configurar un Agent Gateway con salida de VPC, debes seguir las instrucciones que se indican en Configura la conectividad de VPC para Agent Gateway.

Sigue estos pasos para crear un recurso de Agent Gateway para las comunicaciones de Agent-to-Anywhere.

Consola de Cloud de Confiance

  1. En la consola de Cloud de Confiance , ve a la página Agent Gateway.

    Ir a Gateways

  2. Haz clic en Agregar puerta de enlace.
  3. Ingresa un Nombre.
  4. En la lista Región, selecciona una región.
  5. En Modo de implementación, verifica que esté seleccionada la opción Administrado por Google.
  6. En Registros de agentes, selecciona al menos un registro de la lista. Si quieres seleccionar dos registros, uno debe ser global y el otro puede ser regional o multirregional.Para obtener orientación sobre qué registro elegir para tu implementación, consulta Planifica tu implementación de Agent Gateway.
  7. En la lista Ruta de acceso administrada, selecciona Agent-to-Anywhere (salida del agente).

  8. En la sección Autorización de acceso, elige cómo IAP controla el tráfico:

    • Para implementar la puerta de enlace en un modo de ejecución de prueba en el que la puerta de enlace permite todo el tráfico y solo genera registros de auditoría, selecciona Solo auditoría. IAP no aplica tus políticas de IAM en el modo de prueba de validación. Una vez que te sientas seguro, puedes inhabilitar el modo de ejecución de prueba para aplicar las políticas de IAM.
    • Para bloquear las solicitudes que no tienen una política de IAM Allow explícita, selecciona Aplicar políticas. Esta opción se recomienda para entornos de producción.
    • En Modelo de política, selecciona Política de acceso unificado.

  9. Opcional: En la sección Seguridad de la IA, configura seguridad adicional:

    1. Para proteger las interacciones del modelo de IA con Model Armor, activa Habilitar Model Armor.
    2. Selecciona una plantilla de la lista que se aplique a las solicitudes entrantes a la puerta de enlace.

    3. Para usar una plantilla diferente para las respuestas, desmarca Usar la misma plantilla para solicitudes y respuestas y selecciona una plantilla de la lista.

  10. Haz clic en Agregar puerta de enlace.

gcloud

Defines las puertas de enlace de agentes de forma declarativa con YAML.

  1. Define el recurso y guarda la configuración en un archivo YAML. Para este ejemplo, usamos my-agent-gateway-egress.yaml.

    name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - AGENT_REGISTRY_URI_1
  - OPTIONAL_AGENT_REGISTRY_URI_2

    Reemplaza lo siguiente:

    • AGENT_GATEWAY_NAME: Es el nombre del recurso de Agent Gateway.

    • AGENT_REGISTRY_URI_1 y OPTIONAL_AGENT_REGISTRY_URI_2: Son las rutas de acceso a las instancias de Agent Registry que se asociarán con la puerta de enlace. Puedes configurar hasta dos registros para una Agent Gateway. Cuando configures dos registros, uno debe ser global y el otro puede ser regional o multirregional. Para obtener orientación sobre qué registro elegir para tu implementación, consulta Planifica tu implementación de Agent Gateway. Las rutas de acceso del registro deben tener el siguiente formato:

      • Registros regionales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
      • Registros globales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
      • Registros multirregionales: //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

  2. Ejecuta el siguiente comando para crear un recurso de Agent Gateway basado en la especificación YAML:

    gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
 --source="my-agent-gateway-egress.yaml" \
 --location=LOCATION

    Reemplaza LOCATION por la ubicación en la que deseas crear el recurso de Agent Gateway. Por ejemplo, us-central1.

    Ten en cuenta que, para Gemini Enterprise, debes implementar Agent Gateway en una región que corresponda a tu configuración multirregional. Para conocer las asignaciones de ubicación admitidas, consulta Cómo enrutar el tráfico de Gemini Enterprise a través de Agent Gateway.

  3. Crea una política de autorización para aplicar políticas de control de acceso y administración centralizadas en el tráfico que pasa por Agent Gateway. En los siguientes pasos, se muestra cómo configurar una política de autorización que usa IAP.

    1. Configura una extensión de autorización que apunte a IAP. Define la extensión en un archivo YAML, como iap-request-authz-extension.yaml. Usa los valores de muestra proporcionados:

      cat >iap-request-authz-extension.yaml <<EOF
name: AUTHORIZATION_EXTENSION_NAME
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: AUTHORIZATION_EXTENSION_NAME
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 el archivo de configuración YAML a una extensión de autorización.

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

      Reemplaza AUTHORIZATION_EXTENSION_NAME por el nombre de la extensión de autorización, por ejemplo, my-iap-request-authz-ext.

    3. Define una política de autorización en un archivo YAML, como iap-request-authz-policy.yaml, para asociar la extensión con tu puerta de enlace:

      cat >iap-request-authz-policy.yaml <<EOF
name: AUTHORIZATION_POLICY_NAME
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/AUTHORIZATION_EXTENSION_NAME"
EOF

      Reemplaza lo siguiente:

      • AUTHORIZATION_POLICY_NAME: el nombre de la política de autorización, por ejemplo, my-iap-request-authz-policy
      • PROJECT_ID: El ID del proyecto

    4. Importa el archivo de configuración YAML a una política de autorización.

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

  4. Opcional: Si deseas configurar barreras de seguridad de Model Armor para proteger tu implementación contra ataques de inyección de instrucciones y filtraciones de datos sensibles, consulta Cómo delegar la autorización en Model Armor.

  1. Después de crear un Agent Gateway, este sirve como el punto de conexión principal para enrutar el tráfico de agentes dentro de tu proyecto y la región elegida. Ahora puedes usar este extremo para establecer canales de comunicación seguros, encriptados y autenticados entre los agentes y sus destinos (herramientas, otros agentes u otros extremos).

    Vuelve a revisar la sección Plan your Agent Gateway deployment de esta página y asegúrate de que tus agentes estén registrados en Agent Registry y de que se les haya otorgado el permiso iap.resources.egressViaIAP para todos los destinos a los que intentan conectarse. Si tienes problemas de conectividad, consulta Soluciona problemas de conectividad de Agent Gateway.

A continuación, obtén información para implementar agentes y enrutar el tráfico a través de Agent Gateway.

Configura Agent Gateway en el modo de cliente a agente (entrada)

En esta sección, se muestra cómo configurar un Agent Gateway para las comunicaciones de cliente a agente.

Sigue estos pasos para crear un recurso de Agent Gateway.

Consola de Cloud de Confiance

  1. En la consola de Cloud de Confiance , ve a la página Agent Gateway.

    Ir a Gateways

  2. Haz clic en Agregar puerta de enlace.
  3. Ingresa un Nombre.
  4. En la lista Región, selecciona una región.
  5. En Modo de implementación, verifica que esté seleccionada la opción Administrado por Google.
  6. Deja la configuración de Agent registry tal como está. El registro no se usa para la entrada.
  7. En la lista Ruta de acceso administrada, selecciona Cliente a agente (entrada).

  8. Opcional: En la sección Seguridad de IA, configura seguridad adicional:

    1. Para proteger las interacciones del modelo de IA con Model Armor, activa Habilitar Model Armor.

    2. Selecciona una plantilla de la lista que se aplique a las solicitudes entrantes a la puerta de enlace.

    3. Para usar una plantilla diferente para las respuestas, desmarca Usar la misma plantilla para solicitudes y respuestas y selecciona una plantilla de la lista.

  9. Haz clic en Agregar puerta de enlace.

gcloud

Defines las puertas de enlace de agentes de forma declarativa con YAML.

  1. Define el recurso y guarda la configuración en un archivo YAML. Para este ejemplo, usamos my-agent-gateway-ingress.yaml.

    name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: CLIENT_TO_AGENT

    Reemplaza AGENT_GATEWAY_NAME por un nombre para el recurso de Agent Gateway.

  2. Ejecuta el siguiente comando para crear un recurso de Agent Gateway basado en la especificación YAML:

    gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
 --source="my-agent-gateway-ingress.yaml" \
 --location=LOCATION

    Reemplaza LOCATION por la ubicación en la que deseas crear el recurso de Agent Gateway. Por ejemplo, us-central1.

Después de crear una Agent Gateway, esta sirve como el punto de conexión principal para enrutar el tráfico a los agentes de tu proyecto y la región elegida.

A continuación, obtén información para implementar agentes y enrutar el tráfico a través de Agent Gateway.

Implementa agentes y enruta el tráfico a través de Agent Gateway

Para implementar un agente de Agent Runtime que enrute el tráfico a través de Agent Gateway, consulta Enruta el tráfico a través de Agent Gateway.

Para implementar un agente de Gemini Enterprise que enrute el tráfico a través de Agent Gateway, consulta Cómo enrutar el tráfico de Gemini Enterprise a través de Agent Gateway.

Codelabs

Para ver demostraciones de extremo a extremo sobre cómo configurar y usar Agent Gateway, consulta los siguientes codelabs:

¿Qué sigue?

Guía

Aprende a enrutar el tráfico de Agent Runtime a través de Agent Gateway para lograr una conectividad segura y administrada.

Guía

Obtén más información para delegar la autorización de Agent Gateway a IAP, Model Armor o tu propio servicio de autorización personalizado.

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.

Guía

Obtén más información para enrutar el tráfico de Gemini Enterprise a través de Agent Gateway.