Résoudre les problèmes de connectivité de l'Agent Gateway

Ce guide vous aide à déboguer et à résoudre les problèmes de connectivité avec la plate-forme Gemini Enterprise Agent, en particulier lorsque vous utilisez Agent Gateway, l'identité de l'agent, les stratégies Identity and Access Management (IAM) et l'autorisation déléguée avec les extensions de service.

Résoudre les problèmes à l'aide de la skill de dépannage Agent Platform

Pour diagnostiquer de manière interactive les problèmes de connectivité, d'autorisation et de démarrage avec un assistant de codage IA, vous pouvez installer la compétence agent-platform-troubleshooting à partir du dépôt de compétences d'agent Cloud de Confiance by S3NS .

Cette compétence dote les agents IA de playbooks de diagnostic, de filtres de journaux et d'étapes de résolution spécifiques au domaine sur l'ensemble de la pile Agent Platform, y compris :

  • Refus de sortie de l'Agent Gateway : diagnostic des erreurs 403 Forbidden interceptées par la passerelle et vérification des décisions d'autorisation IAP.
  • Échecs de démarrage de l'Agent Runtime : identification des rôles manquants (tels que roles/browser ou resourcemanager.projects.get) et des exceptions d'amorçage.
  • Problèmes de destination du registre d'agents : vérification des entrées de service, des interfaces de point de terminaison et des configurations d'API Google consolidées.
  • Stratégies d'accès IAM : validation des liaisons de règles d'accès unifiées (RAU), des expressions de condition et de la portée de la limite d'accès des principaux (LAP).
  • Confiance des conteneurs : diagnostic des erreurs de certificat TLS et de handshake pour les conteneurs personnalisés (BYOC) ou les autorités de certification privées.

Pour installer la compétence dans votre environnement d'agent, exécutez la commande suivante :

npx skills add https://github.com/google/skills --skill agent-platform-troubleshooting

Flux de requête de sortie

Agent Platform adopte une règle default-deny pour tout le trafic sortant. Pour qu'un agent puisse se connecter à des ressources externes, vous devez autoriser explicitement l'accès à chaque couche d'identité et de réseau. Lorsque Agent Gateway est activé, la passerelle intercepte toutes les requêtes de l'agent et applique les règles configurées.

Pour qu'une demande aboutisse, elle doit remplir toutes les conditions suivantes :

  • Stratégie d'accès IAM : l'identité de l'agent attribuée à l'agent doit disposer de l'autorisation iap.resources.egressViaIAP sur la ressource de destination, directement ou via un ensemble de comptes principaux. Pour en savoir plus, consultez Créer des règles d'agent IAM. Découvrez comment résoudre les problèmes liés aux stratégies IAP.
  • Registre d'agents : il est recommandé d'enregistrer les destinations dans le registre d'agents pour appliquer des règles d'accès précises par ressource et des contrôles au niveau des outils. Si l'agent tente d'accéder à une destination non enregistrée, vous devez accorder l'autorisation iap.resources.egressViaIAP à l'identité de l'agent en configurant une règle pour un point de terminaison non enregistré.
  • Agent Gateway : la passerelle doit être associée à une règle d'autorisation qui la cible explicitement. Par défaut, la passerelle utilise IAP et Model Armor pour sécuriser les requêtes.
  • Autorisation déléguée avec les extensions de service : vous pouvez déléguer les décisions d'autorisation à un moteur d'autorisation personnalisé à l'aide des extensions de service. En fonction de la règle d'autorisation configurée, un ou plusieurs de ces moteurs d'autorisation autoriseront ou refuseront la requête.

Problèmes courants

Consultez ces problèmes courants et leurs solutions lorsque vous dépannez Agent Gateway.

Erreurs lors du démarrage d'Agent Runtime

