Configurer la passerelle d'agent

Pour centraliser le contrôle des accès et sécuriser la connectivité dans vos workflows agentiques, vous pouvez configurer une ressource Agent Gateway pour gérer le trafic entrant ou sortant.

Avant de configurer une passerelle, consultez les concepts de base et les composants principaux dans la présentation d'Agent Gateway.

Autorisations requises

Les autorisations suivantes sont requises pour créer et gérer des Agent Gateways. Vous pouvez obtenir ces autorisations avec des rôles personnalisés ou en utilisant d'autres rôles prédéfinis.

Autorisations requises

  • 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

API requises

Activez les API minimales requises suivantes dans le projet Google Cloud où vous déployez Agent Gateway :

  • API Compute Engine (compute.googleapis.com) : fournit l'infrastructure réseau de base, les sous-réseaux, le routage et les rattachements de réseau Private Service Connect (PSC).
  • API de sécurité réseau (networksecurity.googleapis.com) : crée et applique des règles d'autorisation (authzPolicies) pour le trafic de la passerelle.
  • API Network Services (networkservices.googleapis.com) : gère les ressources Agent Gateway (agentGateways), les modèles de connectivité (agentConnectivityTemplates) et les extensions d'autorisation (authzExtensions).
  • API Identity and Access Management (iam.googleapis.com) : gère les comptes de service et les règles d'accès unifié (UAP) IAM pour les identités d'agent.
  • API Identity-Aware Proxy (iap.googleapis.com) : authentifie et vérifie le trafic des agents, des points de terminaison et des serveurs.
  • API Agent Registry (agentregistry.googleapis.com) : enregistre et gère les agents, les serveurs MCP et les points de terminaison d'outils régis par la passerelle.

Pour activer les API minimales requises, exécutez la commande suivante :

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

Remplacez PROJECT_ID par l'ID du projet dans lequel vous déployez Agent Gateway.

Selon les fonctionnalités, les outils d'observabilité et les environnements d'exécution d'agent que vous utilisez avec Agent Gateway, vous devrez peut-être également activer des API facultatives :

API facultatives par fonctionnalité

  • Connectivité VPC privée et TLS :
    • API Cloud DNS (dns.googleapis.com) : requise uniquement si vous configurez la connectivité VPC avec l'appairage Cloud DNS pour la résolution de domaine privé.
    • API Certificate Manager (certificatemanager.googleapis.com) : requise uniquement si vous configurez des ancres de confiance TLS personnalisées (TrustConfig) lors de la connexion à des backends privés qui utilisent des autorités de certification privées ou des certificats autosignés.
  • Sécurité de l'IA et filtrage de contenu :
    • API Model Armor (modelarmor.googleapis.com) : requise uniquement si vous activez les garde-fous Model Armor pour inspecter et filtrer l'injection de prompt, le contenu toxique et les données sensibles.
  • Observabilité et audit :
    • API Cloud Logging (logging.googleapis.com) : capture les journaux d'accès à la passerelle, les journaux d'audit de sécurité et les événements d'évaluation des règles de simulation.
    • API Cloud Monitoring (monitoring.googleapis.com) : suit l'état, la latence, le débit et les taux d'erreur de la passerelle, et configure les alertes opérationnelles.
    • API Observability (observability.googleapis.com) : fournit des tableaux de bord d'observabilité et d'exploitation unifiés pour l'activité des agents et des passerelles.
    • API Telemetry (telemetry.googleapis.com) : collecte et diffuse les données de télémétrie et les métriques de performances d'exécution sur les composants de la plate-forme.
    • API Cloud Trace (cloudtrace.googleapis.com) : fournit un traçage distribué pour inspecter les requêtes multisauts entre les agents et les backends.
  • Environnements d'exécution des agents et gouvernance sémantique :
    • API Agent Platform (aiplatform.googleapis.com) : requise dans les projets qui hébergent des agents Agent Runtime ou utilisent des règles de gouvernance sémantique.
    • API Discovery Engine (discoveryengine.googleapis.com) : requise dans les projets qui hébergent des applications et des agents Gemini Enterprise.
    • API Agent Identity (agentidentity.googleapis.com) : requise uniquement si vous gérez les identifiants sortants avec le gestionnaire d'authentification Agent Identity ou si vous affichez les fournisseurs d'authentification Agent Identity dans la console Google Cloud .

