Des clés d'agents IA orphelines restent actives bien après la fin des projets

Alors que les agents d'intelligence artificielle deviennent courants dans les workflows de développement, ils laissent fréquemment derrière eux des clés de gestion des identités et des accès (IAM) actives bien après l'achèvement de leurs tâches. Cela crée une faille de sécurité significative où des identifiants valides existent sans propriétaire ni utilité. Une analyse récente met en évidence comment ces clés orphelines peuvent persister pendant des mois, offrant aux attaquants un potentiel point d'entrée dans les environnements cloud.

Ce qui s'est passé

Un scénario hypothétique mais représentatif illustre le problème central : un utilisateur IAM nommé _research-agent-2 conserve une clé d'accès créée il y a quatorze mois. La clé a été utilisée pour la dernière fois il y a onze mois, mais elle reste active. Le projet qu'elle supportait est clos, et l'employé qui avait approuvé sa création ne travaille plus pour l'entreprise. Contrairement aux employés humains qui déclenchent des procédures de départ lorsqu'ils quittent leur poste, les agents IA terminés cessent simplement de fonctionner, laissant leurs identifiants dans un état de limbo.

Ce problème de cycle de vie n'est pas dû à de la négligence, mais plutôt à une lacune structurelle dans la gestion des identités non humaines. Les clés d'accès des utilisateurs AWS IAM n'expirent pas automatiquement. Par conséquent, une clé oubliée reste valide indéfiniment jusqu'à ce que quelqu'un la désactive ou la supprime manuellement. L'Open Web Application Security Project (OWASP) a classé le manque de déprovisionnement approprié comme le risque principal dans son Top 10 2025 pour les identités non humaines, soulignant la nécessité de retirer les actifs inutilisés et d'assigner des propriétaires responsables à ceux qui restent.

L'urgence de cette question est soulignée par la rapidité des attaques modernes. En septembre 2026, GreyNoise a documenté une campagne orchestrée par IA contre des serveurs PaperCut. Les attaquants sont passés d'un espace de travail vide à l'exécution de code à distance en moins de quatre heures. Une fois lancée, la campagne a compromis au moins onze organisations en seulement vingt-six secondes. Bien que cette attaque spécifique n'ait pas utilisé de clés AWS IAM abandonnées, elle démontre à quelle vitesse un accès exposé devient utile pour les adversaires. Des processus lents d'inventaire et de révocation sont dangereusement inadéquats dans ce contexte.

Détails clés

• Les clés d'accès des utilisateurs AWS IAM n'ont pas de date d'expiration automatique et restent valides jusqu'à leur révocation manuelle.
• Le Top 10 2025 de l'OWASP pour les identités non humaines classe le manque de déprovisionnement approprié comme le risque principal.
• Un rapport GreyNoise de septembre 2026 a montré une attaque pilotée par IA compromettant onze organisations en 26 secondes.
• CloudQuery peut synchroniser les rapports d'identifiants AWS IAM pour aider à identifier les clés inutilisées depuis plus de 90 jours.
• Les paramètres de durée de vie (TTL) de l'environnement peuvent aider à gérer les identifiants jetables, mais ne garantissent pas une révocation immédiate si les destructions échouent.
• Les clés d'accès du compte root nécessitent un audit séparé et urgent, et ne devraient généralement pas exister.

Contexte

Les identités non humaines font référence aux comptes de service, aux bots et aux agents IA qui interagissent avec l'infrastructure cloud. Contrairement aux utilisateurs humains, ces entités n'ont pas d'événements naturels de rotation tels que la démission ou la retraite. Leurs identifiants, tels que les clés d'accès ou les jetons, sont souvent provisionnés pour des tâches spécifiques mais manquent de gestion intégrée du cycle de vie. Lorsque la tâche se termine, l'identifiant peut rester actif s'il n'est pas explicitement décommissionné.

L'inventaire de ces identités est difficile car les fournisseurs cloud ne suivent pas toujours quel agent spécifique a utilisé un compte. Il est nécessaire de corréler l'activité avec les journaux d'audit et les propriétaires nommés pour déterminer si une clé est encore nécessaire. De plus, bien que les plateformes de déploiement puissent appliquer des politiques lors de la création de l'infrastructure, elles ne peuvent pas toujours contrôler les identifiants créés via des consoles ou des scripts externes. Cette distinction entre identité de déploiement et identifiants provisionnés complique les efforts de gouvernance.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre logiciel, les clés orphelines représentent une dette de sécurité silencieuse. Une machine virtuelle oubliée engendre des coûts financiers, mais un identifiant oublié accorde un potentiel accès à des données et systèmes sensibles. Les attaquants n'ont pas besoin de savoir qu'une clé est orpheline pour l'exploiter ; ils ont seulement besoin qu'elle soit valide. À mesure que les agents IA prolifèrent, le volume de ces identités non humaines augmentera, élargissant la surface d'attaque si une gouvernance appropriée n'est pas mise en œuvre.

Les audits annuels manuels sont insuffisants compte tenu de la vitesse des attaques automatisées. Les équipes ont besoin d'une visibilité continue sur l'utilisation des identifiants. Sans requêtes et politiques automatisées, les responsables de la sécurité peuvent rester ignorants des clés actives associées à des projets disparus. Ce décalage entre la clôture du projet et la révocation de l'identifiant crée des fenêtres de vulnérabilité que les attaquants sophistiqués peuvent exploiter rapidement.

De plus, compter uniquement sur les outils d'infrastructure-as-code ne suffit pas. Alors que des outils comme Terraform peuvent gérer la création de clés, ils ne révoquent pas automatiquement les clés si le processus de destruction échoue ou si les clés sont créées en dehors de l'environnement géré. Les équipes doivent vérifier activement la révocation plutôt que de faire confiance aux minuteurs de compte à rebours ou aux scripts de déploiement.

Ce que vous pouvez faire

• Exécutez des requêtes SQL sur les rapports d'identifiants IAM synchronisés pour trouver les clés actives inutilisées depuis plus de 90 jours.
• Implémentez des politiques d'approbation dans les plateformes de déploiement pour bloquer la création d'identifiants longue durée dans les plans Terraform ou OpenTofu.
• Préférez la fédération basée sur OIDC pour les déploiements afin d'utiliser des identifiants temporaires qui expirent avec la session.
• Définissez des TTL d'environnement pour les identifiants jetables, mais vérifiez la révocation réelle via des contrôles d'état.
• Désactivez d'abord les clés suspectes pour surveiller les erreurs d'authentification avant de les supprimer définitivement.
• Attribuez des propriétaires explicites à toutes les identités non humaines et enregistrez la propriété dans votre inventaire d'identifiants.

La section de conclusion apparaît ci-dessous.