Si vos instances Agent Runtime ne parviennent pas à démarrer ni à se déployer, cela peut signifier que l'IAP bloque le trafic interne ou que votre agent ne dispose pas des rôles de base dont il a besoin pour s'initialiser.

  1. Vérifier qu'IAP ne bloque pas les appels aux services internes

    Symptôme : erreurs 403 Forbidden au démarrage.

    Cause : Agent Gateway utilise une règle de refus par défaut pour tout le trafic. Par conséquent, lorsque IAP est en mode d'application, il bloque les appels, même vers des services internes (tels que aiplatform ou logging), sauf s'ils sont enregistrés et que l'agent dispose des autorisations IAM requises.

    Solution : Passez temporairement les achats via l'application en mode dry run pour voir quelles connexions échouent sans bloquer le démarrage, ou interrogez Cloud Logging pour identifier les noms d'hôte bloqués exacts. Après avoir identifié les noms d'hôte des services cibles, enregistrez-les dans Agent Registry et accordez l'autorisation iap.resources.egressViaIAP à l'agent.

    Pour trouver des noms d'hôte bloqués spécifiques à l'aide de Cloud Logging, exécutez la requête suivante dans l'explorateur de journaux :

    resource.type="networkservices.googleapis.com/Gateway"
resource.labels.gateway_type="SECURE_WEB_GATEWAY"
httpRequest.status=403

    Examinez les champs httpRequest.requestUrl ou jsonPayload.authzPolicyInfo dans les résultats pour trouver les noms d'hôte de destination.

    Voici quelques services internes courants qui peuvent nécessiter un enregistrement au démarrage :

    • Agent Platform (Moteur de raisonnement et Sessions) : https://REGION-aiplatform.mtls.googleapis.com
    • Resource Manager : https://cloudresourcemanager.mtls.googleapis.com et https://cloudresourcemanager.mtls.googleapis.com/
    • Google Cloud Observability (si activé) : https://telemetry.mtls.googleapis.com/
    • Cloud Logging (si activé) : https://logging.googleapis.com/
    • Cloud Monitoring : https://monitoring.googleapis.com/ et https://monitoring.mtls.googleapis.com/
    • Cloud Trace : https://cloudtrace.googleapis.com/ et https://cloudtrace.mtls.googleapis.com/
    • Secret Manager : https://secretmanager.googleapis.com/ et https://secretmanager.mtls.googleapis.com/

  2. Vérifier que l'identité de l'agent dispose des rôles de base requis

    Symptômes : dans les journaux aiplatform.googleapis.com/reasoning_engine_stderr, des erreurs telles que google.api_core.exceptions.Unknown: None ou Failed to convert project number to project ID s'affichent. L'erreur s'affiche lors du démarrage du moteur de raisonnement.

    Cause. L'identité de l'agent ne dispose pas de l'autorisation resourcemanager.projects.get requise pour résoudre le nom du projet lors de l'initialisation.

    Corriger. Assurez-vous que l'identité de l'agent (ou son ensemble de comptes principaux) dispose des autorisations requises pour lire sa propre configuration d'exécution. Les rôles suivants sont requis :

    • roles/aiplatform.agentDefaultAccess : rôle d'agent par défaut.
    • roles/aiplatform.user : requis pour exécuter l'agent.
    • roles/agentregistry.viewer : obligatoire pour afficher les ressources enregistrées.
    • roles/logging.logWriter et roles/monitoring.metricWriter : requis pour l'observabilité.
    • roles/browser : obligatoire pour exécuter resourcemanager.projects.get lors de l'initialisation du SDK.

    Pour vérifier les rôles attribués à l'identité de l'agent, exécutez la commande suivante :

    gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \
--filter="bindings.members:AGENT_IDENTITY_PRINCIPAL"

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Cloud de Confiance .
    • AGENT_IDENTITY_PRINCIPAL : principal de l'identité de l'agent. Utilise le format suivant : principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

    Pour savoir comment attribuer des rôles, consultez Utiliser Agent Identity avec Agent Runtime.

403 Forbidden erreurs

Si vous rencontrez une erreur 403 Forbidden, vérifiez qu'elle est liée à la sortie Agent Gateway. Voici un exemple de message d'erreur de sortie :

{"code": 403, "message": "403 Forbidden. {'message': 'Egress request is not authorized.', 'status': 'Forbidden'}"}

Interrogez les journaux de l'agent dans Logging pour trouver les appels défaillants spécifiques :

resource.type="aiplatform.googleapis.com/ReasoningEngine"
resource.labels.location="LOCATION"
resource.labels.reasoning_engine_id="AGENT_ID"
textPayload:"403"

Remplacez les éléments suivants :

  • LOCATION : région dans laquelle l'agent est déployé, par exemple us-central1.
  • AGENT_ID : ID de l'agent (moteur de raisonnement).

