Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Probleme mit der Authentifizierung der Agent-Identität beheben

In diesem Dokument wird beschrieben, wie Sie häufige Fehler bei der Verwendung des Agent Identity-Authentifizierungsmanagers beheben.

Eine Anleitung zum Konfigurieren von Authentifizierungsanbietern finden Sie unter Authentifizierungsanbieter für Agent-Identitäten verwalten.

Nicht übereinstimmender Weiterleitungs-URI

Wenn Sie während des OAuth-Ablaufs einen redirect URI mismatch-Fehler von der Drittanbieteranwendung erhalten, prüfen Sie, ob der im Drittanbieter-Entwicklerportal registrierte Weiterleitungs-URI genau mit dem vom Autorisierungsmanager generierten URI übereinstimmt.

Um dieses Problem zu beheben, rufen Sie den generierten Weiterleitungs-URI ab, indem Sie sich die Details des Authentifizierungsanbieters in der Cloud de Confiance -Konsole ansehen oder den folgenden gcloud-Befehl ausführen:

gcloud alpha agent-identity authProviders describe AUTH_PROVIDER_NAME \
    --location="LOCATION"

Nutzerrolle fehlt

Wenn Ihr Agent den Authentifizierungsanbieter nicht verwenden kann, prüfen Sie, ob die Agent-Identität die Rolle roles/agentidentity.user für die Authentifizierungsanbieterressource hat.

Um dieses Problem zu beheben, weisen Sie die Rolle über die Cloud de Confiance Console zu oder führen Sie den Befehl add-iam-policy-binding aus.

Probleme mit Ausstellerendpunkten

Prüfen Sie bei OIDC-Anbietern, ob der Aussteller-Endpunkt öffentlich zugänglich ist und das .well-known/openid-configuration-Discovery-Dokument unterstützt.

Wenn Cloud de Confiance die OIDC-Metadaten oder JWKS nicht abrufen kann, prüfen Sie, ob sich der Endpunkt hinter einer Firewall oder in einem eingeschränkten Netzwerk befindet.

Fehler 401 UNAUTHENTICATED

Wenn sich Ihr Agent nicht authentifizieren kann, tritt möglicherweise der folgende Fehler auf. Dieser Fehler wird in der Regel durch eine von Google verwaltete Richtlinie für den kontextsensitiven Zugriff verursacht, die die mTLS-Bindung und DPoP-kryptografische Beweise erzwingt:

{
  "error": {
    "code": 401,
    "message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
    "status": "UNAUTHENTICATED"
  }
}

Wenn Sie diesen Fehler beheben möchten, können Sie die Standardrichtlinie für den kontextsensitiven Zugriff deaktivieren, wenn Sie bestimmte Anforderungen für die gemeinsame Nutzung von Tokens haben oder das Token direkt in den Header einfügen müssen. Wenn Sie die Funktion deaktivieren möchten, legen Sie beim Bereitstellen Ihres Agents die folgende Umgebungsvariable fest:

config={
  "env_vars": {
    "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False,
  }
}

API-Schlüssel-Dienst blockiert (`API_KEY_SERVICE_BLOCKED`)

Wenn Sie Ihren API-Schlüssel validieren, kann der folgende Fehler auftreten. Dieser Fehler gibt an, dass der Dienst blockiert ist:

"details": [
  {
    "@type": "type.googleapis.com/google.rpc.ErrorInfo",
    "reason": "API_KEY_SERVICE_BLOCKED",
    "domain": "googleapis.com",
    "metadata": {
      "methodName": "google.cloud.translate.v2.TranslateService.TranslateText",
      "service": "translate.googleapis.com",
      "consumer": "projects/PROJECT_NUMBER",
      "apiName": "translate"
    }
  },
  {
    "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
    "locale": "en-US",
    "message": "Requests to this API translate method google.cloud.translate.v2.TranslateService.TranslateText are blocked."
  }
]

Dieser Fehler tritt auf, weil der Ziel-API-Dienst (z. B. die Cloud Translation API) in Ihrem Cloud de Confiance -Projekt nicht aktiviert wurde oder die Einschränkungen des API-Schlüssels keinen Zugriff auf diesen Dienst zulassen.

So beheben Sie diesen Fehler:

Rufen Sie in der Cloud de Confiance Console die Seite APIs & Dienste >Bibliothek auf und prüfen Sie, ob die Ziel-API aktiviert ist.
Rufen Sie „APIs & Dienste“ >„Bibliothek“ auf.
Rufen Sie in der Cloud de Confiance Console die Seite APIs & Dienste >Anmeldedaten auf, bearbeiten Sie Ihren API-Schlüssel und prüfen Sie, ob die API-Einschränkungen den Zugriff auf den Dienst zulassen.
Zu „APIs & Dienste“ > „Anmeldedaten“

Ungültiger API-Schlüssel (`API_KEY_INVALID`)

Beim Senden von Anfragen an einen Drittanbieterdienst kann der folgende Fehler auftreten. Dieser Fehler gibt an, dass der API-Schlüssel ungültig ist:

"details": [
  {
    "@type": "type.googleapis.com/google.rpc.ErrorInfo",
    "reason": "API_KEY_INVALID",
    "domain": "googleapis.com",
    "metadata": {
      "service": "translate.googleapis.com"
    }
  },
  {
    "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
    "locale": "en-US",
    "message": "API key not valid. Please pass a valid API key."
  }
]

