Rien n'a été pirqué. Tout a été emporté.

Confiez à un agent IA une clé AWS fuiteée — le genre à faibles privilèges, jetable, qu'un pipeline CI répand chaque semaine — et dites-lui de prendre ce qu'il peut atteindre. Puis éloignez-vous. Plus souvent qu'autrement, environ une minute plus tard et sans personne au clavier, il lit vos données clients.

Rien n'a été piraté pour y parvenir. Pas d'exploit, pas de CVE, pas de serveur non corrigé. Chaque identifiant qu'il a touché était valide ; chaque appel d'API était un appel qu'AWS est conçu pour servir. Pendant trente ans, une clé fuiteée n'était que le début d'une attaque — la partie lente à laquelle un humain devait être éveillé, l'intervalle dans lequel vivent les équipes de sécurité et où la rotation rapide gagne la course. Cet intervalle vient de s'effondrer à environ une minute.

En mai 2026, un chercheur nommé Adan Álvarez a réalisé un test simple. Il a pris une seule clé AWS à faibles privilèges — le genre qu'un pipeline CI/CD fuite en permanence — et l'a remise à un agent de code IA avec une seule instruction : agis comme un pentester, trouve ce que tu peux atteindre. Aucun humain au clavier ensuite. L'agent a fait le reste. Plus de la moitié du temps, il a parcouru toute la chaîne jusqu'aux données clients — en environ une minute, sans surveillance.

Ce qui s'est réellement passé

La configuration était délibérément ordinaire. La clé fuiteée appartenait à un utilisateur de build à faibles privilèges. À elle seule, elle ne pouvait pas toucher aux données clients. Mais elle pouvait lire un fichier d'état Terraform. Ce fichier d'état contenait un second jeu de clés. Ces clés pouvaient endosser un rôle. Ce rôle pouvait lire le bucket clients.

C'est ainsi qu'est structuré presque tout compte cloud réel — non pas une seule muraille, mais une chaîne de petites relations de confiance raisonnables, dont chaque maillon est sensé pris isolément. Un attaquant humain démêle cette chaîne lentement, à la main. L'agent l'a démêlée en environ soixante secondes.

Les exécutions réussies ont suivi les mêmes six étapes à chaque fois : confirmer à qui appartient la clé, lister ce qu'elle a le droit de faire, récupérer le second jeu d'identifiants depuis le bucket de staging, endosser le rôle privilégié, trouver les données, les emporter. Sur douze exécutions avec deux modèles, sept sont allées jusqu'à l'exfiltration. La plupart se sont terminées en environ une minute [1].

Et il ne s'agit pas seulement d'un résultat de laboratoire. En novembre 2025, l'équipe de recherche sur les menaces de Sysdig a vu la même forme se produire en conditions réelles : des clés AWS valides exposées dans un bucket public, une fonction Lambda réécrite discrètement pour fabriquer des identifiants administratifs, un mouvement latéral à travers dix-neuf identités distinctes — le tout en huit minutes [2][3]. Le code injecté portait les empreintes d'un modèle : gestion d'exceptions soignée, logique de ciblage itérative, commentaires dans plusieurs langues.

Ce n'est pas une faille d'AWS

Voici la partie qui devrait vous tenir éveillé : rien n'a été piraté.

Pas d'exploit. Pas de CVE. Pas de dépassement de tampon, pas de serveur non corrigé. Chaque identifiant était valide. Chaque appel d'API était un appel qu'AWS est conçu pour servir. Comme l'a résumé Sysdig, les identifiants étaient légitimes et les API ont été utilisées exactement comme prévu [3]. AWS a parfaitement fait son travail.

L'hypothèse qui a cédé n'était pas la sécurité d'AWS. C'était une hypothèse plus ancienne, plus discrète, en dessous : qu'une clé fuiteée n'est dangereuse que dans la mesure de l'attention qu'un attaquant peut lui consacrer. Pendant trente ans, cela a tenu. Exploiter un identifiant prenait un humain — du temps, de l'expérience, de la patience. Ce coût faisait réellement partie de votre défense, même si personne ne l'a jamais dessiné sur le schéma d'architecture.

Les agents réduisent ce coût à peu près à zéro. La patience est infinie. L'expertise se loue à la minute. L'attaquant peut dormir.

Ce n'est pas qu'AWS

Rien ici n'est propre à Amazon. La même chaîne se déroule partout où un identifiant peut servir à découvrir l'identifiant suivant : une clé cloud qui peut lister ses propres permissions, un jeton dans un fichier .env qu'un autre processus peut lire, un secret dans un fichier d'état, un jeton de coffre-fort posé sur le disque à côté du code. Tout harness — un agent de code, un serveur MCP installé la semaine dernière — peut être l'élément qui remonte la chaîne, avec ou sans votre bénédiction.

Le fil conducteur est que le secret porte son propre rayon d'impact. Il peut être lu là où le travail s'effectue, il peut énumérer ce qu'il touche, et il fonctionne depuis n'importe où. Ces trois propriétés étaient survivables lorsque les attaques étaient lentes et manuelles. Elles ne le sont pas à la vitesse des agents.

Conçu pour cela, délibérément

Nous avons donc construit l'inverse, délibérément.

Un identifiant Clavitor n'est accessible que par le nom qui a été donné à l'agent — il ne peut pas lister le coffre, il ne peut donc pas en tracer la carte. La valeur du secret n'atterrit jamais là où le code s'exécute ; l'agent obtient le résultat de l'utilisation de l'identifiant, pas l'identifiant lui-même. Chacun est lié à la machine et au périmètre pour lesquels il a été émis, de sorte qu'une copie emportée sur un portable est inutilisable. Et chaque requête est inscrite dans un journal immuable, chaîné par hachage, hors de l'extrémité concernée — les preuves demandées par PCI DSS Req 10 et NIST 800-171 (3.3.8) — afin qu'une action parfaitement « valide » ait elle aussi un nom associé.

Voici la limite honnête : cela ne rend pas un identifiant fuiteé inoffensif. Limitez une clé à un bucket, et si cette clé fuite, un attaquant obtient ce bucket-là. Ce que cela tue, c'est la chaîne — la partie où une clé ordinaire devient la carte de tout le reste. Périmètre délimité contre périmètre ambiant, ce n'est pas la différence entre sûr et compromis. C'est la différence entre un incident et une catastrophe.

Nous avons noté la poignée de règles qu'un outil de gestion d'identifiants doit respecter s'il veut survivre à cela. Vous pouvez évaluer le vôtre point par point sur clavitor.ai/rules.

La leçon n'est pas « rotation plus rapide »

Vous ne pouvez pas gagner une rotation contre une attaque de soixante secondes. Au moment où l'alerte se déclenche, la chaîne a déjà tourné.

L'enseignement n'est pas un exercice de nettoyage plus strict. C'est que l'économie a basculé. Nous avons construit des systèmes d'identifiants pour un monde où le temps de l'attaquant était rare et coûteux — où une clé fuiteée était une course que l'on pouvait gagner. Ce monde n'existe plus. Un identifiant qui peut trouver l'identifiant suivant n'est plus une commodité. C'est l'attaque entière, pré-écrite, en attendant qu'une clé tombe.

Construisez pour le monde où l'attaquant ne dort jamais. Il est déjà là.

Clavitor (@clavitorai) est le coffre-fort d'identifiants conçu pour les agents IA, et contre eux. clavitor.ai

Sources

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (mai 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AWS Compromised by AI Agents in Minutes" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/