Planifier le déploiement de votre Agent Gateway

Utilisez cette section pour planifier le déploiement de votre Agent Gateway et comprendre les exigences de l'architecture de gouvernance. Vous pouvez revenir sur ces étapes lorsque vous enregistrez de nouvelles destinations, ajoutez des règles de contrôle des accès ou déployez d'autres agents.

Choisir votre mode de déploiement

Agent Gateway est compatible avec deux modes de déploiement :

  • Client vers agent (entrée) : sécurise les communications entre les clients et vos agents exécutés sur Google Cloud.
  • Agent vers n'importe où (sortie) : sécurise les communications entre vos agents et des cibles externes, des API publiques et des serveurs MCP.

Sélectionnez l'environnement d'exécution, le projet et la région de déploiement.

Agent Gateway gère le trafic des agents exécutés sur Gemini Enterprise et Runtime.

  • Agent Runtime : Agent Gateway est compatible avec les modes Agent vers n'importe où (sortie) et Client vers agent (entrée). En mode Agent-to-Anywhere, les agents peuvent se trouver dans le même projet que la passerelle ou dans un projet différent. En mode client-agent, les agents doivent se trouver dans le même projet que la passerelle. Dans les deux modes, les agents doivent se trouver dans la même région que la passerelle.

  • Gemini Enterprise : Agent Gateway n'est compatible qu'avec le mode Agent-to-Anywhere (sortie). Avec Gemini Enterprise, chaque passerelle régit les interactions agentiques uniquement dans le cadre du projet et de la région où elle est déployée.

Pour gérer les agents dans Gemini Enterprise et l'environnement d'exécution, vous pouvez utiliser une seule instance Agent Gateway. Vous pouvez également déployer des instances Agent Gateway indépendantes pour Gemini Enterprise et Runtime.

Exemples de modèles de déploiement

Voici quelques exemples de modèles de déploiement à prendre en compte :

Gouvernance interprojets pour les agents d'exécution

Dans ce modèle de déploiement, vous déployez une passerelle Agent Gateway d'agent vers n'importe quel emplacement (sortie) dans un projet de gouvernance dédié. Les agents d'exécution sont déployés dans des projets distincts de la même région que la passerelle et peuvent appartenir à n'importe quel dossier de votre organisation.

Pour configurer la gouvernance de sortie multiprojet, vous devez configurer les ressources suivantes :

Dans le projet de gouvernance central :

  • Créez l'Agent Gateway. Assurez-vous que la passerelle est associée à une instance Agent Registry.
  • Enregistrez les agents interprojets ainsi que tous les outils, serveurs ou points de terminaison auprès d'Agent Registry associé à la passerelle.
  • Accordez des autorisations IAM multiprojets à l'agent de service d'exécution de chaque projet où les agents sont basés, afin que les agents de ces projets puissent se lier à la passerelle du projet de gouvernance. Pour obtenir un exemple, consultez Acheminer le trafic d'exécution via Agent Gateway.
  • Configurez des règles IAP, des limites d'accès des principaux et des Workload Identity compatibles avec SPIFFE pour gérer et sécuriser le trafic sortant vers les points de terminaison autorisés.
  • Créez les modèles Model Armor que vous souhaitez utiliser pour la sortie.
  • Si vous souhaitez effectuer une sortie vers un réseau VPC, vous pouvez créer le rattachement de réseau PSC, les ancres de confiance TLS personnalisées (tlsConfig) pour les autorités de certification privées et la configuration d'appairage DNS dans le projet de gouvernance.

Dans les projets Agent Runtime :

  • Déployez les agents et associez-les à la passerelle centrale dans le projet de gouvernance.

