Google Threat Intelligence Group a publié le 8 septembre 2026 un nouveau suivi des menaces décrivant le passage de requêtes isolées à des opérations soutenues par des agents. L'exemple le plus concret concerne un acteur présumé motivé par l'argent. Après avoir compromis un environnement cloud, il aurait utilisé un assistant de programmation IA, un prompt et des fichiers d'instructions préparés pour planifier et exécuter une collecte massive d'identifiants en moins de six heures.
Selon Google, l'agent a géré l'analyse des vulnérabilités, le dépannage et la rotation des adresses IP sans intervention humaine continue. Le rapport décrit aussi un logiciel malveillant qui plaçait des fichiers dans les répertoires de projet utilisés par les assistants, modifiait les mécanismes de démarrage et ajoutait des instructions visant à manipuler les outils IA ou à pousser les scanners de sécurité à interrompre leur analyse.
Il s'agit d'observations de Google et Mandiant, pas d'une mesure exhaustive de l'activité mondiale. Des médias spécialisés indépendants confirment le rapport et ses principaux exemples, mais la télémétrie reste détenue par Google et ne peut pas être reproduite à partir du seul article public.
Le flux d'attaque change davantage que les outils
L'automatisation des cyberattaques n'est pas nouvelle. Le changement important tient au fait qu'un agent a enchaîné plusieurs décisions. Il pouvait maintenir une chaîne d'analyse, résoudre des erreurs, faire tourner l'infrastructure et continuer la collecte tandis que l'opérateur humain restait éloigné de chaque étape.
Cette réduction du délai modifie la défense. Une politique qui attend l'examen manuel de chaque alerte peut être trop lente lorsqu'un seul ensemble d'instructions entraîne plusieurs actions. Les équipes ont besoin de contrôles aux frontières de l'identité, du réseau, des outils et de la tâche, avec un arrêt automatique lorsque le comportement sort du but autorisé.
Google indique que l'acteur travaillait depuis une infrastructure cloud compromise, ce qui donnait au trafic des adresses légitimes et affaiblissait les filtres de réputation simples. Les comptes cloud, quotas de calcul, identifiants de service et abonnements IA deviennent donc des cibles sensibles, pas de simples commodités de développement.
Les fichiers d'instructions entrent dans la surface d'attaque
Le rapport associe un acteur de la chaîne logicielle suivi sous le nom UNC6780 à plusieurs techniques visant les outils IA. Google affirme que cet acteur a publié des copies malveillantes de serveurs MCP, modifié des dossiers cachés utilisés par les assistants et ajouté des commandes susceptibles de s'exécuter à l'ouverture d'un espace de travail.
Le logiciel aurait aussi placé des instructions adverses dans des commentaires de code afin de provoquer un refus des scanners LLM. Cela ne prouve pas que tous les scanners échouent. Google précise que ses protections ont réagi et que des mesures ont été prises contre les campagnes. L'exemple montre néanmoins qu'un refus devient une technique d'évasion si le scanner s'arrête avant d'examiner le code dissimulé dessous.
La confiance dans un dépôt doit dépasser le nom des dépendances. Les équipes devraient examiner les répertoires cachés des agents, les hooks, les instructions de tâches, les flux CI, les définitions MCP et les changements de configuration des éditeurs de confiance. Le guide Maetra sur les contrôles contre l'injection de prompt explique pourquoi une instruction non fiable doit être contrôlée avant d'atteindre un modèle doté d'outils.
Les contrôles doivent résister à la vitesse des agents
Le rapport soutient cinq mesures immédiates:
- Accorder à chaque identité d'agent uniquement les droits nécessaires à sa tâche.
- Bloquer les changements non approuvés dans les instructions, hooks, flux CI et configurations MCP.
- Limiter les sorties réseau des agents et scanners aux destinations requises.
- Détecter les accès inhabituels aux secrets, les rotations rapides d'IP, les nouvelles charges cloud et les journaux supprimés.
- Conserver la proposition, la décision de politique, l'exécution et l'effet final pour l'enquête.
Ces contrôles doivent être reliés. Un filtre de prompt ne compense pas une identité cloud trop privilégiée. Un journal est faible si l'attaquant peut le supprimer avec les mêmes droits que l'agent.
Le guide de sécurité à l'exécution des agents relie prompts, appels d'outils, identifiants et preuves. Pour cette menace, la question centrale est de savoir si un fichier ou un secret compromis peut détourner silencieusement un agent durable.
Ce qui est vérifié et ce qui reste incertain
Google rapporte que la campagne a compromis des milliers d'identifiants tiers et qu'un autre serveur exposé a ensuite géré plus de 23 800 secrets collectés. Ces chiffres doivent rester attribués à Google. Le rapport public ne nomme pas toutes les victimes, ne fournit pas un échantillon complet et n'établit pas la fréquence de tels cadres autonomes dans l'ensemble des incidents.
Il distingue aussi les opérations observées des expériences. Certains groupes ont tenté de concevoir des agents de test offensif, mais Google affirme avoir désactivé les ressources avant d'observer un déploiement réel. Pour les opérations d'information, Google a constaté un intérêt pour des bots interactifs sans voir ces capacités réussir en production.
Le rapport prouve donc l'utilisation d'un agent dans une vraie campagne de collecte d'identifiants. Il ne prouve pas que les agents autonomes dominent désormais la cybercriminalité.
Analyse de Maetra
La leçon principale est que les instructions de tâche forment un contexte de sécurité exécutable. Un fichier AGENTS.md, un dossier d'IDE caché ou une configuration MCP peut influencer un agent aussi directement qu'un prompt. Ces éléments ont besoin de responsables, d'un historique, de règles de revue et de contrôles à l'exécution.
Les équipes devraient définir le résultat autorisé de chaque agent, les outils et destinations permis et les preuves qui confirment l'effet. Un changement de tâche, d'identité, de route réseau ou de confiance du dépôt doit déclencher une nouvelle évaluation plutôt que reprendre une ancienne autorité.
La vitesse des agents sert les deux camps. L'avantage défensif vient de permissions étroites, de limites déterministes, d'une surveillance indépendante et de dossiers qu'un attaquant ne peut pas modifier depuis le contexte de l'agent.