Recherchez le message Egress request is not authorized dans le textPayload de l'entrée de journal. Si l'erreur 403 contient un texte différent, il est possible que le service de destination rejette l'appel directement, plutôt qu'Agent Gateway.

Vous pouvez également afficher les journaux de trafic sortant, y compris les refus 403, à l'aide du tableau de bord d'observabilité intégré.

Échec de la connexion aux destinations CA privées ou auto-signées

  • Symptôme : l'agent ne parvient pas à se connecter aux destinations qui présentent des certificats autosignés ou émis par une autorité de certification privée.
  • Cause : Par défaut, Agent Gateway n'approuve que les certificats émis par des autorités de certification publiques. La connexion à des destinations qui utilisent des autorités de certification privées ou des certificats autosignés nécessite une configuration supplémentaire.
  • Solution : Pour vous connecter à des destinations à l'aide d'autorités de certification privées ou de certificats autosignés, vous devez configurer des ancres de confiance TLS personnalisées à l'aide du paramètre tlsConfig dans un modèle de connectivité de l'agent.

L'agent déployé avec un conteneur personnalisé (BYOC) ne parvient pas à se connecter à la passerelle d'agent

  • Symptôme : l'agent BYOC ne parvient pas à établir de connexions lorsqu'il est routé via Agent Gateway. Les journaux peuvent afficher des erreurs de handshake TLS ou de validation de certificat.
  • Cause : Le conteneur personnalisé de l'agent ne fait pas confiance à l'autorité de certification de l'Agent Gateway.
  • Correctif : assurez-vous d'avoir ajouté le certificat racine de l'Agent Gateway au magasin d'autorité de certification de votre conteneur. Consultez Configurer des agents de conteneur personnalisé (BYOC) pour Agent Gateway.

La liaison de stratégie échoue ou imite un refus de gouvernance

  • Symptôme : Les configurations de liaison de règles échouent, vous êtes invité de manière interactive à saisir un etag lors de la liaison de règles, ou les requêtes échouent avec une erreur de refus de gouvernance faux (par exemple, "destination non enregistrée correctement rejetée").
  • Cause : L'API Identity-Aware Proxy (iap.googleapis.com) est désactivée dans votre projet.
  • Solution : activez l'API Identity-Aware Proxy.

Échecs lors de la gestion d'Agent Gateway avec la fédération des identités des employés

Vous pouvez rencontrer ce problème si vous gérez Agent Gateway dans la consoleCloud de Confiance ou si vous utilisez la gcloud CLI lorsque vous êtes authentifié avec la fédération d'identité de personnel (WIF).