Notez que la gouvernance multiprojet n'est compatible qu'avec l'environnement d'exécution avec des passerelles Agent-to-Anywhere (sortie). Gemini Enterprise n'est pas compatible.

Gouvernance partagée pour les agents Gemini Enterprise et Runtime

Dans ce modèle de déploiement, tout le trafic provenant des applications Gemini Enterprise et des agents d'exécution est acheminé via une seule passerelle d'agent.

Voici un exemple de déploiement :

  • L'application Gemini Enterprise est déployée en tant que déploiement global.
  • Les agents d'exécution sont déployés dans une seule région (us-central1) qui correspond au déploiement Gemini Enterprise.
  • L'Agent Gateway est déployé dans la même région (us-central1).
  • L'instance Agent Registry us-central1 est associée à Agent Gateway. Vous devez enregistrer vos agents et vos destinations dans cette instance Agent Registry.
Gouvernance indépendante pour les agents Gemini Enterprise et Runtime

Dans ce modèle de déploiement, chaque région dispose d'une passerelle d'agent dédiée pour surveiller et contrôler le trafic des agents, ce qui garantit l'isolation régionale :

  • L'application Gemini Enterprise est déployée dans global, us ou eu.
  • Les agents d'exécution sont déployés dans chaque région où ils sont nécessaires.
  • Les instances Agent Gateway sont déployées dans chaque région où se trouvent les agents et les applications.
  • Vous devez enregistrer vos agents et vos destinations dans l'instance Agent Registry régionale associée à chaque passerelle.

Configurer l'identité de l'agent

Chaque agent géré par Agent Gateway nécessite sa propre identité d'agent unique (un ID SPIFFE). Étant donné que les règles d'accès IAM dépendent de cette Workload Identity, le trafic provenant d'agents non identifiés est bloqué par défaut.

Vous pouvez provisionner une identité d'agent lorsque vous déployez un agent dans l'environnement d'exécution ou l'attribuer à des charges de travail d'agent existantes. Pour obtenir des instructions détaillées, consultez Utiliser Agent Identity avec l'environnement d'exécution.

Enregistrer vos agents et vos ressources de destination

