Lorsqu’un agent d’intelligence artificielle crée un réseau virtuel, des bases de données ou un répartiteur de charge, le problème ne prend pas fin avec l’achèvement de la tâche. La ressource peut rester en fonctionnement, consommer le budget et nécessiter une maintenance, tandis que l’étiquette de propriété renvoie à une identité automatisée telle que deploy-agent, et non à une personne que l’on peut contacter ou tenir responsable de la ressource.
L’article présente cette question comme une lacune de gouvernance dans l’infrastructure cloud : l’identité d’exécution qui a créé la ressource n’en est pas nécessairement le propriétaire réel. Avec l’augmentation du nombre d’agents et la rapidité de leurs créations, les mécanismes traditionnels de propriété fondés sur les employés deviennent insuffisants.
Détecter les ressources appartenant à des agents
La première étape consiste à inventorier les ressources portant une étiquette de propriétaire, puis à comparer la valeur de cette étiquette avec l’annuaire des identités de l’organisation. Dans AWS et Azure, il est possible de faire correspondre l’étiquette avec les journaux des rôles ou les entités de service d’origine. Dans Google Cloud, l’article propose de vérifier que la valeur du propriétaire figure dans l’annuaire des employés ; si ce n’est pas le cas, il ne s’agit pas d’une identité humaine selon la règle de contrôle utilisée.
L’apparition d’une identité automatisée ne signifie pas que la ressource est illégitime ; l’automatisation peut avoir été conçue pour exploiter l’infrastructure au nom de l’organisation. Mais ce contrôle réduit le périmètre de l’audit aux ressources qui nécessitent réellement l’attribution d’un propriétaire humain.
Qu’est-ce qui change concrètement ?
Au lieu d’accepter automatiquement comme propriétaire la personne ou le compte ayant exécuté le plan de déploiement, la politique d’approbation devrait vérifier l’étiquette de propriété elle-même. La règle proposée est qu’aucun déploiement ne soit autorisé si la ressource pouvant être étiquetée n’a pas de propriétaire, si la valeur du propriétaire n’est pas au format d’une adresse e-mail personnelle ou si elle correspond à l’une des identités d’agents connues.
L’article recommande de conserver la liste des identités d’agents dans un fichier JSON transmis au moteur de politiques. En l’absence de cette liste, la politique échoue de manière restrictive au lieu d’autoriser le déploiement sans contrôle. Il met également en garde contre l’utilisation de clés API dotées de privilèges administratifs ; il propose d’attribuer à chaque agent une clé de type User au sein d’une équipe distincte, avec des privilèges limités sur l’environnement dans lequel il opère, tout en évitant les jetons partagés.
Définir la fin de vie des environnements
Les politiques de déploiement ne suffisent pas à traiter les anciennes ressources déjà créées par les agents. L’article propose donc d’utiliser une durée d’expiration pour l’environnement, une personne créant l’environnement et définissant sa durée de vie, tandis que l’agent exécute le déploiement à l’intérieur de celui-ci. Ainsi, les alertes d’expiration parviennent à une partie humaine capable d’agir, plutôt qu’à une identité automatisée qui ne possède pas de boîte aux lettres.
L’article indique que env zero avertit le créateur de l’environnement avant sa destruction automatique à deux échéances : deux jours, puis deux heures et trente minutes. Il mentionne également un modèle chez Axiom qui supprime automatiquement le compte s’il n’est pas revendiqué dans les 24 heures.
Pourquoi cette information est-elle importante ?
L’article relie l’ampleur du problème à la multiplication du nombre d’agents au sein des organisations. Selon l’enquête de Gravitee pour 2026, le nombre moyen d’agents d’entreprise a presque doublé en quatre mois, entre décembre 2025 et avril 2026, tandis que plus d’un tiers des organisations exploitaient plus de 100 agents. Des enquêtes menées par Larridin ont également relevé une moyenne de 47 agents dans les environnements d’entreprise sans propriétaire désigné.
L’enquête devient encore plus difficile lorsque les agents utilisent un compte de service partagé ; le journal peut prouver la création de la ressource, mais il n’indique pas quelle exécution, quelle demande ou quelle décision y a conduit. L’attribution explicite d’un propriétaire humain ne permet donc pas seulement de traiter les coûts : elle comble également une partie de la lacune en matière de responsabilité dans les journaux d’audit.
Les limites restantes sont également claires : l’efficacité de ces contrôles dépend de l’exactitude des annuaires d’identités, du fait que les agents ne contournent pas les politiques d’autorisation et de l’existence d’une définition organisationnelle stable de la personne qui possède réellement la ressource. La source elle-même est un contenu pédagogique sponsorisé par env zero ; ses recommandations concernant les produits doivent donc être considérées comme des solutions proposées, et non comme l’unique référence du marché.