Présentation de l'identité de l'agent

Agent Identity fournit une identité cryptographique hautement certifiée pour chaque agent, basée sur la norme SPIFFE. Avec l'identité d'agent, votre agent peut s'authentifier de manière sécurisée auprès de serveurs MCP, de ressources cloud, de points de terminaison et d'autres agents, en agissant soit en son nom propre, soit au nom d'un utilisateur final. Agent Identity utilise les propres identifiants de l'agent et le gestionnaire d'authentification Agent Identity. Vous pouvez utiliser le gestionnaire d'authentification pour créer et gérer des fournisseurs d'authentification, qui sont les configurations spécifiques utilisées pour acquérir, gérer et sécuriser les clés API, les ID client OAuth, les codes secrets du client OAuth et les jetons OAuth délégués de l'utilisateur final.

Contrairement aux comptes de service, les identités Agent Identity ne sont pas partagées par plusieurs charges de travail par défaut, ne peuvent pas être empruntées et ne permettent pas aux développeurs de générer des clés de compte de service de longue durée. Les jetons d'accès générés pour Google Cloudsont liés par cryptographie aux certificats X.509 uniques de l'agent afin d'éviter le vol de jetons.

Agent Identity fonctionne avec Agent Registry et Agent Gateway pour sécuriser et gouverner les agents IA. Agent Identity provisionne les identités cryptographiques et gère les identifiants, Agent Registry répertorie les outils et les destinations de votre environnement, et Agent Gateway applique les règles d'accès et inspecte le trafic réseau lorsque les agents appellent ces destinations.

Les services suivants sont compatibles avec l'identité de l'agent :

Modèles d'authentification

Pour s'authentifier auprès de divers outils et services, Agent Identity est compatible avec plusieurs modèles d'authentification. Le modèle utilisé par un agent dépend de la méthode d'authentification proposée par la ressource cible et du fait que l'agent agisse de sa propre autorité ou au nom d'un utilisateur final.

