Google attribue une identité cryptographique à chaque agent IA : ce que ça change pour les DPO européens
Le 22 avril 2026, lors de la conférence Cloud Next 26 à Las Vegas, Google Cloud a dévoilé sa nouvelle Gemini Enterprise Agent Platform : chaque agent IA déployé dans l'environnement de l'entreprise se voit désormais attribuer un identifiant cryptographique unique, rattaché à des politiques d'autorisation « traçables et auditables ». Pour les DPO et RSSI européens, ce changement de paradigme dépasse largement l'écosystème Google : il pose les fondations techniques d'une gouvernance des agents IA enfin compatible avec l'article 32 du RGPD et avec les exigences du règlement IA.
Ce qui s'est passé
L'annonce porte le nom d'Agent Platform, le nouveau hub de gestion des agents IA — qu'ils soient développés par Google ou par des éditeurs tiers. Au cœur du dispositif, trois briques techniques structurantes :
- Un identifiant cryptographique unique attribué à chaque agent et invoqué pour chaque action exécutée, mappé sur des politiques d'autorisation « traçables et auditables ».
- Un Agent Registry, bibliothèque centrale qui indexe chaque agent interne, chaque outil et chaque compétence déployés dans l'organisation.
- Un Agent Gateway, point unique d'application des politiques de sécurité pour l'ensemble des interactions agent-à-agent et agent-à-outil, compatible avec les protocoles de référence du marché (Model Context Protocol et Agent2Agent).
Thomas Kurian, CEO de Google Cloud, a résumé l'ambition lors de sa keynote : « Nous apportons la vérification zero trust à chaque agent et à chaque étape d'orchestration. » L'éditeur ajoute deux capacités de surveillance : Agent Anomaly Detection, qui combine modèles statistiques et LLM-as-a-judge pour détecter en temps réel les comportements suspects, et un Agent Security Dashboard adossé au Security Command Center, qui cartographie les relations entre agents et modèles.
Pourquoi c'est important — les identités non humaines deviennent un sujet RGPD
Jusqu'ici, les identités non humaines (NHI) connues des équipes sécurité — clés API, comptes de service — étaient déterministes. Un agent IA, lui, est autonome : il décompose un objectif en étapes et exécute des actions sur plusieurs applications sans validation humaine intermédiaire. Cette différence de nature appelle une différence de traitement, à la fois en sécurité et en conformité.
Côté juridique, le sujet n'est pas neuf en Europe. Trois avocats de Norton Rose Fulbright dénonçaient en avril 2026 « l'approche sparadrap » consistant à empiler des contrôles a posteriori plutôt qu'à coder la gouvernance dans le système : leur checklist en sept questions appelait précisément à intégrer l'identité, l'auditabilité et la révocabilité dès la conception. La CNIL, de son côté, a déjà fait la démonstration que les agents IA qui décident à la place des humains engagent la responsabilité juridique de l'entreprise qui les déploie — quatre affaires (Amazon, Uber, Air Canada, plateforme de livraison française) le rappellent.
Le rapprochement avec le droit européen est direct. L'article 32 RGPD impose des « mesures techniques et organisationnelles appropriées » pour garantir la sécurité et la traçabilité des traitements ; un agent qui agit sans identité propre rend cette traçabilité quasi impossible. Le règlement IA, lui, exige pour les systèmes à haut risque une journalisation et un contrôle humain effectif que seule une identification fine des agents peut techniquement réaliser. Sans oublier la doctrine ANSSI : le bulletin CERTFR-2026-ACT-016 déconseille formellement le déploiement en production des agents IA autonomes tant que ces garde-fous ne sont pas en place.
Ce que ça change pour les organisations européennes
Même si vous n'êtes pas client Google Cloud, le standard que pose l'éditeur va peser sur vos audits, vos appels d'offres et vos AIPD. Quatre chantiers à ouvrir dès maintenant :
- Cartographier votre fleet d'agents IA — humains comme « shadow IT IA ». Sans inventaire exhaustif, impossible d'attribuer une identité, donc impossible d'auditer. Le concept d'Agent Registry de Google peut servir de canevas : un agent, une fiche, une politique, un propriétaire fonctionnel.
- Réviser vos AIPD sur les traitements impliquant des agents autonomes. La méthodologie AIPD en cinq étapes doit désormais intégrer une question explicite : qui est l'agent, comment ses actions sont-elles tracées, comment sont-elles révocables ?
- Durcir vos questionnaires sécurité fournisseurs. Si votre éditeur ne peut produire la liste des agents qu'il déploie chez vous, leurs identifiants et leurs politiques d'autorisation, vous êtes en zone grise au regard de l'article 32. Les cadres NIS 2 et DORA imposent par ailleurs cette transparence pour les opérateurs concernés.
- Désigner une autorité interne de gouvernance des agents IA. Le règlement IA impose en France une articulation avec plusieurs régulateurs — le guide Leto sur les autorités compétentes pour l'AI Act détaille cette répartition. Dans l'organisation, le DPO et le RSSI doivent piloter conjointement, sous peine de retomber dans la « gouvernance sparadrap » dénoncée par les juristes.
Ce que Leto pense de cette décision
L'annonce de Google Cloud est moins une révolution technologique qu'une mise en conformité anticipée avec les exigences européennes. C'est exactement le mouvement qu'attendaient les régulateurs : faire de l'identité de l'agent le point d'ancrage de la conformité, plutôt que de bricoler des contrôles a posteriori. Reste deux angles morts. D'abord, l'identité cryptographique ne dit rien de la légitimité de l'action de l'agent — c'est toujours au DPO de qualifier la base légale et la finalité. Ensuite, la traçabilité offerte par un éditeur reste sa traçabilité : la portabilité des journaux d'audit vers vos propres SIEM et registres de traitements doit figurer noir sur blanc dans vos contrats. Sans cette clause, vous achetez une promesse de transparence que vous ne pourrez pas opposer à votre autorité de contrôle en cas d'incident.
Sources :
