Le rapport de Google sur les cybermenaces liées à l’IA avertit que les attaquants réduisent l’écart de capacités

Google a documenté des attaquants ayant mis en place et exécuté une campagne massive de collecte d’identifiants en six heures, malgré l’absence des ressources habituellement associées aux opérations soutenues par des États.

Le rapport de Google sur les cybermenaces liées à l’IA décrit une évolution, d’une assistance ponctuelle par chatbot vers des flux de travail autonomes et multi-agents. Ces systèmes peuvent gérer l’analyse, résoudre les échecs, faire tourner l’infrastructure et collecter des identifiants avec une implication humaine limitée.

Cette distinction compte davantage que la capacité de l’IA à inventer des techniques d’attaque entièrement nouvelles. Les groupes criminels peuvent désormais coordonner des techniques connues à une vitesse et à une échelle qui exigeaient autrefois des équipes plus importantes, des opérateurs spécialisés et une infrastructure conséquente.

Le Google Threat Intelligence Group, ou GTIG, a fondé son rapport du 8 septembre sur les enquêtes de Mandiant, le suivi des menaces et l’activité observée sur les plateformes de Google. Ses conclusions placent des criminels motivés par l’appât du gain aux côtés de groupes liés aux États chinois, iranien, russe et nord-coréen qui utilisent l’IA tout au long de leurs opérations cyber.

La confrontation n’oppose plus simplement l’IA des attaquants à celle des défenseurs. Elle oppose une offensive automatisée à des processus de réponse humains qui dépendent encore de files d’attente, de transmissions et de revues planifiées.

Le rapport de Google sur les cybermenaces liées à l’IA documente une attaque de six heures

Le changement le plus manifeste est opérationnel : les agents d’IA passent de rôles consultatifs à la boucle d’exécution.

Au deuxième trimestre 2026, Mandiant a enquêté sur un acteur présumé motivé par l’appât du gain qui avait compromis l’infrastructure cloud d’une organisation. L’attaquant a déployé un cadre autonome comprenant plusieurs agents, chacun prenant en charge une partie d’une opération de collecte d’identifiants.

Selon Google, l’acteur a fourni à un chatbot d’IA dédié au code un prompt et un ensemble d’instructions destinées aux agents. Ces instructions servaient de guides opérationnels réutilisables.

En six heures, le cadre a planifié, construit et exécuté une campagne massive de collecte d’identifiants. Il a compromis des milliers d’identifiants tiers, selon GTIG.

Les agents n’ont pas seulement généré des scripts. Ils ont géré un pipeline d’analyse des vulnérabilités, diagnostiqué les erreurs et pris en charge la rotation des adresses Internet Protocol sans directives continues de l’opérateur.

Cette automatisation a réduit la latence humaine dans la boucle, c’est-à-dire le temps d’attente créé chaque fois qu’un logiciel a besoin qu’une personne approuve ou corrige son action suivante. Elle a également aidé l’attaquant à maintenir son activité sur un vaste ensemble de cibles.

L’environnement cloud compromis offrait un autre avantage. Le trafic d’attaque pouvait transiter par des adresses IP légitimes associées à l’infrastructure de la victime, compliquant les détections simples fondées sur la réputation.

GTIG a également découvert un serveur de commande et contrôle exposé, exécutant un cadre automatisé de reconnaissance et de gestion d’identifiants appelé Recon. Ce cadre contenait des fichiers d’instructions et de connaissances conçus pour un fonctionnement agentique.

Son répertoire comprenait des fichiers tels que AGENTS.md, KNOWLEDGE.md et agentic_vuln_research.md. Il contenait également des répertoires modulaires pour les outils, la mémoire et les flux de travail automatisés.

Après que GTIG a détecté le serveur exposé, le répertoire serait devenu un tableau de bord de production. Ce tableau de bord pouvait organiser, valider et gérer plus de 23 800 secrets collectés en temps réel.

Ces secrets comprenaient des identifiants pour des plateformes cloud et des services d’IA. Ce cas reliait donc trois risques que les organisations traitent souvent séparément : le vol d’identifiants, la compromission du cloud et l’accès non autorisé à l’IA.

Google a qualifié l’opération de passage des infostealers passifs sur les terminaux à une collecte agentique offensive. Les agents ont recherché des vulnérabilités, analysé l’infrastructure de serveurs et tenté une exploitation ciblée avec une intervention minimale.

