Risolvere i problemi di connettività di Agent Gateway

Questa guida ti aiuta a eseguire il debug e risolvere i problemi di connettività con Gemini Enterprise Agent Platform, in particolare quando utilizzi Agent Gateway, l'identità dell'agente, le policy di Identity and Access Management (IAM) e l'autorizzazione delegata con le estensioni di servizio.

Risolvere i problemi utilizzando la skill per la risoluzione dei problemi di Agent Platform

Per diagnosticare i problemi di connettività, autorizzazione e avvio in modo interattivo con un'assistenza al coding AI, puoi installare la skill agent-platform-troubleshooting dal repository delle skill dell'agente Cloud de Confiance by S3NS .

Questa competenza fornisce agli agenti AI playbook diagnostici specifici per il dominio, filtri dei log e passaggi di risoluzione nello stack di Agent Platform, tra cui:

  • Negazioni di uscita del gateway dell'agente: diagnosi degli 403 Forbidden errori intercettati dal gateway e verifica delle decisioni di autorizzazione IAP.
  • Errori di avvio di Agent Runtime: identificazione dei ruoli mancanti (ad esempio roles/browser o resourcemanager.projects.get) e delle eccezioni di bootstrap.
  • Problemi di destinazione di Agent Registry: verifica delle voci di servizio, delle interfacce degli endpoint e delle configurazioni consolidate delle API di Google.
  • Policy di accesso IAM: convalida delle associazioni delle Unified Access Policies (UAP), delle espressioni delle condizioni e dell'ambito del confine di accesso dell'entità (PAB).
  • Container trust: diagnosi di errori di handshake e certificato TLS per container personalizzati (BYOC) o autorità di certificazione (CA) private.

Per installare la skill nell'ambiente dell'agente, esegui questo comando:

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

Flusso delle richieste in uscita

Agent Platform adotta un criterio default-deny per tutto il traffico in uscita. Affinché un agente si connetta a risorse esterne, devi consentire esplicitamente l'accesso a ogni livello di rete e identità. Quando Agent Gateway è abilitato, il gateway intercetta tutte le richieste dell'agente e applica i criteri configurati.

Affinché una richiesta vada a buon fine, deve soddisfare tutte le seguenti condizioni:

  • Policy di accesso IAM: all'identità dell'agente assegnata all'agente deve essere concessa l'autorizzazione iap.resources.egressViaIAP per la risorsa di destinazione, direttamente o tramite un insieme di entità. Per maggiori dettagli, consulta Creare policy dell'agente IAM. Scopri come risolvere i problemi relativi alle policy IAP.
  • Agent Registry: ti consigliamo di registrare le destinazioni in Agent Registry per applicare policy di accesso granulari per risorsa e controlli a livello di strumento. Se l'agente sta tentando di raggiungere una destinazione non registrata, devi concedere l'autorizzazione iap.resources.egressViaIAP all'identità dell'agente configurando una policy per un endpoint non registrato.
  • Agent Gateway: il gateway deve essere associato a una policy di autorizzazione che lo prende di mira in modo esplicito. Per impostazione predefinita, il gateway utilizza IAP e Model Armor per proteggere le richieste.
  • Autorizzazione delegata con Service Extensions: puoi delegare le decisioni di autorizzazione a un motore di autorizzazione personalizzato utilizzando Service Extensions. A seconda della norma di autorizzazione configurata, uno o più di questi motori di autorizzazione consentiranno o negheranno la richiesta.

Problemi comuni

Esamina questi problemi comuni e le relative soluzioni durante la risoluzione dei problemi di Agent Gateway.

Errori durante l'avvio di Agent Runtime