La console affiche des erreurs de chargement ou de création génériques, telles que les suivantes :

  • "Une erreur s'est produite lors du chargement..."
  • "Le serveur n'a pas pu traiter votre requête"
  • "Failed to create agent gateway" (Échec de la création de la passerelle d'agent)
  • "Échec du chargement"

De plus, les commandes gcloud (telles que gcloud network-services agent-gateways import) peuvent renvoyer une erreur interne, telle que error 13: an internal error has occurred.

Pour résoudre ce problème, authentifiez-vous avec un compte Google standard géré via Cloud Identity ou Google Workspace et disposant des autorisations requises, comme roles/networkservices.admin.

La compatibilité des identités fédérées est limitée dans les services Agent Platform Governance et Gateway en version Preview. Attribuer des rôles IAM plus larges à un compte principal fédéré ne résout pas le problème.

Workflow de débogage

Si l'une des conditions décrites dans la section Flux de demande de sortie est manquante, vos demandes peuvent être bloquées.

Examiner la décision IAP

Pour limiter votre recherche de journaux aux décisions de sortie IAP, exécutez la requête suivante dans Logging :

protoPayload.serviceName="iap.googleapis.com"
protoPayload.authorizationInfo.permission="iap.resources.egressViaIAP"
protoPayload.metadata.mcp_attributes.base_protocol_method="true"

Si vous ne voyez aucune entrée de journal IAP correspondante, il est possible que la passerelle ait refusé la requête avant qu'IAP ne l'évalue. Passez à l'étape suivante.

Si vous trouvez une entrée de journal correspondante, examinez les champs suivants :

  • protoPayload.authorizationInfo[].granted : indique si la requête a été autorisée (true) ou refusée (false).
  • protoPayload.authenticationInfo.principalSubject : ID SPIFFE ou identité principal://... de l'appelant. Vérifiez que cela correspond à l'identité de votre agent.
  • protoPayload.authorizationInfo[].resource : ressource de destination enregistrée à laquelle l'appel a été résolu.
  • labels."iap.googleapis.com/audited_resource_name" : si cette valeur est unregisteredResource, le nom d'hôte de destination n'est pas enregistré. Enregistrez le nom d'hôte de destination auprès du registre d'agents et assurez-vous que l'agent dispose de l'autorisation iap.resources.egressViaIAP pour cette destination.
  • Mode d'application : examinez le mode d'application de la requête. Pour filtrer les requêtes de dry run, vous pouvez ajouter protoPayload.metadata.iamEnforcementMode="DRY_RUN" à la requête. En mode DRY_RUN, IAP consigne les refus, mais ne les applique pas. Par conséquent, si l'agent échoue avec une erreur 403 en mode d'essai, le refus provient probablement du proxy de sortie de la passerelle ou de la ressource de destination.

Examiner la décision de la passerelle d'agent

Pour savoir comment Agent Gateway a évalué la requête, interrogez les journaux de la passerelle dans Logging. Dans cet exemple, nous filtrons les journaux pour n'afficher que les erreurs 403 :

resource.type="networkservices.googleapis.com/Gateway"
resource.labels.gateway_type="SECURE_WEB_GATEWAY"
resource.labels.location="REGION"
resource.labels.gateway_name="AGENT_GATEWAY_NAME"
httpRequest.status=403
-httpRequest.requestMethod="CONNECT"

Examinez les champs suivants dans l'entrée de journal correspondante :

  • jsonPayload.authzPolicyInfo.policies.result : résultat global de l'autorisation, ALLOWED ou DENIED.
  • httpRequest.requestUrl : notez l'URL de destination exacte que l'agent a tenté d'atteindre. À l'étape suivante, nous vérifions si le nom d'hôte utilisé par la ressource de destination a été enregistré dans l'Agent Registry.

Vérifier l'enregistrement de la destination et la couverture de la stratégie d'accès IAM

L'accès aux destinations nécessite toujours une stratégie d'autorisation IAM accordant l'autorisation iap.resources.egressViaIAP à l'identité de l'agent. Nous vous recommandons d'enregistrer les destinations dans le registre d'agents pour appliquer des règles d'accès précises par ressource et garantir une correspondance exacte des noms d'hôte. Pour les destinations non enregistrées, vérifiez si une règle pour les points de terminaison non enregistrés accorde l'autorisation requise à l'identité de l'agent.

Si vous utilisez des règles par ressource, chaque nom d'hôte de destination et toutes les variantes du nom d'hôte que l'agent tente d'atteindre doivent être enregistrés dans le registre d'agents. En effet, une API Google telle que aiplatform.googleapis.com peut être résolue via plusieurs noms d'hôte en fonction de la version du SDK, de la configuration régionale du client ou de l'utilisation de mTLS (par exemple, us-central1-aiplatform.googleapis.com ou us-central1-aiplatform.mtls.googleapis.com).

Étant donné que la passerelle met en correspondance les noms d'hôte de manière exacte, si vous enregistrez aiplatform.googleapis.com, mais que l'agent appelle us-central1-aiplatform.googleapis.com, la passerelle considère qu'il s'agit d'une ressource non enregistrée et refuse la requête.

Exécutez l'exemple de script suivant pour lister vos entrées de registre en fonction du type de ressource et vérifiez les entrées pour le nom d'hôte spécifique utilisé par l'appel de l'agent :

HOSTNAME="HOSTNAME"
PROJECT_ID="PROJECT_ID"
LOCATION="REGION"

echo "Checking Endpoints..."
gcloud agent-registry endpoints list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

echo "Checking MCP Servers..."
gcloud agent-registry mcp-servers list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

echo "Checking Agents..."
gcloud agent-registry agents list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

Remplacez les éléments suivants :

  • HOSTNAME : nom d'hôte de destination que l'agent tente d'atteindre, par exemple us-central1-aiplatform.mtls.googleapis.com.
  • PROJECT_ID : ID de votre projet Cloud de Confiance .
  • REGION : emplacement de vos ressources Agent Registry et Agent Gateway, par exemple us-central1.

Résultat 1 : Le nom d'hôte est déjà enregistré

Si le nom d'hôte existe dans une entrée de l'Agent Registry, un résultat semblable à l'exemple suivant s'affiche :

Checking Endpoints...
  url: https://us-central1-aiplatform.mtls.googleapis.com
Checking MCP Servers...
Checking Agents...

Passez à Vérifier les liaisons IAM sur la ressource de destination pour vérifier si une stratégie par ressource ou à l'échelle du registre accorde l'accès à l'identité de l'agent.

Sortie 2 : le nom d'hôte n'existe pas dans le registre

Si le nom d'hôte n'existe pas dans le registre, un résultat semblable à l'exemple suivant s'affiche :

Checking Endpoints...
Checking MCP Servers...
Checking Agents...

Si vous prévoyez d'utiliser des règles par ressource ou à l'échelle du registre, enregistrez d'abord la destination dans Agent Registry. Si vous utilisez des stratégies pour les points de terminaison non enregistrés, passez à la section Vérifier les liaisons IAM sur la ressource de destination.

Vérifier les liaisons IAM sur la ressource de destination

Assurez-vous que l'identité de l'agent ou son ensemble de principaux disposent de l'autorisation iap.resources.egressViaIAP sur la destination.

Vous pouvez configurer des liaisons de règles dans trois champs d'application :

  • À l'échelle du registre : accès à tous les agents, serveurs MCP et points de terminaison enregistrés dans le registre.
  • Par ressource : accès restreint. Une liaison par ressource remplace la liaison à l'échelle du registre pour cette ressource spécifique au lieu de fusionner avec elle.
  • Règles pour les points de terminaison non enregistrés : accès aux destinations qui ne sont pas enregistrées dans Agent Registry.

Utilisez l'un des exemples suivants pour vérifier les liaisons :

  • Pour vérifier les liaisons de stratégie IAM au niveau du registre, exécutez la commande suivante :

    curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry:getIamPolicy" \
-H "Content-Type: application/json"

  • Pour vérifier les liaisons de stratégie IAM par point de terminaison, exécutez la commande suivante :

    export HOSTNAME=HOSTNAME

ENDPOINT_ID=$(gcloud agent-registry endpoints list \
--project="PROJECT_ID" \
--location="REGION" \
--filter="interfaces.url:$HOSTNAME" \
--format="value(name.basename())")

echo "ENDPOINT_ID=$ENDPOINT_ID"

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry/endpoints/${ENDPOINT_ID}:getIamPolicy"

    Remplacez HOSTNAME par le nom d'hôte de la destination que l'agent tente d'atteindre (par exemple, us-central1-aiplatform.mtls.googleapis.com).

  • Pour vérifier les liaisons de stratégie IAM par serveur MCP, exécutez la commande suivante :

    export MCP_SERVER=MCP_SERVER

MCP_SERVER_ID=$(gcloud agent-registry mcp-servers list \
--project="PROJECT_ID" \
--location="REGION" \
--filter="interfaces.url:$MCP_SERVER" \
--format="value(name.basename())")

echo "MCP_SERVER_ID=$MCP_SERVER_ID"

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry/mcpServers/${MCP_SERVER_ID}:getIamPolicy"

    Remplacez MCP_SERVER par l'URL du serveur MCP (par exemple, https://example-abc12345-uc.a.run.app/mcp).

Dans les informations sur les règles renvoyées, recherchez une liaison avec l'autorisation iap.resources.egressViaIAP qui correspond à l'identité ou à l'ensemble de principaux de l'agent. Si le résultat renvoyé contient un champ "etag", mais aucune liaison, cela signifie qu'aucune stratégie IAM n'existe.

Si une liaison existe, mais inclut un condition, vérifiez que l'expression CEL (Common Expression Language) n'exclut pas l'agent. Une condition qui filtre par un attribut que l'agent n'a pas peut exclure l'agent de manière silencieuse.

Si la destination cible ne dispose pas d'une liaison de règle correspondante accordant l'autorisation iap.resources.egressViaIAP à l'identité de votre agent ou à votre ensemble de comptes principaux, accordez l'autorisation à l'aide de l'une des options de règle suivantes :

Inspecter la règle d'autorisation et l'extension

Dans cette section, nous nous assurons qu'il existe une règle d'autorisation ciblant explicitement l'Agent Gateway associée à l'agent.

  1. Obtenez les détails de l'extension d'autorisation associée à la passerelle et vérifiez que l'extension que vous utilisez est configurée comme prévu.

    gcloud service-extensions authz-extensions describe AUTHORIZATION_EXTENSION_NAME \
  --location=LOCATION \
  --project=PROJECT_ID

    Remplacez AUTHORIZATION_EXTENSION_NAME par le nom de l'extension associée à la passerelle. Si vous ne connaissez pas le nom de l'extension, vous pouvez accéder à la page d'informations de la passerelle dans la console Cloud de Confiance Cloud de Confiance et noter la valeur du champ Nom de l'extension sous "Extensions de service".

  2. Vérifiez qu'une règle d'autorisation cible explicitement la ressource de passerelle et qu'elle est associée à la même extension d'autorisation. Vous pouvez accéder à la page d'informations de la passerelle dans la console Cloud de Confiance Cloud de Confiance et noter la valeur du champ Nom de la règle sous "Extensions de service".

    Si aucune règle ne cible la passerelle ou si le mappage entre la passerelle et la règle est incorrect, l'extension d'autorisation ne sera pas exécutée.

Vérifier les stratégies de limite d'accès des comptes principaux

Les stratégies de limite d'accès des comptes principaux prévalent sur les stratégies d'autorisation IAM. Cela signifie que même si vous avez correctement configuré toutes les liaisons IAM, une requête échouera s'il existe une stratégie de limite d'accès des comptes principaux active qui exclut la ressource de destination du champ d'application de l'agent.

Pour lister les règles à l'échelle de l'organisation, exécutez la commande suivante :

gcloud iam principal-access-boundary-policies list \
  --organization="ORGANIZATION_ID" \
  --location=global

Pour trouver les stratégies associées à l'ensemble de comptes principaux de l'agent, exécutez la commande suivante :

gcloud iam policy-bindings search-target-policy-bindings \
  --project="PROJECT_ID" \
  --target="PRINCIPAL_SET"

Remplacez les éléments suivants :

  • ORGANIZATION_ID : ID de votre organisation Cloud de Confiance .
  • PROJECT_ID : ID de votre projet Cloud de Confiance .
  • PRINCIPAL_SET : ensemble de comptes principaux de l'identité de l'agent.

Si une liaison existe, inspectez le champ details.rules[].resources[] pour vérifier que la destination est dans le champ d'application de votre agent.

Tester les liaisons de comptes principaux par rapport aux liaisons d'ensembles de comptes principaux

Si les autorisations fonctionnent de manière incohérente ou échouent de manière inattendue, le problème peut être lié à la configuration de l'identité de groupe de votre agent (l'ensemble de principaux). Les autorisations basées sur un ensemble de comptes principaux peuvent échouer pour les raisons suivantes :

  • Délais de synchronisation : lorsque vous ajoutez une identité à un ensemble, IAM peut mettre quelques minutes à se mettre à jour et à reconnaître le nouveau membre.
  • Attributs manquants : si l'appartenance à un ensemble de comptes principaux nécessite certains attributs, l'identité de l'agent doit comporter ces attributs exacts (par exemple, des libellés de service ou d'équipe). Si l'identité ne comporte pas ces attributs, l'agent peut être exclu du groupe sans notification.

Pour vérifier si le problème est lié à l'appartenance à un groupe, accordez des autorisations directement à l'agent spécifique en ajoutant une liaison principal:// directe sur la ressource concernée. Si l'agent se connecte correctement avec la liaison directe, la cause première est probablement une incompatibilité d'attributs ou un délai de synchronisation avec l'ensemble principal. Pour résoudre ce problème, validez et corrigez les attributs d'identité de l'agent, ou utilisez des liaisons principal:// directes.

Étapes suivantes

Atelier de programmation

Découvrez comment régir les charges de travail agentiques avec Agent Gateway sur Gemini Enterprise Agent Platform.

Guide

Découvrez comment surveiller la passerelle d'agent.