Autorité Méthode d'authentification Ressource cible Cas d'utilisation et solution
Autorité déléguée par l'utilisateur OAuth 2.0 (à trois étapes) Outils et services externes Lorsqu'un agent agit au nom d'un utilisateur spécifique (par exemple, pour accéder aux tâches Jira ou aux dépôts GitHub d'un utilisateur). Vous configurez un fournisseur d'authentification OAuth en trois étapes dans le gestionnaire d'authentification Agent Identity pour gérer le consentement utilisateur et les jetons. Pour en savoir plus, consultez S'authentifier à l'aide d'OAuth à trois branches avec le gestionnaire d'authentification.
Autorité de l'agent Identité dans le cloud (Agent Identity) Google Cloud services Lorsqu'un agent hébergé sur Google Cloud doit accéder à d'autres services Google Cloud en utilisant sa propre identité. Pour en savoir plus, consultez S'authentifier auprès de Google Cloud à l'aide de l'identité d'un agent.
Identité dans le cloud (jetons d'ID OIDC) Outils et services externes Lorsqu'un agent hébergé sur Google Cloud doit s'authentifier auprès de backends externes, d'API personnalisées ou de plates-formes cloud tierces à l'aide de sa propre identité et de la fédération d'identité OpenID Connect (OIDC). Pour en savoir plus, consultez S'authentifier auprès de services externes à l'aide de l'identité d'un agent.
OAuth 2.0 (en deux étapes) Outils et services externes Recommandé pour l'authentification de machine à machine avec des services externes compatibles avec OAuth. Vous configurez un fournisseur d'authentification OAuth à deux étapes dans le gestionnaire d'authentification Agent Identity pour gérer les identifiants client et les jetons d'accès. Pour en savoir plus, consultez S'authentifier à l'aide d'OAuth à deux segments avec le gestionnaire d'authentification.
Clé API Outils et services externes Pour les services externes qui nécessitent une clé cryptographique ou un mot de passe pour l'authentification. Vous configurez un fournisseur d'authentification par clé API dans le gestionnaire d'authentification Agent Identity pour stocker et gérer les clés de manière sécurisée. Pour en savoir plus, consultez S'authentifier à l'aide d'une clé API avec le gestionnaire d'authentification.
Authentification de base HTTP Outils et services externes Utilise des mots de passe en texte clair. Cette méthode n'est pas recommandée. Vous pouvez stocker des mots de passe de la même manière qu'une clé API. Pour en savoir plus, consultez S'authentifier à l'aide d'une clé API avec le gestionnaire d'authentification.

Architecture de délégation d'identité

Pour appliquer des limites de confiance entre les utilisateurs humains, les charges de travail autonomes et les outils externes sans recourir à l'emprunt d'identité d'un compte de service, l'identité d'agent utilise un framework de délégation à trois identités. Ce framework sépare et coordonne trois contextes d'identité distincts dans votre environnement :

  • Identité de l'utilisateur : identité de l'utilisateur final à l'origine de la requête, authentifiée via OAuth 2.0 ou OpenID Connect (OIDC) standard avec Google Identity ou un fournisseur d'identité (IdP) fédéré des employés.
  • Identité de l'agent : identité SPIFFE unique et attestée par cryptographie de l'agent déployé, et certificat X.509 provisionné automatiquement, représentant l'agent agissant sous sa propre autorité.
  • Identité déléguée : contexte d'autorité combiné lorsque l'agent agit au nom de l'utilisateur humain à l'origine de la requête à l'aide d'identifiants OAuth à trois acteurs (3LO) limités, négociés par le gestionnaire d'authentification Agent Identity.

Le diagramme suivant illustre l'interaction entre l'identité de l'utilisateur, l'identité de l'agent et l'identité déléguée au niveau des limites de confiance d'entrée, d'exécution et de sortie :

Schéma de l'architecture de délégation d'identité mappant l'identité de l'utilisateur, l'identité de l'agent et l'identité déléguée entre les limites de confiance d'entrée, d'exécution et de sortie.

Pour en savoir plus sur la façon dont la plate-forme évalue et propage chaque couche d'identité au-delà des limites de confiance, consultez Architecture de délégation d'identité.

Composants principaux

L'identité de l'agent implique plusieurs composants clés qui, ensemble, permettent de sécuriser l'authentification et l'autorisation.

Identité basée sur SPIFFE

Chaque agent se voit attribuer une chaîne d'identité unique, ou ID SPIFFE, basée sur la norme SPIFFE. Cette identité est fortement attestée, liée au cycle de vie de l'agent et mappée directement à l'URI de la ressource où l'agent est hébergé.

L'identité suit le format suivant :

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Exemple :

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Lorsqu'une identité d'agent est utilisée dans une stratégie d'autorisation IAM, l'identifiant du compte principal respecte le format suivant :

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Exemples :

  • Vertex AI Agent Engine (organisation) : principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (projet sans organisation) : principal://agents.global.proj-9876543210.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Gemini Enterprise : principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

Les identifiants utilisent les éléments suivants :

  • TRUST_DOMAIN : domaine de confiance de votre hiérarchie de ressources :
    • Pour les projets d'une organisation : agents.global.org-ORGANIZATION_ID.system.id.goog
    • Pour les projets sans organisation : agents.global.proj-PROJECT_NUMBER.system.id.goog
  • SERVICE : nom court du service Google Cloud (par exemple, aiplatform ou discoveryengine).
  • RESOURCE_PATH : chemin d'accès complet à la ressource qui héberge l'agent.

Étant donné que l'agent lui-même est le compte principal, vous accordez des autorisations directement à cet identifiant pour contrôler les ressources auxquelles l'agent peut accéder.

Cycle de vie des identités et des autorisations

Vous devez gérer les liaisons IAM pour vos identités d'agent. La suppression d'un agent ne supprime pas les liaisons IAM qui font référence à son compte principal. Ces liaisons restent dans vos stratégies en tant qu'autorisations inactives, et vous devez les supprimer manuellement lors de la mise hors service d'un agent.

L'identité d'un agent est dérivée de l'ID de la ressource qui l'héberge, par exemple l'ID de ressource reasoningEngines. Si vous supprimez un agent et déployez un agent de remplacement, même avec le même nom à afficher, le même code et la même configuration, le nouvel agent reçoit un nouvel ID de ressource et donc un nouvel identifiant de compte principal. Les liaisons IAM existantes qui faisaient référence à l'ancienne identité ne s'appliquent pas au nouveau compte principal. Vous devez attribuer les rôles requis au nouveau compte principal.

Identifiants de l'agent

Les identifiants d'agent fournissent une preuve cryptographique de l'identité d'un agent. Le système est compatible avec les certificats X.509, les jetons d'accès Google Cloud et les jetons d'ID OIDC. Un certificat X.509 est provisionné et géré automatiquement sur l'agent pour renforcer l'authentification.

Ces certificats X.509 sont associés à une autorité de certification racine gérée par Google. Vous pouvez afficher les certificats CA publics par défaut aux points de terminaison suivants :

Par défaut, les identités d'agent utilisent le protocole TLS mutuel (mTLS) avec des certificats X.509 lorsqu'elles communiquent directement avec les API Google Cloud . Lorsque les agents interagissent via Agent Gateway, ils utilisent également le protocole DPoP (Demonstrating Proof of Possession), qui crée des identifiants à double liaison pour une sécurité de bout en bout. Cette double liaison signifie que les agents s'authentifient à l'aide de mTLS pour l'accès first party à la passerelle et utilisent DPoP pour les interactions au-delà de la passerelle.

gestionnaire d'authentification Agent Identity

Le gestionnaire d'authentification Agent Identity est un coffre-fort d'identifiants et un agent d'authentification centralisés qui simplifient l'authentification des outils sortants pour vos agents. Il permet aux agents de s'authentifier à l'aide d'une clé API ou d'un ID client et d'un secret OAuth, ou au nom d'un utilisateur via la délégation OAuth à l'aide de jetons d'accès de l'utilisateur final. Dans le gestionnaire d'authentification, vous configurez des fournisseurs d'authentification qui définissent le type d'authentification et les identifiants pour des applications tierces spécifiques.

L'accès au gestionnaire d'authentification Agent Identity est régi par IAM, et l'agent utilise son propre ID SPIFFE d'agent pour s'authentifier auprès du gestionnaire d'authentification. Tous les événements d'accès des utilisateurs finaux sont également attribuables à l'ID SPIFFE de l'agent, ce qui facilite la gouvernance.

Le gestionnaire d'authentification Agent Identity automatise l'acquisition des identifiants OAuth, par exemple en ouvrant une boîte de dialogue pour la connexion et le consentement de l'utilisateur. Il offre également une visibilité sur l'accès des utilisateurs finaux et permet de révoquer l'accès, ce qui garantit une meilleure gouvernance des autorisations déléguées par l'utilisateur.

Pour en savoir plus, consultez la présentation du gestionnaire d'authentification Agent Identity.

Sécurité et gouvernance

L'identité de l'agent est entièrement intégrée aux systèmes de règles de Google tels qu'IAM, la limite d'accès des principaux (PAB) et VPC Service Controls, qui permettent d'améliorer la sécurité et la gouvernance. Il s'intègre également à la journalisation d'audit pour garantir la responsabilité et fournir des journaux d'audit clairs, à la fois lorsque l'agent agit en son nom propre et lorsqu'il agit au nom d'un utilisateur final.

  • Accès contextuel : par défaut, une règle d'accès contextuel gérée par Google permet de sécuriser les identifiants de l'agent en appliquant la liaison de jetons mTLS et DPoP. Cette approche garantit que les jetons liés à un certificat ne peuvent pas être rejoués en dehors de leur environnement d'exécution de confiance.
  • Intégration d'IAM : compatibilité avec les stratégies d'autorisation et de refus IAM standards.
  • Limite d'accès des principaux (PAB) : une stratégie de limite d'accès des principaux limite les ressources auxquelles un agent peut accéder, quelles que soient les autres autorisations dont il dispose. Les stratégies de limite d'accès des principaux appliquées à l'identité de l'agent sont évaluées dans le cadre des appels sortants (egress). Les identités d'agent soumises à des stratégies Limite d'accès des principaux ne sont autorisées à accéder qu'aux ressources spécifiées dans ces stratégies, ce qui isole strictement l'agent dans la limite désignée.
  • VPC Service Controls : compatibilité avec la protection du périmètre et l'utilisation du compte principal :
    • Protection du périmètre : vous pouvez ajouter l'API Agent Identity (agentidentity.googleapis.com) et l'API Agent Identity Credentials (agentidentitycredentials.googleapis.com) à un périmètre de service pour contrôler l'accès à ces API. Pour utiliser ces API dans un périmètre de service, les clients doivent acheminer les requêtes via l'adresse IP virtuelle restreinte (restricted.googleapis.com).
    • Règles d'entrée et de sortie : compatibilité avec l'utilisation d'identités d'agent en tant que comptes principaux dans les règles d'entrée et de sortie pour autoriser l'accès aux ressources protégées par un périmètre de service.

Fonctionnement de l'identité de l'agent

L'identité de l'agent authentifie et autorise les actions de l'agent via un workflow conçu pour renforcer la sécurité :

  1. Attribution d'identité : lorsque vous déployez un agent, Google Cloudlui attribue une identité SPIFFE unique et un certificat X.509. Chaque certificat X.509 est valide pendant 24 heures, et Google Cloudle maintient automatiquement à jour pour assurer la sécurité.
  2. Acquisition des identifiants : la méthode utilisée par les agents pour acquérir des identifiants dépend de ce à quoi ils tentent d'accéder. Voici quelques exemples :
    • Accéder aux services Google Cloud  : l'agent demande un jeton d'accès lié. Ce jeton est lié par cryptographie au certificat X.509 unique de l'agent pour empêcher le vol de jetons. Pour en savoir plus, consultez Sécurité et gouvernance.
    • Accéder à des outils externes : pour s'authentifier directement auprès d'un service externe à l'aide de sa propre identité, l'agent demande un jeton d'ID OIDC. Pour récupérer les identifiants stockés (tels que les clés API ou les jetons OAuth) auprès d'un fournisseur d'authentification, l'agent utilise le gestionnaire d'authentification Agent Identity, qui accepte à la fois l'autorité déléguée par l'utilisateur et l'autorité propre de l'agent.

Avantages d'Agent Identity

L'identité d'agent améliore la sécurité par rapport aux comptes de service standards.

  • Isolation forte : contrairement aux comptes de service, les identités d'agent ne sont pas partagées par plusieurs charges de travail par défaut, ne peuvent pas être empruntées et ne permettent pas aux développeurs de générer des clés de compte de service de longue durée.
  • Sécurité des identifiants : les règles d'accès contextuel par défaut rendent les jetons liés non rejouables, ce qui contribue à protéger contre le vol de jetons et la prise de contrôle de compte.
  • Approche du moindre privilège : fournit des identités par agent au lieu de comptes de service partagés pour éliminer les agents disposant d'autorisations excessives.
  • Moins de frictions : automatise les flux OAuth complexes et gère les clés API pour simplifier l'intégration des outils.
  • Observabilité améliorée : fournit des journaux d'audit clairs. Lorsqu'un agent agit au nom d'un utilisateur, les journaux affichent l'identité de l'agent et celle de l'utilisateur.

Limites

  • Anciens rôles de bucket Cloud Storage : vous ne pouvez pas attribuer d'anciens rôles de bucket aux identités d'agent (par exemple, storage.legacyBucketReader).

Étapes suivantes