Se le istanze di Agent Runtime non vengono avviate o non vengono implementate, potrebbe significare che IAP blocca il traffico interno o che l'agente non dispone dei ruoli di base necessari per l'inizializzazione.

  1. Conferma che IAP non blocchi le chiamate ai servizi interni

    Sintomo: errori 403 Forbidden durante l'avvio.

    Causa: Agent Gateway utilizza una policy di negazione predefinita per tutto il traffico. Pertanto, quando IAP è in modalità di applicazione, blocca le chiamate anche ai servizi interni (come aiplatform o logging) a meno che non siano registrati e l'agente non disponga delle autorizzazioni IAM richieste.

    Correzione: passa temporaneamente IAP alla modalità dry run per vedere quali connessioni non vanno a buon fine senza bloccare l'avvio oppure esegui una query su Cloud Logging per identificare i nomi host bloccati esatti. Dopo aver identificato i nomi host dei servizi target, registrali in Agent Registry e concedi l'autorizzazione iap.resources.egressViaIAP all'agente.

    Per trovare nomi host bloccati specifici utilizzando Cloud Logging, esegui la seguente query in Esplora log:

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

    Esamina i campi httpRequest.requestUrl o jsonPayload.authzPolicyInfo nei risultati per trovare i nomi host di destinazione.

    I servizi interni comuni che potrebbero richiedere la registrazione durante l'avvio includono:

    • Agent Platform (motore di ragionamento e sessioni): https://REGION-aiplatform.mtls.googleapis.com
    • Resource Manager: https://cloudresourcemanager.mtls.googleapis.com e https://cloudresourcemanager.mtls.googleapis.com/
    • Google Cloud Observability (se abilitato): https://telemetry.mtls.googleapis.com/
    • Cloud Logging (se abilitato): https://logging.googleapis.com/
    • Cloud Monitoring: https://monitoring.googleapis.com/ e https://monitoring.mtls.googleapis.com/
    • Cloud Trace: https://cloudtrace.googleapis.com/ e https://cloudtrace.mtls.googleapis.com/
    • Secret Manager: https://secretmanager.googleapis.com/ e https://secretmanager.mtls.googleapis.com/

  2. Verifica che l'identità dell'agente disponga dei ruoli di base richiesti

    Sintomi: nei log di aiplatform.googleapis.com/reasoning_engine_stderr, vengono visualizzati errori come google.api_core.exceptions.Unknown: None o Failed to convert project number to project ID. L'errore viene visualizzato durante l'avvio del motore di ragionamento.

    Causa. L'identità dell'agente non dispone dell'autorizzazione resourcemanager.projects.get necessaria per risolvere il nome del progetto durante l'inizializzazione.

    Correggi. Assicurati che l'identità dell'agente (o il relativo set di entità) disponga delle autorizzazioni necessarie per leggere la propria configurazione di runtime. Sono richiesti i seguenti ruoli:

    • roles/aiplatform.agentDefaultAccess: Ruolo predefinito dell'agente.
    • roles/aiplatform.user: obbligatorio per eseguire l'agente.
    • roles/agentregistry.viewer: obbligatorio per visualizzare le risorse registrate.
    • roles/logging.logWriter e roles/monitoring.metricWriter: obbligatori per l'osservabilità.
    • roles/browser: obbligatorio per eseguire resourcemanager.projects.get durante l'inizializzazione dell'SDK.

    Per verificare i ruoli assegnati all'identità dell'agente, esegui il seguente comando:

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto Cloud de Confiance .
    • AGENT_IDENTITY_PRINCIPAL: l'entità dell'identità dell'agente. Utilizza il formato: principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

    Per scoprire come concedere i ruoli, consulta Utilizzare l'identità dell'agente con Agent Runtime.

403 Forbidden errori

Se riscontri un errore 403 Forbidden, verifica che sia correlato al traffico in uscita dell'Agent Gateway. Ecco un esempio di messaggio di errore in uscita:

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

Esegui query nei log dell'agente in Logging per trovare le chiamate specifiche non riuscite:

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

Sostituisci quanto segue:

  • LOCATION: la regione in cui è stato eseguito il deployment dell'agente, ad esempio us-central1.
  • AGENT_ID: l'ID dell'agente (Reasoning Engine).

Cerca il messaggio Egress request is not authorized in textPayload della voce di log. Se l'errore 403 contiene un testo diverso, il servizio di destinazione potrebbe rifiutare la chiamata direttamente, anziché Agent Gateway.

Puoi anche visualizzare i log del traffico in uscita, inclusi i 403 dinieghi, utilizzando la dashboard di osservabilità integrata.

Impossibile connettersi alle destinazioni CA autofirmate o private

  • Sintomo: l'agente non riesce a connettersi alle destinazioni che presentano certificati autofirmati o emessi da CA private.
  • Causa: per impostazione predefinita, Agent Gateway considera attendibili solo i certificati emessi da CA attendibili pubblicamente. La connessione a destinazioni che utilizzano CA private o certificati autofirmati richiede una configurazione aggiuntiva.
  • Mitigazione: per connetterti alle destinazioni utilizzando CA private o certificati autofirmati, devi configurare trust anchor TLS personalizzati utilizzando l'impostazione tlsConfig in un template di connettività dell'agente.