C’est l’avertissement central du rapport de Google sur les cybermenaces liées à l’IA. Un opérateur disposant de ressources modestes peut encoder des instructions une seule fois, puis laisser le logiciel les répéter sur des milliers d’occasions.

Le délai de six heures ne signifie pas que chaque attaquant peut soudainement mener de l’espionnage de haut niveau. Il montre que la capacité d’orchestration, autrefois limitée par les effectifs, peut de plus en plus être louée, volée ou automatisée.

L’automatisation par l’IA change l’horloge des défenseurs

Les équipes de sécurité font désormais face à un problème de timing avant de faire face à une catégorie d’exploit entièrement nouvelle.

La réponse traditionnelle aux incidents suppose que les défenseurs conservent un certain délai entre la reconnaissance, l’exploitation, l’utilisation d’identifiants et le mouvement latéral. Les systèmes de supervision détectent les événements, les analystes les valident et des équipes distinctes coordonnent le confinement.

L’IA agentique compresse ces étapes. Un cadre peut analyser, s’adapter, réessayer et passer à la cible suivante pendant qu’une alerte reste sans examen.

John Hultquist, analyste en chef de GTIG, a déclaré à IT Pro que les organisations devraient supposer que les acteurs de la menace utilisent déjà l’IA d’une manière ou d’une autre. Il a averti que les criminels privilégieront les attaques qui progressent plus vite que les défenseurs ne peuvent répondre.

La pression pèse surtout sur les organisations dont les contrôles de sécurité créent des alertes sans permettre un confinement rapide. Un volume d’alertes plus élevé offre peu de protection lorsque les analystes ne peuvent pas les examiner avant que les identifiants volés ne deviennent des voies d’attaque actives.

Le problème dépasse les centres opérationnels de sécurité. Les équipes chargées des identités, les administrateurs cloud, les développeurs et les mainteneurs open source contrôlent tous des ressources qu’une campagne automatisée peut atteindre.

La rotation des identifiants en fournit un exemple simple. Une organisation peut découvrir un secret exposé en quelques heures, mais exiger plusieurs approbations avant de le révoquer. L’agent d’un attaquant n’a besoin que de quelques secondes pour tester ce secret ailleurs.

L’infrastructure cloud accentue ce déséquilibre. Les identifiants volés peuvent fournir de la capacité de traitement, des emplacements réseau de confiance et l’accès à des services supplémentaires.

GTIG appelle une forme de cette activité LLMjacking. Les attaquants volent des identifiants de plateformes d’IA ou détournent des environnements cloud afin d’exécuter des charges de travail de modèles non autorisées.

Cette pratique permet aux attaquants d’éviter les coûts directs d’infrastructure. Elle peut également masquer leur activité, car le calcul a lieu dans le compte d’une organisation légitime.

En avril 2026, Mandiant a observé un acteur utilisant un accès volé à une infrastructure d’IA pour provisionner des ressources de traitement graphique haute performance. La victime a supporté la charge de travail et les dépenses qui en ont résulté.

Le même schéma est apparu dans une campagne liée à la Chine suivie sous le nom UNC6508. Google indique que le groupe a déployé un modèle local à poids ouverts dans des environnements cloud compromis.

L’exécution locale du modèle a aidé le groupe à éviter la supervision des services commerciaux d’IA. Elle a également transféré la charge de calcul à la victime.

Ces cas poussent les responsables de la sécurité à redéfinir la surface à protéger. Les modèles, prompts, instructions d’agents, identifiants d’API, quotas cloud et outils de développement rejoignent désormais les applications et serveurs conventionnels.

Ronald Lewis, responsable de la gouvernance de la cybersécurité chez Black Duck, a déclaré à IT Pro que ces risques évoluent plus vite que de nombreuses organisations ne peuvent les mesurer et les gouverner. Il a soutenu que les équipes de sécurité doivent protéger les systèmes d’IA tout en faisant face à des attaquants utilisant la même technologie.

Cela crée la confrontation principale : une offensive à la vitesse des machines face à des organisations dont les systèmes de réponse restent organisés autour de décisions à la vitesse humaine.

Les attaquants disposant de moins de ressources peuvent emprunter l’échelle des États

L’IA réduit l’écart de capacités opérationnelles, même si elle n’efface pas les différences d’accès au renseignement, de financement ou de patience stratégique.

Les groupes soutenus par des États conservent traditionnellement des avantages que les logiciels ne peuvent à eux seuls reproduire. Ils peuvent s’appuyer sur des renseignements classifiés, un financement à long terme, une infrastructure sur mesure, une couverture diplomatique et des équipes disposant de connaissances régionales spécialisées.

