Identités d’agents IA : Google Cloud généralise son gestionnaire d’accès

Google Cloud a annoncé la disponibilité générale de son gestionnaire d’authentification Agent Identity et des API associées. Cette évolution répond à un problème devenu central : lorsqu’un agent agit sur plusieurs outils, il ne devrait ni réutiliser aveuglément les identifiants d’un utilisateur ni conserver des secrets permanents dans son code.

Un agent a besoin d’une identité propre

Les applications traditionnelles distinguent déjà les comptes humains, les comptes de service et les charges de travail. Les agents ajoutent une difficulté : ils peuvent être créés dynamiquement, agir au nom d’une personne, utiliser plusieurs outils au cours d’une même tâche et conserver un état pendant une durée variable. Une simple clé d’API copiée dans une variable d’environnement ne décrit ni qui a demandé l’action ni ce que l’agent était autorisé à faire.

Google présente Agent Identity comme une identité cryptographique fortement attestée, liée au cycle de vie de la ressource qui héberge l’agent. Le gestionnaire d’authentification agit ensuite comme un coffre centralisé et un courtier pour les connexions sortantes vers des services tiers.

Trois modes d’authentification couverts

Le service prend en charge l’OAuth à trois acteurs, lorsque l’utilisateur doit consentir à l’accès de l’agent à un service ; l’OAuth à deux acteurs, adapté aux échanges de service à service ; et les clés d’API, encore utilisées par de nombreux outils. L’intérêt d’un courtier central n’est pas seulement de stocker les secrets. Il permet de normaliser leur attribution, leur rotation et leur utilisation sans les exposer directement à tous les composants.

Les API agentidentity.googleapis.com et agentidentitycredentials.googleapis.com remplacent l’ancienne API IAM Connectors pour la gestion des fournisseurs d’authentification et des identités d’agents. Google avait prévu une phase de migration pendant laquelle les ressources existantes étaient reflétées dans la nouvelle hiérarchie afin de déplacer progressivement les politiques et les applications.

Pourquoi une identité par agent améliore l’audit

Avec un compte partagé, les journaux indiquent seulement qu’une application générique a utilisé une ressource. Avec une identité distincte, il devient possible de relier une opération à un agent, à son environnement et à la politique qui lui a accordé l’accès. Cela facilite l’analyse d’un incident et l’application du moindre privilège.

Cette granularité est particulièrement utile pour les agents spécialisés. Un agent de support peut lire une base documentaire et créer un brouillon de réponse sans modifier la facturation. Un agent commercial peut enrichir un CRM sans accéder aux secrets d’infrastructure. Un agent de développement peut ouvrir une demande de fusion sans posséder les droits de déploiement en production.

Le coffre de secrets ne suffit pas : il faut limiter la délégation

Une architecture sûre doit distinguer l’identité de l’agent, celle de la personne qui lance la tâche et l’identité effectivement utilisée auprès de l’outil. La délégation doit rester explicite. Un utilisateur autorisé à consulter une donnée ne devrait pas automatiquement permettre à tous les agents de son organisation de la lire.

Il faut aussi définir la durée et la portée des jetons. Les identifiants éphémères réduisent les conséquences d’une fuite, tandis que les autorisations ciblées évitent qu’une tâche limitée dispose d’un accès global. Lorsqu’un outil ne propose qu’une clé statique, le courtier peut améliorer le stockage et la rotation, mais il ne peut pas inventer une granularité que le service distant ne fournit pas.

Les garde-fous d’organisation deviennent disponibles

Google Cloud a également rendu disponibles les contraintes personnalisées d’Organization Policy sur les ressources Agent Identity ainsi que l’intégration avec VPC Service Controls. Une organisation peut encadrer la création ou la modification des fournisseurs d’authentification, placer les API dans un périmètre de service et préciser les règles d’entrée et de sortie qui concernent les identités d’agents.

Ces contrôles rapprochent les agents des pratiques habituelles de gouvernance cloud. Ils permettent aux équipes plateforme et sécurité d’établir des règles communes, plutôt que de laisser chaque prototype inventer son propre stockage de secrets.

Une méthode de mise en œuvre progressive

1. Inventorier les actions : lister les outils appelés, les données consultées et les modifications possibles.
2. Séparer les rôles : créer des identités différentes pour les agents qui n’ont pas les mêmes responsabilités.
3. Réduire les autorisations : accorder seulement les opérations nécessaires, sur les ressources nécessaires.
4. Raccourcir la durée : privilégier les jetons temporaires et révoquer l’accès lorsque l’agent disparaît.
5. Tracer le contexte : conserver l’identité de l’utilisateur initiateur, la tâche, l’outil et le résultat.
6. Tester les détournements : simuler une injection de prompt, un outil compromis et une tentative d’accès hors périmètre.

Ce que doit encore décider l’application

Agent Identity gère l’authentification ; il ne remplace pas les règles métier de l’application. Le fait qu’un agent soit reconnu ne signifie pas que toutes ses demandes doivent être acceptées. Les opérations irréversibles ou financières peuvent nécessiter une validation humaine, un double contrôle ou une politique contextuelle.

Il faut également penser à la confidentialité des journaux. Une trace d’audit utile décrit l’action et son résultat, mais ne doit pas recopier un jeton, un document sensible ou l’intégralité d’un prompt contenant des données personnelles. La qualité de l’observabilité dépend autant de ce que l’on exclut que de ce que l’on conserve.

Un socle pour industrialiser sans banaliser le risque

Les premiers prototypes d’agents commencent souvent avec une clé partagée parce que c’est le chemin le plus court. Cette solution devient fragile dès que le nombre d’outils, d’utilisateurs et d’environnements augmente. La disponibilité générale d’un service d’identité dédié montre que l’écosystème passe progressivement de la démonstration à l’exploitation gouvernée.

Pour une entreprise, le bénéfice ne tient pas seulement à un produit cloud précis. Il réside dans le modèle d’architecture : une identité vérifiable par agent, un courtier de secrets, des jetons limités, des règles centrales et une piste d’audit. Ces principes restent valables quel que soit le fournisseur choisi.

Consulter les notes de version IAM de Google Cloud ↗ · Préparer une architecture d’agents maîtrisée avec SDX →