L'agente di cui è stato eseguito il deployment con un container personalizzato (BYOC) non riesce a connettersi ad Agent Gateway

  • Sintomo: l'agente BYOC non riesce a stabilire connessioni quando viene instradato tramite Agent Gateway. I log potrebbero mostrare errori di handshake TLS o di verifica del certificato.
  • Causa: il contenitore personalizzato dell'agente non considera attendibile l'autorità di certificazione dell'Agent Gateway.
  • Correzione:assicurati di aver aggiunto il certificato radice di Agent Gateway all'archivio CA del tuo container. Consulta Configurare agenti di container personalizzati (BYOC) per Agent Gateway.

L'associazione delle policy non va a buon fine o simula un rifiuto della governance

  • Sintomo: le configurazioni di binding delle policy non vanno a buon fine, ti viene chiesto in modo interattivo un etag durante il binding delle policy o le richieste non vanno a buon fine con un errore di negazione della governance errato (ad esempio "destinazione non registrata rifiutata correttamente").
  • Causa: l'API Identity-Aware Proxy (iap.googleapis.com) è disattivata nel tuo progetto.
  • Correzione:abilita l'API Identity-Aware Proxy.

Errori durante la gestione di Agent Gateway con la federazione delle identità della forza lavoro

Potresti riscontrare questo problema se gestisci Agent Gateway nella consoleCloud de Confiance o utilizzi gcloud CLI dopo l'autenticazione con la federazione delle identità per la forza lavoro (WIF).

La console visualizza errori di caricamento o creazione generici, ad esempio:

  • "Si è verificato un errore durante il caricamento…"
  • "Il server non è riuscito a completare la tua richiesta"
  • "Impossibile creare il gateway dell'agente"
  • "Impossibile caricare"

Inoltre, i comandi gcloud (ad esempio gcloud network-services agent-gateways import) potrebbero restituire un errore interno, ad esempio error 13: an internal error has occurred.

Per risolvere il problema, esegui l'autenticazione con un Account Google standard gestito tramite Cloud Identity o Google Workspace che disponga delle autorizzazioni richieste, ad esempio roles/networkservices.admin.

Le identità federate hanno un supporto limitato nei servizi Agent Platform Governance e Gateway in anteprima. La concessione di ruoli IAM più ampi a un'entità federata non risolve il problema.

Workflow di debug

Se una delle condizioni descritte nella sezione Flusso delle richieste in uscita non è presente, le tue richieste potrebbero essere bloccate.

Esamina la decisione relativa all'IAP

Per restringere la ricerca dei log alle decisioni sul traffico in uscita di IAP, esegui la seguente query in Logging:

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

Se non vedi alcuna voce di log IAP corrispondente, il gateway potrebbe aver rifiutato la richiesta prima che IAP la valutasse. Vai al passaggio successivo.

Se vedi una voce di log corrispondente, esamina i seguenti campi:

  • protoPayload.authorizationInfo[].granted: indica se la richiesta è stata consentita (true) o negata (false).
  • protoPayload.authenticationInfo.principalSubject: L'ID SPIFFE o l'identità principal://... del chiamante. Verifica che corrisponda all'identità del tuo agente.
  • protoPayload.authorizationInfo[].resource: La risorsa di destinazione registrata a cui è stata risolta la chiamata.
  • labels."iap.googleapis.com/audited_resource_name": se questo valore è unregisteredResource, il nome host di destinazione non è registrato. Registra il nome host di destinazione con Agent Registry e assicurati che l'agente disponga dell'autorizzazione iap.resources.egressViaIAP per questa destinazione.
  • Modalità di applicazione forzata: esamina la modalità di applicazione forzata della richiesta. Per filtrare le richieste dry run, puoi aggiungere protoPayload.metadata.iamEnforcementMode="DRY_RUN" alla query. In modalità DRY_RUN, IAP registra i rifiuti, ma non li applica. Pertanto, se l'agente non riesce con un errore 403 in modalità dry run, il rifiuto probabilmente proviene dal proxy in uscita del gateway o dalla risorsa di destinazione.

Esamina la decisione di Agent Gateway

Per esaminare il modo in cui Agent Gateway ha valutato la richiesta, esegui una query sui log del gateway in Logging. In questo esempio, filtriamo i log solo per gli errori 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"