Dieser Fehler tritt auf, weil der in Ihrem Anfrageheader übergebene API-Schlüsselstring falsch oder fehlerhaft ist oder nicht in den Anmeldedaten Ihres Projekts vorhanden ist.

Prüfen Sie, ob Sie den richtigen API-Schlüsselstring von der Seite Anmeldedaten in der Cloud de Confiance Console kopiert haben und ob der String keine Leerzeichen am Anfang oder Ende enthält.

Berechtigung zum Abrufen von Anmeldedaten verweigert (`agentidentity.authProviders.retrieveCredentials`)

Wenn Sie adk web lokal ausführen oder mit Ihrem bereitgestellten Agenten interagieren, kann der folgende 403 Forbidden-Fehler auftreten:

google.api_core.exceptions.Forbidden: 403 POST https://agentidentitycredentials.mtls.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/authProviders/AUTH_PROVIDER_NAME/credentials:retrieve?%24alt=json%3Benum-encoding%3Dint: Permission 'agentidentity.authProviders.retrieveCredentials' denied on resource '//agentidentity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/authProviders/AUTH_PROVIDER_NAME' (or it may not exist).

Dieser Fehler tritt auf, weil der Prinzipal, der versucht, den Auth-Bereitsteller aufzurufen, nicht die erforderlichen IAM-Berechtigungen zum Abrufen von Anmeldedaten hat.

Um diesen Fehler zu beheben, weisen Sie dem Hauptkonto die Rolle Agent Identity User (roles/agentidentity.user) zu:

Wenn dieser Fehler bei der lokalen Entwicklung (uv run adk web oder uvicorn) auftritt, prüfen Sie, ob Sie Ihrem persönlichen Nutzerkonto (user:USER_EMAIL) die Rolle zugewiesen haben.
Wenn dieser Fehler bei der Interaktion mit einem bereitgestellten Agent auftritt, prüfen Sie, ob Sie dem SPIFFE-ID-Principal (principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/LOCATION/reasoningEngines/ENGINE_ID) Ihres Agents die Rolle zugewiesen haben.

Allgemeiner Bereitstellungsfehler

Wenn Sie Ihren Agenten mit uv run adk deploy bereitstellen, kann der Befehl mit einer allgemeinen Fehlermeldung fehlschlagen.

Dieser Fehler tritt aufgrund fehlender Python-Abhängigkeiten, Syntaxfehler in agent.py oder falsch konfigurierten Umgebungsvariablen auf.

So beheben Sie diesen Fehler:

Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf.
Suchen Sie nach den Logs des temporären Deployment-Containers, z. B. maps_mcp_agent_tmp... oder bigquery_mcp_agent_tmp....
Prüfen Sie den Python-Traceback, um Syntaxfehler zu identifizieren oder fehlende Pakete zu verfolgen.
Achten Sie darauf, dass alle erforderlichen Pakete in Ihrer Datei requirements.txt aufgeführt sind.

ServiceNow-Authentifizierungsschleife oder unerwartete Bereiche

Wenn sich ein Kundenservicemitarbeiter mit dem dreibeinigen OAuth bei ServiceNow authentifiziert, kann es sein, dass der Authentifizierungsablauf fehlschlägt oder der Kundenservicemitarbeiter in eine Anfrageschleife gerät.

Dieses Problem tritt auf, weil ServiceNow gewährte Bereiche auf Anwendungsebene und nicht anhand der vom Agent angeforderten Bereiche bestimmt. Wenn ein Administrator bestimmte Bereiche in der ServiceNow-Anwendung konfiguriert (z. B. useraccount), gibt ServiceNow Tokens zurück, die nur diese konfigurierten Bereiche enthalten, auch wenn der Agent andere Bereiche angefordert hat (z. B. mcp_server). Wenn der Agent die angeforderten Bereiche strikt erwartet oder validiert, lehnt er das empfangene Token ab und fordert möglicherweise in einer Schleife Anmeldedaten an.

So beheben Sie das Problem:

Melden Sie sich als Administrator in Ihrer ServiceNow-Instanz an.
Rufen Sie die ServiceNow OAuth-Anwendungskonfiguration auf.
Achten Sie darauf, dass alle für Ihren Agent erforderlichen Bereiche explizit der Liste der zulässigen Bereiche für die Anwendung hinzugefügt werden.
Konfigurieren Sie Ihren Agent so, dass nur die in ServiceNow aktivierten Bereiche angefordert werden.

Weitere Informationen finden Sie unter Unterstützte Drittanbieterdienste.

Fehler bei mehreren Bereichen in GitHub oder Microsoft

Wenn Sie einen Authentifizierungsanbieter für GitHub oder Microsoft konfigurieren, schlägt die Authentifizierung fehl, wenn Sie mehrere OAuth-Bereiche anfordern.

Der Auth-Manager unterstützt Integrationen mit einem einzigen Bereich für GitHub und Microsoft. Der Auth-Manager unterstützt nicht das gleichzeitige Anfordern mehrerer Bereiche.

Um dieses Problem zu beheben, konfigurieren Sie Ihren Agent oder Authentifizierungsanbieter so, dass nur ein für die Integration erforderlicher Bereich angefordert wird.