Toutefois, de nombreuses caractéristiques visibles des opérations avancées proviennent d’une exécution répétable. Elles comprennent une reconnaissance soutenue, du phishing localisé, la modification de code, la rotation de l’infrastructure et le dépannage rapide.

L’IA peut automatiser ou accélérer chacune de ces tâches. Elle donne ainsi aux petits groupes une partie de la portée opérationnelle auparavant associée aux grandes organisations.

La campagne d’identifiants de six heures illustre ce mécanisme. L’attaquant n’avait pas besoin d’un agent pour imaginer un concept d’attaque inédit.

Le cadre a plutôt coordonné des tâches connues sans attendre un opérateur humain à chaque étape. Son avantage reposait sur la persistance, l’activité parallèle et le rétablissement rapide après des erreurs courantes.

Ce modèle modifie la manière dont les défenseurs doivent interpréter la sophistication. Un volume d’attaque élevé, des leurres soignés ou des changements rapides de code ne prouvent plus qu’une grande équipe se trouve derrière une opération.

Un petit groupe peut réutiliser des instructions entre les agents. Il peut aussi orienter différents modèles vers la reconnaissance, le codage, la traduction et l’analyse de données.

Les groupes liés à des États adoptent la même approche. GTIG a observé un acteur chinois d’espionnage expérimenter un pipeline automatisé d’exploitation et de post-exploitation.

L’acteur a utilisé CC Switch, un outil capable d’acheminer le travail entre différents modèles de langage. Google indique qu’il a interrogé Claude, Gemini et Codex pour obtenir des scripts d’exploitation, du contenu de phishing et de l’aide au débogage.

Le flux de travail combinait le sondage manuel avec Burp Suite et une activité automatisée via Phalanx, un cadre open source de tests d’intrusion. Après avoir obtenu l’accès, l’opérateur pouvait déployer des outils supplémentaires pour le commandement et contrôle ainsi que la collecte d’identifiants.

Google a également décrit BASIN CASTLE, un groupe lié à l’État chinois, utilisant l’IA générative au cours de phases d’attaque successives. Ses activités comprenaient le profilage des cibles, la création de leurres localisés, l’obfuscation de logiciels malveillants et le dépannage post-exploitation.

CALANQUE ION, également connu sous le nom d’APT42, a utilisé l’IA pour la reconnaissance, la découverte d’e-mails, la traduction et l’ingénierie sociale, selon GTIG. L’acteur lié à l’Iran s’est également intéressé au développement d’infrastructures et à l’ingénierie inverse de logiciels.

RAVINE CASTLE, un autre groupe lié à la Chine, a utilisé Gemini pour la collecte de renseignements, la recherche d’exploits et les opérations d’influence. Google a observé le groupe étudier des méthodes permettant d’anonymiser des fuites et de les diffuser via des canaux médiatiques.

SANDWORM RELIC, lié à la Russie, a utilisé Gemini pour affiner des scripts de password spraying et automatiser le profilage des hôtes. Le groupe a également exploré un routage par proxy conçu pour dissimuler l’infrastructure de commande et contrôle.

Des clusters nord-coréens ont utilisé des modèles pour le profilage des cibles, des documents de candidature falsifiés, des leurres techniques et le développement de code malveillant. Un cluster aurait enregistré un grand nombre de comptes de modèles en utilisant des identités détournées.

Ces exemples montrent que l’automatisation des cybermenaces par l’IA se diffuse parmi des acteurs aux motivations très différentes. Les groupes d’espionnage cherchent des renseignements, tandis que les groupes criminels poursuivent l’extorsion, la vente d’identifiants et le vol de cryptomonnaies.

La technologie ne rend pas ces acteurs identiques. Elle leur donne accès à une couche commune d’automatisation opérationnelle.

Cette différence est importante. Une portée de niveau étatique décrit l’échelle et la vitesse d’exécution, non un transfert complet des capacités de renseignement étatiques à des criminels ordinaires.

La chaîne d’approvisionnement logicielle devient une surface d’attaque pour les agents

Les attaquants ciblent les instructions et les signaux de confiance utilisés par les systèmes de codage IA, et non seulement les logiciels que ces systèmes produisent.

GTIG a lié une grande partie de cette activité à UNC6780, également connu sous le nom de TeamPCP. Depuis mars 2026, ce groupe à motivation financière cible PyPI, npm et Docker Hub.