Esamina i seguenti campi nella voce di log corrispondente:

  • jsonPayload.authzPolicyInfo.policies.result: il risultato complessivo dell'autorizzazione, ALLOWED o DENIED.
  • httpRequest.requestUrl: prendi nota dell'URL di destinazione esatto che l'agente ha tentato di raggiungere. Nel passaggio successivo, controlliamo se il nome host utilizzato dalla risorsa di destinazione è stato registrato in Agent Registry.

Verifica la registrazione della destinazione e la copertura dei criteri di accesso IAM

L'accesso alle destinazioni richiede sempre una policy di autorizzazione IAM che conceda l'autorizzazione iap.resources.egressViaIAP all'identità dell'agente. Per applicare policy di accesso granulari per risorsa e garantire una corrispondenza accurata dei nomi host, è consigliabile registrare le destinazioni in Agent Registry. Per le destinazioni non registrate, verifica se un criterio per gli endpoint non registrati concede l'autorizzazione richiesta all'identità dell'agente.

Se utilizzi criteri per risorsa, ogni nome host di destinazione e qualsiasi variante del nome host che l'agente tenta di raggiungere deve essere registrata in Agent Registry. Questo perché un'API di Google come aiplatform.googleapis.com può essere risolta tramite più nomi host a seconda della versione dell'SDK, della configurazione del client regionale o dell'utilizzo di mTLS (ad esempio, us-central1-aiplatform.googleapis.com o us-central1-aiplatform.mtls.googleapis.com).

Poiché il gateway corrisponde esattamente ai nomi host, se registri aiplatform.googleapis.com, ma l'agente chiama us-central1-aiplatform.googleapis.com, il gateway lo considera una risorsa non registrata e nega la richiesta.

Esegui il seguente script di esempio per elencare le voci del registro in base al tipo di risorsa e controlla le voci per il nome host specifico utilizzato dalla chiamata dell'agente:

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"

Sostituisci quanto segue:

  • HOSTNAME: il nome host di destinazione che l'agente sta tentando di raggiungere, ad esempio us-central1-aiplatform.mtls.googleapis.com.
  • PROJECT_ID: l'ID progetto Cloud de Confiance .
  • REGION: la posizione delle risorse Agent Registry e Agent Gateway, ad esempio us-central1.

Output 1: Hostname is already registered

Se il nome host esiste in una voce del registro degli agenti, viene visualizzato un output simile al seguente esempio:

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

Vai a Verifica i binding IAM nella risorsa di destinazione per controllare se una policy per risorsa o a livello di registry concede l'accesso all'identità dell'agente.

Output 2: il nome host non esiste nel registry

Se il nome host non esiste nel registro, viene visualizzato un output simile all'esempio seguente:

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

Se prevedi di utilizzare policy per risorsa o a livello di registro, registra prima la destinazione in Agent Registry. Se utilizzi policy per endpoint non registrati, vai a Verifica i binding IAM sulla risorsa di destinazione.

Verifica le associazioni IAM sulla risorsa di destinazione

Assicurati che l'identità dell'agente o il relativo insieme di entità disponga dell'autorizzazione iap.resources.egressViaIAP sulla destinazione.

Puoi configurare i binding dei criteri in tre ambiti:

  • A livello di registry: accesso a ogni agente, server MCP ed endpoint registrato nel registry.
  • Per risorsa: limita l'accesso. Un'associazione per risorsa sostituisce l'associazione a livello di registro per quella risorsa specifica anziché unirsi a essa.
  • Policy per gli endpoint non registrati: accesso alle destinazioni non registrate in Agent Registry.

Utilizza uno dei seguenti esempi per verificare le associazioni:

  • Per verificare la presenza di associazioni di policy IAM a livello di registry, esegui il seguente comando:

    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"

  • Per verificare la presenza di associazioni di policy IAM per endpoint, esegui il seguente comando:

    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"

    Sostituisci HOSTNAME con il nome host della destinazione che l'agente sta tentando di raggiungere, ad esempio us-central1-aiplatform.mtls.googleapis.com.

  • Per verificare le associazioni di policy IAM per server MCP, esegui il seguente comando:

    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"

    Sostituisci MCP_SERVER con l'URL del server MCP (ad esempio, https://example-abc12345-uc.a.run.app/mcp).