Pour permettre une communication sécurisée, vous devez identifier votre instance de registre d'agents et enregistrer les ressources que votre passerelle gère.

  1. Identifiez l'instance régionale du registre d'agents à utiliser. Chaque Agent Gateway est associé à un seul registre régional (//agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION) dans le même projet et la même région que ceux où la passerelle est déployée :

    • Agent Runtime : référencez le registre régional dans le même projet et la même région que ceux où Agent Gateway est déployé. Enregistrez les agents interprojets dans le registre régional du projet de gouvernance central qui héberge la passerelle.
    • Gemini Enterprise : référencez le registre régional dans le même projet et la même région que l'Agent Gateway (us-central1 pour les applications global et us, ou europe-west1 pour les applications eu). Pour en savoir plus, consultez Planifier vos mappages d'emplacement et de registre d'agents.

    Assurez-vous que l'instance de registre régional que vous associez à votre Agent Gateway est celle où vos agents, points de terminaison et serveurs MCP sont enregistrés.

  2. Enregistrez vos agents auprès d'Agent Registry. Si vous n'avez pas encore créé l'agent, vous devrez effectuer cette étape ultérieurement. Pour obtenir des instructions, consultez Enregistrer des agents.

  3. Recommandé : Identifiez et enregistrez tous les outils, serveurs MCP et points de terminaison d'API que vos agents appelleront (y compris les API de plate-forme essentielles). L'accès de l'agent aux destinations nécessite toujours une stratégie d'accès IAM accordant l'autorisation iap.resources.egressViaIAP à l'identité de l'agent. Nous vous recommandons d'enregistrer les ressources dans le registre d'agents afin de pouvoir appliquer des règles précises par ressource et des contrôles au niveau des outils. Pour les destinations qui ne sont pas enregistrées, vous devez accorder cette autorisation à l'agent en configurant des règles pour les points de terminaison non enregistrés.

    Les destinations d'un projet différent de celui de la passerelle doivent être enregistrées auprès du registre d'agents dans le projet de la passerelle. Ces destinations ne sont valides que pour les agents d'exécution en mode Agent-to-Anywhere.

    Pour obtenir des instructions, consultez les guides suivants :

Configurer des stratégies de contrôle des accès

Chaque Agent Gateway nécessite une stratégie d'autorisation associée.

IAM (mode Agent vers n'importe quelle destination uniquement)

Configurez une stratégie IAM qui attribue l'autorisation iap.resources.egressViaIAP au principal de l'identité de votre agent pour chacune des ressources de destination que vous avez enregistrées dans Agent Registry.

Par défaut, Agent Gateway bloque tout le trafic, sauf si une stratégie d'accès IAM autorise explicitement l'accès de l'agent aux ressources de destination en accordant l'autorisation iap.resources.egressViaIAP à l'identité de l'agent.

Il est recommandé d'enregistrer les destinations dans Agent Registry, car cela vous permet de limiter le champ d'application des règles à des ressources spécifiques et d'appliquer des contrôles d'outils précis. Si les destinations ne sont pas enregistrées dans le registre d'agents, vous devez accorder l'autorisation iap.resources.egressViaIAP à l'agent en configurant une règle pour les points de terminaison non enregistrés.

Assurez-vous que toute liaison à l'échelle du registre correspond à l'instance Agent Registry régionale configurée pour votre Agent Gateway.

Pour obtenir des instructions, consultez Créer des règles d'agent IAM.

Pour valider votre configuration sans bloquer le trafic, nous vous recommandons de déployer initialement IAP en mode dry run.

Model Armor

(Facultatif) Si votre déploiement nécessite une protection contre les attaques par injection de prompt, les jailbreaks, les contenus toxiques ou les fuites de données sensibles, vous devez planifier l'intégration de votre garde-fou Model Armor et créer des modèles avec les filtres de sécurité dont vous avez besoin.

Pour en savoir plus, consultez les documents suivants :

Règles de gouvernance sémantique

(Facultatif) Vous pouvez choisir d'ajouter des contrôles contextuels basés sur le langage naturel à vos agents pour les protéger contre les combinaisons d'outils toxiques.

Nous vous recommandons de commencer par déployer les règles de gouvernance sémantique en mode dry run afin de pouvoir valider votre configuration sans bloquer le trafic. Pour en savoir plus, consultez Configurer des règles de gouvernance sémantique.

Moteurs d'autorisation personnalisés

(Facultatif) Si vous souhaitez déléguer l'autorisation à des moteurs d'autorisation personnalisés ou à des systèmes tiers à l'aide des extensions de service, vous devez vous assurer que les moteurs d'autorisation personnalisés sont disponibles lors du déploiement de la passerelle.

Model Armor, les règles de gouvernance sémantique et tout autre moteur d'autorisation personnalisé peuvent être activés lors de la configuration initiale d'Agent Gateway ou associés après le déploiement en tant que mise à jour incrémentielle des règles de sécurité.

Configurer Agent Gateway en mode Agent vers n'importe quelle destination (sortie)

Lorsque vous configurez Agent Gateway en mode Agent-to-Anywhere (sortie), vous pouvez configurer la manière dont le trafic géré atteint les points de terminaison et les outils de destination. En fonction de vos exigences de mise en réseau et de sécurité, choisissez l'une des options de déploiement suivantes :

  • Sortie Internet : la passerelle achemine de manière sécurisée le trafic des agents vers les points de terminaison et les API accessibles publiquement sur Internet. Pour configurer une Agent Gateway avec une sortie Internet, vous pouvez suivre les instructions de cette page.

  • Sortie du réseau VPC : la passerelle achemine le trafic de l'agent de manière privée vers un réseau VPC à l'aide de rattachements de réseau Private Service Connect. Vous pouvez choisir d'acheminer tout le trafic via le réseau VPC (ALL_TRAFFIC) ou uniquement le trafic destiné aux plages d'adresses IP privées (PRIVATE_RANGES_ONLY).

    Pour configurer une Agent Gateway avec une sortie VPC, vous devez suivre les instructions de la section Configurer la connectivité VPC pour Agent Gateway.

Pour créer une ressource Agent Gateway pour les communications Agent-to-Anywhere, procédez comme suit :

Console Google Cloud

  1. Dans la console Google Cloud , accédez à la page Agent Gateway.

    Accéder à la page "Passerelles"

  2. Cliquez sur Ajouter une passerelle.
  3. Saisissez un nom.
  4. Dans la liste Région, sélectionnez une région.
  5. Pour Mode de déploiement, vérifiez que Géré par Google est sélectionné.
  6. Pour Registres d'agents, sélectionnez le registre régional qui correspond à la région de votre Agent Gateway. Pour obtenir des conseils, consultez Planifier votre déploiement d'Agent Gateway.
  7. Dans la liste Chemin d'accès contrôlé, sélectionnez Agent vers n'importe où (sortie de l'agent).

  8. Dans la section Autorisation d'accès, choisissez comment le trafic est géré par IAP :

    • Pour déployer la passerelle en mode dry run, où la passerelle autorise tout le trafic et ne génère que des journaux d'audit, sélectionnez Audit uniquement (ce qui définit iamEnforcementMode: "DRY_RUN" sur l'extension d'autorisation). Vos stratégies IAM ne sont pas appliquées par IAP en mode dry run. Une fois que vous êtes sûr de vous, vous pouvez désactiver le mode dry run pour appliquer les stratégies IAM.
    • Pour bloquer les requêtes qui ne disposent pas d'une stratégie IAM Allow explicite, sélectionnez Appliquer les stratégies (ce qui écrit iamEnforcementMode: "ENFORCED" sur l'extension d'autorisation lors de la création d'une passerelle, ou supprime iamEnforcementMode lors de la mise à jour d'une passerelle existante). Cette option est recommandée pour les environnements de production.
    • Pour Modèle de règle, sélectionnez Règle d'accès unifiée.

  9. Facultatif : Dans la section Sécurité de l'IA, configurez des paramètres de sécurité supplémentaires :

    1. Pour protéger les interactions des modèles d'IA avec Model Armor, activez l'option Activer Model Armor.
    2. Dans la liste, sélectionnez un modèle qui s'applique aux requêtes entrantes vers la passerelle.

    3. Pour utiliser un autre modèle pour les réponses, décochez l'option Utiliser le même modèle pour les requêtes et les réponses, puis sélectionnez un modèle dans la liste.

  10. Cliquez sur Ajouter une passerelle.

gcloud

Vous définissez les Agent Gateways de manière déclarative à l'aide de YAML.

  1. Définissez la ressource et enregistrez la configuration dans un fichier YAML. Dans cet exemple, nous utilisons my-agent-gateway-egress.yaml.

    name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - AGENT_REGISTRY_PATH

    Remplacez les éléments suivants :

    • AGENT_GATEWAY_NAME : nom de la ressource Agent Gateway.
    • AGENT_REGISTRY_PATH : chemin d'accès à l'instance Agent Registry régionale dans le même projet et la même région que la passerelle, au format //agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION. Pour obtenir des conseils, consultez Planifier votre déploiement d'Agent Gateway.

  2. Exécutez la commande suivante pour créer une ressource Agent Gateway basée sur la spécification YAML :

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

    Remplacez LOCATION par l'emplacement où vous souhaitez créer la ressource Agent Gateway. Exemple : us-central1.

    Notez que pour Gemini Enterprise, vous devez déployer Agent Gateway dans une région qui correspond à l'emplacement de votre application. Pour connaître les mappages d'emplacement requis, consultez Router le trafic Gemini Enterprise via Agent Gateway.

  3. Créez une règle d'autorisation pour appliquer des règles de contrôle des accès et de gouvernance centralisées au trafic transitant par Agent Gateway. Les étapes suivantes vous expliquent comment configurer une règle d'autorisation qui utilise IAP.

    1. Configurez une extension d'autorisation qui pointe vers IAP. Définissez l'extension dans un fichier YAML, tel que iap-request-authz-extension.yaml. Utilisez les exemples de valeurs fournis :

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

      Si vous souhaitez déployer l'extension en mode dry run audit-only pour tester la stratégie d'autorisation sans l'appliquer, vous pouvez spécifier le champ iamEnforcementMode dans le bloc metadata. Cela vous permet de vérifier votre stratégie et de minimiser le risque de perturbation du trafic en raison d'erreurs de configuration :

      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

      Supprimez le champ iamEnforcementMode: "DRY_RUN" du bloc metadata lorsque vous êtes prêt à appliquer les règles. Pour savoir comment auditer les cas de non-respect des règles en mode dry run dans les contrôles avant d'activer l'application, consultez Auditer les cas de non-respect des règles en mode dry run dans les contrôles.

    2. Importez le fichier de configuration YAML dans une extension d'autorisation.

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

      Remplacez AUTHORIZATION_EXTENSION_NAME par le nom de l'extension d'autorisation (par exemple, my-iap-request-authz-ext).

    3. Définissez une règle d'autorisation dans un fichier YAML, tel que iap-request-authz-policy.yaml, pour associer l'extension à votre passerelle :

      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

      Remplacez les éléments suivants :

      • AUTHORIZATION_POLICY_NAME : nom de la stratégie d'autorisation, par exemple my-iap-request-authz-policy
      • PROJECT_ID : ID du projet

    4. Importez le fichier de configuration YAML dans une règle d'autorisation.

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

  4. Facultatif : Si vous souhaitez configurer des garde-fous Model Armor pour protéger votre déploiement contre les attaques par injection de prompt et les fuites de données sensibles, consultez Déléguer l'autorisation à Model Armor.

Terraform

Pour provisionner de manière déclarative une passerelle Agent Gateway Agent-to-Anywhere (sortie) ainsi que l'extension d'autorisation IAP et la règle associées dans un projet de gouvernance centralisé à l'aide du fournisseur google :

  1. Créez la ressource google_network_services_agent_gateway et associez votre instance Agent Registry régionale :

    resource "google_network_services_agent_gateway" "egress_gateway" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "AGENT_GATEWAY_NAME"
  protocols = ["MCP"]

  google_managed {
    governed_access_path = "AGENT_TO_ANYWHERE"
  }

  registries = [
    "//agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION",
  ]
}

  2. Configurez l'google_network_services_authz_extension IAP et associez-le à la passerelle avec un google_network_security_authz_policy :

    resource "google_network_services_authz_extension" "iap_request_authz_ext" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "my-iap-request-authz-ext"
  service   = "iap.googleapis.com"
  timeout   = "1s"
  fail_open = false

  metadata = {
    iapPolicyVersion = "V2"
    # Uncomment the following line to deploy in dry-run (audit-only) mode:
    # iamEnforcementMode = "DRY_RUN"
  }
}

resource "google_network_security_authz_policy" "iap_request_authz_policy" {
  project        = "PROJECT_ID"
  location       = "LOCATION"
  name           = "my-iap-request-authz-policy"
  policy_profile = "REQUEST_AUTHZ"
  action         = "CUSTOM"

  target {
    resources = [
      google_network_services_agent_gateway.egress_gateway.id
    ]
  }

  custom_provider {
    authz_extension {
      resources = [
        google_network_services_authz_extension.iap_request_authz_ext.id
      ]
    }
  }
}

  1. Une fois qu'un Agent Gateway a été créé, il sert de point de connexion principal pour acheminer le trafic des agents dans votre projet et la région choisie. Vous pouvez désormais utiliser ce point de terminaison pour établir des canaux de communication sécurisés, chiffrés et authentifiés entre les agents et leurs destinations (outils, autres agents ou autres points de terminaison).

    Consultez à nouveau la section Planifier le déploiement d'Agent Gateway sur cette page et assurez-vous que vos agents sont enregistrés auprès d'Agent Registry et que votre agent dispose de l'autorisation iap.resources.egressViaIAP pour toutes les destinations auxquelles il tente de se connecter. Si vous rencontrez des problèmes de connectivité, consultez Résoudre les problèmes de connectivité d'Agent Gateway.

Découvrez ensuite comment déployer des agents et acheminer le trafic via Agent Gateway.

Configurer Agent Gateway en mode client vers agent (entrée)

Cette section explique comment configurer une Agent Gateway pour les communications client-agent.

Pour créer une ressource Agent Gateway, procédez comme suit :

Console Google Cloud

  1. Dans la console Google Cloud , accédez à la page Agent Gateway.

    Accéder à la page "Passerelles"

  2. Cliquez sur Ajouter une passerelle.
  3. Saisissez un nom.
  4. Dans la liste Région, sélectionnez une région.
  5. Pour Mode de déploiement, vérifiez que Géré par Google est sélectionné.
  6. Laissez le paramètre Registre de l'agent tel quel. Le registre n'est pas utilisé pour l'entrée.
  7. Dans la liste Chemin d'accès contrôlé, sélectionnez Client vers agent (entrée).

  8. Facultatif : dans la section AI Security, configurez des mesures de sécurité supplémentaires :

    1. Pour protéger les interactions des modèles d'IA avec Model Armor, activez l'option Activer Model Armor.

    2. Dans la liste, sélectionnez un modèle qui s'applique aux requêtes entrantes vers la passerelle.

    3. Pour utiliser un autre modèle pour les réponses, décochez l'option Utiliser le même modèle pour les requêtes et les réponses, puis sélectionnez un modèle dans la liste.

  9. Cliquez sur Ajouter une passerelle.

gcloud

Vous définissez les Agent Gateways de manière déclarative à l'aide de YAML.

  1. Définissez la ressource et enregistrez la configuration dans un fichier YAML. Dans cet exemple, nous utilisons my-agent-gateway-ingress.yaml.

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

    Remplacez AGENT_GATEWAY_NAME par le nom de la ressource Agent Gateway.

  2. Exécutez la commande suivante pour créer une ressource Agent Gateway basée sur la spécification YAML :

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

    Remplacez LOCATION par l'emplacement où vous souhaitez créer la ressource Agent Gateway. Exemple : us-central1.

Terraform

Pour provisionner une ressource Agent Gateway client vers agent (entrée) de manière déclarative à l'aide du fournisseur google :

resource "google_network_services_agent_gateway" "ingress_gateway" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "AGENT_GATEWAY_NAME"
  protocols = ["MCP"]

  google_managed {
    governed_access_path = "CLIENT_TO_AGENT"
  }
}

