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 afin de 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 à l'aide de rôles personnalisés ou 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 Cloud de Confiance 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.

En fonction des fonctionnalités, des outils d'observabilité et des 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 Vertex AI (aiplatform.googleapis.com) : requise dans les projets qui hébergent des agents Agent Runtime ou qui 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 Cloud de Confiance .

Planifier le déploiement de votre Agent Gateway

Utilisez cette section pour planifier le déploiement de votre Agent Gateway et comprendre les exigences d'architecture de gouvernance. Vous pouvez revenir à 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 Cloud de Confiance.
  • 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 dans lesquels 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 de type Agent vers n'importe où (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 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 multiprojets 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).
  • Les instances Agent Registry global et us-central1 peuvent être associées à Agent Gateway. Les agents et les destinations doivent être enregistrés auprès des instances Agent Registry associées à la passerelle.
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 en tant que déploiement mondial ou multirégional (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 destinations dans les instances Agent Registry associées à 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 activer la communication sécurisée, vous devez identifier votre instance Agent Registry et enregistrer les ressources que votre passerelle gérera.

  1. Identifiez les instances Agent Registry que vous allez utiliser. Une Agent Gateway peut être associée à deux registres au maximum (un registre mondial et un registre régional ou multirégional) :

    • Les agents Agent Runtime sont des ressources régionales et sont généralement enregistrés dans des registres régionaux correspondant à leur région de déploiement. Notez que les agents multiprojets doivent être enregistrés dans le registre associé au projet de gouvernance centralisé où l'Agent Gateway est déployé.
    • Les agents Gemini Enterprise sont des ressources mondiales ou multirégionales, et sont enregistrés dans des registres mondiaux ou multirégionaux (tels que global, us ou eu).

    Assurez-vous que les instances de registre que vous associez à votre Agent Gateway sont celles où vos agents, points de terminaison et serveurs 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 règle 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 règle 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.

Nous vous recommandons 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 Agent Registry, vous devez accorder l'autorisation iap.resources.egressViaIAP à l'agent en configurant une règle pour les points de terminaison non enregistrés.

Étant donné que les registres peuvent être mondiaux, multirégionaux ou régionaux, assurez-vous que toute liaison à l'échelle du registre correspond à l'instance (ou aux instances) de registre 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.

Suivez les étapes ci-dessous pour créer une ressource Agent Gateway pour les communications Agent-to-Anywhere.

Console Cloud de Confiance

  1. Dans la console Cloud de Confiance , 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 l'option Géré par Google est sélectionnée.
  6. Pour Registres d'agents, sélectionnez au moins un registre dans la liste. Si vous souhaitez sélectionner deux registres, l'un doit être un registre mondial et l'autre peut être un registre régional ou multirégional.Pour savoir quel registre choisir pour votre déploiement, consultez Planifier votre déploiement 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. 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 règle IAM Allow explicite, sélectionnez Appliquer les règles. Cette option est recommandée pour les environnements de production.
    • Pour Modèle de stratégie, 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. Sélectionnez dans la liste 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_URI_1
  - OPTIONAL_AGENT_REGISTRY_URI_2

    Remplacez les éléments suivants :

    • AGENT_GATEWAY_NAME : nom de la ressource Agent Gateway.

    • AGENT_REGISTRY_URI_1 et OPTIONAL_AGENT_REGISTRY_URI_2 : chemins d'accès aux instances Agent Registry à associer à la passerelle. Vous pouvez configurer jusqu'à deux registres pour une passerelle d'agent. Lorsque vous configurez deux registres, l'un doit être un registre mondial et l'autre peut être un registre régional ou multirégional. Pour savoir quel registre choisir pour votre déploiement, consultez Planifier votre déploiement Agent Gateway. Les chemins d'accès au registre doivent être formatés comme suit :

      • Registres régionaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
      • Registres mondiaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/global
      • Registres multirégionaux : //agentregistry.googleapis.com/projects/PROJECT_ID/locations/MULTI_REGION

  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 à votre configuration multirégionale. Pour connaître les mappages d'emplacements compatibles, consultez Acheminer le trafic Gemini Enterprise via Agent Gateway.

  3. Créez une stratégie d'autorisation pour appliquer des stratégies 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 stratégie 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.

    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 vos instances Agent Registry régionales ou globales :

    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.

Ensuite, découvrez 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 Cloud de Confiance

  1. Dans la console Cloud de Confiance , 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 l'option Géré par Google est sélectionnée.
  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 géré, sélectionnez Client vers agent (entrée).

  8. 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. Sélectionnez dans la liste 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.

Découvrez ensuite 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 surveiller Agent Gateway.

Dépannage

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

Guide

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