Ces services distribuent des paquets utilisés dans les projets logiciels modernes. Un paquet compromis peut pénétrer dans plusieurs organisations via des installations de routine ou des builds automatisés.

TeamPCP aurait compromis des comptes de développeurs légitimes et publié des forks malveillants de serveurs Model Context Protocol. MCP est une norme qui permet aux applications IA de se connecter à des outils et données externes.

Le groupe a également injecté du code malveillant dans des dépôts organisationnels officiels. Les ressources empoisonnées ont ainsi acquis l'apparence d'actifs de projet dignes de confiance.

Un composant malveillant, DUSTMAKER, recherchait des jetons d'identité dans les environnements d'intégration continue. Ces jetons pouvaient autoriser la publication de paquets via des flux de travail de développeurs de confiance.

Google indique que les paquets compromis pouvaient comporter des attestations SLSA Build Level 3 valides. SLSA est un cadre de documentation et de protection de l'intégrité des builds logiciels.

Une attestation valide peut convaincre des systèmes automatisés qu'un paquet a suivi un processus de build approuvé. Elle ne peut toutefois pas rendre fiable une identité de publication volée.

C'est là que les systèmes de codage IA créent un risque spécifique. Les agents évaluent souvent les noms de paquets, les métadonnées, le contexte du dépôt et les signaux de confiance lisibles par machine avant de recommander ou d'installer une dépendance.

Les attaquants peuvent façonner ces signaux. Ils peuvent empoisonner des métadonnées, dissimuler des instructions dans des fichiers de projet ou exploiter la volonté de l'agent d'accomplir une tâche de développement.

DUSTMAKER plaçait du contenu malveillant dans des répertoires cachés utilisés par les outils de codage et environnements de développement. Parmi les exemples figuraient les répertoires .claude, .vscode et .cursor.

Les fichiers situés dans ces emplacements peuvent se fondre dans l'activité ordinaire d'un espace de travail. Ils peuvent aussi influencer les outils qui analysent automatiquement la configuration d'un projet.

Google a découvert une configuration malveillante conçue pour déclencher des commandes lors d'interactions normales avec les développeurs. Un développeur pouvait ainsi activer le malware en ouvrant ou en travaillant dans un projet compromis.

Le malware créait également des tâches de pipeline aux noms plausibles liés à l'IA. Un exemple portait le libellé « Copilot Setup » tout en recherchant des identifiants et clés d'accès supplémentaires.

Après son exécution, le malware pouvait supprimer les journaux de workflow. Cela réduisait la probabilité que les développeurs remarquent une activité suspecte via l'interface d'un dépôt.

Une autre tactique visait les scanners de sécurité basés sur l'IA. Les attaquants intégraient des requêtes interdites extrêmes dans des commentaires placés au-dessus de JavaScript malveillant.

L'objectif apparent était de pousser les contrôles de sécurité à refuser l'analyse avant d'atteindre le malware proprement dit. Il s'agit d'une injection de prompt indirecte, dans laquelle un contenu caché manipule un système IA examinant du matériel non fiable.

Cette stratégie révèle un conflit au sein du développement automatisé. Les équipes souhaitent que les agents de codage lisent un large contexte de projet, mais chaque fichier supplémentaire devient un canal d'instructions potentiel.

Les scanners traditionnels traitent généralement les commentaires comme du texte non exécutable. Un scanner IA pourrait considérer ces mêmes commentaires comme des instructions opérationnelles ou du contenu sensible au regard des politiques.

Les constats sur la chaîne d'approvisionnement dépassent donc la détection de paquets malveillants. Les organisations doivent examiner comment les agents choisissent les dépendances, interprètent les fichiers d'espace de travail et approuvent les commandes.

Les développeurs ont également besoin de visibilité sur les actions effectuées en leur nom. Un agent qui installe silencieusement des paquets ou exécute des scripts de configuration peut transformer une erreur de recommandation en compromission immédiate.

La provenance des connaissances importe ici. Les équipes doivent distinguer les instructions opérationnelles fiables des textes recueillis dans des dépôts, tickets, documents et pages externes.

Une base de connaissances techniques consultable peut étayer cette distinction lorsque les règles d'accès et le contexte des sources restent visibles. Elle ne remplace ni la vérification des paquets ni l'isolation à l'exécution.

La leçon plus générale est que les agents IA héritent des faiblesses de leurs entrées. Ils transforment aussi certaines entrées trompeuses en actions, ce qui accroît le coût d'une confiance mal placée.