Une fois qu'une passerelle d'agent a été créée, elle sert de point de connexion principal pour acheminer le trafic vers les agents de votre projet et de la région choisie.

Ensuite, découvrez comment déployer des agents et acheminer le trafic via Agent Gateway.

Déployer des agents et acheminer le trafic via Agent Gateway

Pour déployer un agent Agent Runtime qui achemine le trafic via Agent Gateway, consultez Acheminer le trafic via Agent Gateway.

Pour déployer un agent Gemini Enterprise qui achemine le trafic via Agent Gateway, consultez Acheminer le trafic Gemini Enterprise via Agent Gateway.

Ateliers de programmation

Pour obtenir des démonstrations de bout en bout sur la configuration et l'utilisation d'Agent Gateway, consultez les ateliers de programmation suivants :

Étapes suivantes

Guide

Découvrez comment acheminer le trafic Agent Runtime via Agent Gateway pour une connectivité sécurisée et régie.

Guide

Découvrez comment déléguer l'autorisation pour Agent Gateway à IAP, Model Armor ou à votre propre service d'autorisation personnalisé.

Guide

Découvrez comment afficher, mettre à jour, dissocier et supprimer des ressources Agent Gateway.

Guide

Découvrez comment surveiller Agent Gateway.

Dépannage

Découvrez comment résoudre les problèmes de connectivité d'Agent Gateway.

Guide

Découvrez comment router le trafic Gemini Enterprise via Agent Gateway.