Nelle informazioni restituite sulla policy, cerca un'associazione con l'autorizzazione iap.resources.egressViaIAP che corrisponda all'identità o al set di entità dell'agente. Se l'output restituito contiene un campo "etag" ma nessun binding, significa che non esiste alcun criterio IAM.

Se esiste un'associazione, ma include un condition, verifica che l'espressione Common Expression Language (CEL) non escluda l'agente. Una condizione che filtra in base a un attributo di cui l'agente non dispone potrebbe escludere l'agente senza che tu te ne accorga.

Se la destinazione di destinazione non ha un'associazione delle norme di corrispondenza corrispondente che concede l'autorizzazione iap.resources.egressViaIAP all'identità dell'agente o al set di entità, concedi l'autorizzazione utilizzando una delle seguenti opzioni delle policy:

Esamina la policy di autorizzazione e l'estensione

In questa sezione ci assicuriamo che esista una policy di autorizzazione che prenda di mira esplicitamente l'Agent Gateway associato all'agente.

  1. Recupera i dettagli dell'estensione dell'autorizzazione associata al gateway e verifica che l'estensione che stai utilizzando sia configurata come previsto.

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

    Sostituisci AUTHORIZATION_EXTENSION_NAME con il nome dell'estensione associata al gateway. Se non conosci il nome dell'estensione, puoi andare alla pagina dei dettagli del gateway nella console Cloud de Confiance Cloud de Confiance e annotare il valore del campo Nome estensione in Service Extensions.

  2. Verifica che una policy di autorizzazione abbia come target esplicito la risorsa gateway e si colleghi alla stessa estensione dell'autorizzazione. Puoi andare alla pagina dei dettagli del gateway nella console Cloud de Confiance Cloud de Confiance e annotare il valore del campo Nome policy in Service Extensions.

    Se nessun criterio ha come target il gateway o se il mapping gateway-criterio non è corretto, l'estensione dell'autorizzazione non verrà eseguita.

Controlla le policy di Principal Access Boundary

Le policy sul confine di accesso dell'entità hanno la precedenza sulle policy di autorizzazione IAM. Ciò significa che, anche se hai configurato correttamente tutti i binding IAM, una richiesta non andrà a buon fine se esiste una policy di boundary di accesso dell'entità attiva che esclude la risorsa di destinazione dall'ambito dell'agente.

Per elencare le policy a livello di organizzazione, esegui:

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

Per trovare le policy associate al set di entità dell'agente, esegui:

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

Sostituisci quanto segue:

  • ORGANIZATION_ID: l'ID della tua organizzazione Cloud de Confiance .
  • PROJECT_ID: l'ID progetto Cloud de Confiance .
  • PRINCIPAL_SET: Il set di entità dell'identità dell'agente.

Se esiste un'associazione, controlla il campo details.rules[].resources[] per verificare che la destinazione rientri nell'ambito dell'agente.

Testa le associazioni di entità rispetto a quelle di set di entità

Se le autorizzazioni funzionano in modo incoerente o non funzionano in modo imprevisto, il problema potrebbe riguardare il modo in cui è configurata l'identità di gruppo dell'agente (il set di entità). Le autorizzazioni basate su set di entità potrebbero non funzionare per i seguenti motivi:

  • Ritardi nella sincronizzazione: quando aggiungi un'identità a un insieme, IAM potrebbe impiegare alcuni minuti per aggiornarsi e riconoscere il nuovo membro.
  • Attributi mancanti: se l'appartenenza a un insieme principale richiede determinati attributi, l'identità dell'agente deve includerli (ad esempio, etichette di reparto o team). Se l'identità non include questi attributi, l'agente potrebbe essere escluso silenziosamente dal gruppo.

Per verificare se il problema è l'appartenenza al gruppo, concedi le autorizzazioni direttamente all'agente specifico aggiungendo un'associazione principal:// diretta alla risorsa interessata. Se l'agente si connette correttamente all'associazione diretta, la causa principale è probabilmente una mancata corrispondenza degli attributi o un ritardo di sincronizzazione con il set di entità. Per risolvere il problema, verifica e correggi gli attributi di identità dell'agente o utilizza i binding principal:// diretti.

Passaggi successivi

Codelab

Scopri come gestire i carichi di lavoro agentici con Agent Gateway su Gemini Enterprise Agent Platform.

Guida

Scopri come monitorare Agent Gateway.