Les preuves de Google sont sérieuses, mais l'écart de capacités n'a pas disparu

Le rapport étaye l'affirmation d'une accélération réelle, mais ne prouve pas que chaque petit attaquant dispose désormais de capacités complètes dignes d'un État.

GTIG bénéficie d'une visibilité exceptionnellement large grâce à ses activités de réponse aux incidents, de suivi des menaces, d'infrastructure cloud et de surveillance des abus de Gemini. Cela rend ses études de cas précieuses.

Toutefois, le rapport présente des opérations observées sélectionnées plutôt qu'une mesure exhaustive du comportement des attaquants à l'échelle mondiale. Il ne fournit pas de référence indiquant quel pourcentage des attaques utilise des agents autonomes.

La campagne de six heures a également commencé après que l'attaquant a compromis une infrastructure cloud. L'accès initial reste un obstacle important, même lorsque des agents accélèrent les étapes ultérieures.

De même, « des milliers d'identifiants » décrit l'échelle de collecte de la campagne, et non le nombre de comptes effectivement exploités avec succès. Certains secrets pouvaient être expirés, restreints, dupliqués ou autrement inutilisables.

Les organisations devraient donc éviter de considérer chaque script généré par IA comme une menace persistante avancée. L'attribution et l'évaluation des capacités requièrent toujours l'infrastructure, la victimologie, les malwares, les modes opératoires et le renseignement humain.

Google a lui-même signalé des limites. Dans les opérations d'information observées au cours du deuxième trimestre, l'IA a amélioré la productivité sans créer de capacités qualitativement nouvelles.

Les acteurs ont utilisé des modèles pour générer du contenu, créer des personas synthétiques, traduire et affiner des récits. GTIG n'avait pas observé d'agents interactifs expérimentaux déployés dans des opérations d'influence réelles au moment de la publication.

Cette conclusion complique les interprétations alarmistes. L'IA semble particulièrement efficace lorsqu'elle automatise un travail structuré et répétable avec un retour mesurable.

Les opérations cyber offrent précisément ces conditions. Un scanner peut déterminer si un hôte répond, si des identifiants fonctionnent et si une commande a échoué.

L'espionnage à long terme exige davantage. Les opérateurs doivent comprendre les relations organisationnelles, sélectionner des renseignements stratégiquement utiles, éviter d'être exposés et interpréter des résultats ambigus.

L'IA introduit également des risques opérationnels pour les attaquants. Les modèles peuvent halluciner du code, exposer une infrastructure, déclencher la surveillance des plateformes ou produire des schémas reconnaissables.

Les fournisseurs commerciaux peuvent désactiver des comptes et renforcer les protections des modèles. Google indique avoir perturbé des actifs associés et mis à jour les classificateurs ainsi que le comportement de refus de Gemini après avoir observé des abus.

L'application des règles par les fournisseurs présente toutefois des limites. Les attaquants peuvent faire tourner des comptes frauduleux, voler des identifiants légitimes ou passer à des modèles hébergés localement.

Anthropic a observé un schéma de migration similaire dans des opérations de surveillance. Ses chercheurs en menaces ont indiqué que certains acteurs étaient passés à des modèles ouverts lorsque les protections commerciales créaient trop de friction.

Les constats sur la surveillance renforcent également l'observation plus générale de Google. Des gouvernements ont utilisé l'IA pour réduire les besoins en personnel et accroître le volume d'analyse, même sans les systèmes de pointe les plus récents.

Cela ne rend pas les contrôles de sécurité inutiles. La surveillance des plateformes crée des opportunités de renseignement et perturbe les opérateurs moins disciplinés.

Cela signifie que la résiliation des comptes ne peut pas constituer la dernière couche de défense. Les flux de travail sous-jacents peuvent survivre lorsque les attaquants conservent les données, les instructions et une puissance de calcul alternative.

Google joue également un double rôle dans ce débat. L'entreprise développe des modèles largement accessibles tout en vendant des produits de sécurité cloud, de renseignement sur les menaces et de défense par IA.

Cette position donne à Google une télémétrie utile, mais les lecteurs devraient distinguer les incidents observés des affirmations commerciales. Les preuves montrent une accélération sans établir que la défense automatisée neutralisera systématiquement l'offensive automatisée.

La même prudence s'applique à l'extraction de modèles. Google a signalé des campagnes coordonnées dépassant 100 millions de prompts contre des capacités propriétaires.

L'entreprise affirme avoir déployé des contrôles en temps réel qui réduisent l'utilité de modèles d'étudiants non autorisés. Les preuves indépendantes de l'efficacité durable de ces défenses restent limitées.

Une lecture équilibrée évite deux extrêmes. L'IA ne se contente pas d'aider les attaquants à écrire de meilleurs e-mails, pas plus qu'elle ne transforme chaque criminel en service de renseignement.

Elle élimine les contraintes de main-d'œuvre et de coordination dans certaines parties du cycle de vie des attaques. Ce seul changement peut submerger des défenses conçues face à des adversaires plus lents.

Trois signaux montreront si les défenseurs peuvent suivre le rythme

La prochaine phase sera déterminée par la vitesse de confinement, la gouvernance des agents et la migration vers des modèles contrôlés par les attaquants.

Le premier signal est le délai entre l'exposition d'identifiants et le confinement automatisé. Les organisations devraient mesurer la rapidité avec laquelle elles peuvent révoquer des secrets, isoler des charges de travail et bloquer des sessions suspectes.

Cette métrique importe davantage que le volume d'alertes. Une attaque de six heures devient moins efficace lorsque des détections à forte confiance déclenchent un confinement en quelques minutes.

Elle devient plus dangereuse lorsque la réponse dépend de plusieurs équipes qui échangent des tickets. Des incidents répétés impliquant des identifiants exploitables renforceraient l'avertissement de Google sur la compression des fenêtres de défense.

Le deuxième signal concerne la manière dont les plateformes logicielles sécurisent les actions des agents. Les registres de paquets, hébergeurs de code, fournisseurs cloud et vendeurs de modèles ont besoin de contrôles qui distinguent les suggestions générées de l'exécution autorisée.

Parmi les mesures utiles figurent des autorisations d'agent restreintes, des builds isolés, l'épinglage des dépendances, des versions signées et des exigences d'approbation pour les commandes sensibles. La journalisation doit aussi préserver ce qu'un agent a lu et pourquoi il a agi.

Une compromission majeure d'un registre provoquée par des instructions IA empoisonnées renforcerait la thèse du rapport sur la chaîne d'approvisionnement. Une adoption plus large d'une isolation efficace des agents réduirait l'impact attendu.

Le troisième signal est le passage des attaquants de services commerciaux surveillés vers des modèles locaux et de la puissance de calcul volée. Cette migration réduit la visibilité dont disposent des fournisseurs tels que Google et Anthropic.

GTIG a déjà observé UNC6508 exécuter un modèle à poids ouverts au sein d'une infrastructure compromise. La poursuite de la croissance de cette tactique rendrait l'application des règles au niveau du modèle moins décisive.

Les défenseurs devraient surveiller le provisionnement inattendu de processeurs graphiques, les téléchargements inhabituels de modèles, un trafic d'inférence anormal et de nouveaux identifiants de services IA. Ces événements peuvent indiquer un vol de ressources avant l'apparition d'une alerte d'intrusion conventionnelle.

Le cas antérieur de zero-day fournit un repère connexe. Google a indiqué que des criminels semblaient utiliser l'IA pour découvrir et exploiter une faille d'authentification auparavant inconnue.

Si des cas confirmés indépendamment devenaient courants, le risque dépasserait l'exploitation plus rapide de faiblesses connues. Les attaquants disposeraient d'une réserve plus importante de nouvelles opportunités.

Pour l'instant, les preuves les plus solides concernent l'automatisation et l'échelle. L'automatisation des cybermenaces par IA aide les acteurs à répéter un travail connu, à coordonner des outils et à se remettre plus rapidement d'erreurs opérationnelles.

Cela exige tout de même une posture de sécurité différente. Les organisations devraient inventorier chaque agent ayant accès au code, aux identifiants, au contenu externe ou aux systèmes de production.

Elles devraient également séparer l'accès au modèle de l'autorité d'exécution. Un assistant capable de recommander une commande n'a pas automatiquement besoin de l'autorisation de l'exécuter.

Les équipes peuvent commencer par tester une question concrète : un compte contrôlé par un agent peut-il modifier la production, publier un package ou exposer des secrets sans qu’un second contrôle n’intervienne ?

La réponse révèle si l’automatisation soutient les défenseurs ou élargit silencieusement la voie des attaquants. Le rapport de Google AI sur les cybermenaces montre clairement que cette évaluation doit figurer dans les plans de sécurité actuels, et non sur une feuille de route future.