Les attaques de LLM-jacking de Google transforment l’accès à l’IA en marchandise volée

Google affirme que des criminels dérobent des comptes d’IA et des identifiants cloud, alors que le coût des modèles premium alimente un marché clandestin de plus en plus important pour l’accès à ces services.

L’alerte de septembre 2026 déplace le centre de gravité de la sécurité de l’IA. Les entreprises ont passé des années à débattre de la possibilité pour les attaquants de manipuler ou de compromettre les modèles eux-mêmes. Google décrit désormais un problème plus immédiat : les attaquants volent les comptes, clés API, fichiers de configuration et ressources cloud qui entourent ces modèles.

Les attaques de LLM-jacking décrites par Google opposent l’expansion rapide de l’accès à l’IA à des contrôles d’identité conçus pour des services logiciels ordinaires. Le LLM-jacking consiste à utiliser des identifiants compromis afin de consommer l’accès payant aux modèles ou la capacité de calcul d’autrui. La technique est apparue publiquement pour la première fois en 2024, mais les éléments recueillis par Google suggèrent qu’elle s’est intégrée à une économie criminelle plus vaste.

Les attaques de LLM-jacking de Google dépassent les simples clés API volées

La conclusion centrale de Google est que l’accès à l’IA est devenu suffisamment précieux pour être volé, échangé, mutualisé et revendu.

La évaluation des menaces de septembre provient du Google Threat Intelligence Group, ou GTIG. Ses éléments s’appuient sur les travaux de réponse à incident de Mandiant, le suivi d’acteurs malveillants, des forums clandestins et des activités observées dans les services de Google.

GTIG a constaté une hausse du nombre d’acheteurs recherchant des comptes liés à l’IA au cours de 2026. Les chercheurs ont également observé davantage de vendeurs en faire la publicité. La demande se serait concentrée sur les identifiants pour Claude et Gemini, tandis que les comptes destinés aux environnements de codage autonomes suscitaient également de l’intérêt.

Google n’a pas publié le nombre total de comptes volés. L’entreprise a toutefois indiqué que les prix clandestins moyens par compte avaient plus que doublé en 2026. Ce détail est important, car il signale une réaction du marché plutôt que de simples vols d’identifiants isolés.

Les attaquants recherchent un accès premium à l’IA pour plusieurs raisons. Les comptes payants offrent des limites d’utilisation plus élevées, des modèles plus performants et moins d’interruptions que les comptes gratuits jetables. Les identifiants API peuvent également prendre en charge des charges de travail automatisées difficiles à maintenir via une interface de chat grand public.

Les identifiants cloud ont une valeur encore plus grande. Une identité compromise peut exposer des modèles hébergés, des autorisations de déploiement, du stockage et de coûteuses ressources de calcul. Les attaquants peuvent alors exécuter des charges de travail d’inférence tandis que la victime en assume l’utilisation et les conséquences opérationnelles.

Google relie ce comportement au LLM-jacking, dans lequel des criminels détournent sans autorisation des services de modèles payants ou une infrastructure cloud. L’objectif immédiat peut être un accès gratuit, mais la même infrastructure peut servir au phishing, à la recherche de vulnérabilités, au développement de malwares ou à la revente.

Il s’agit d’un phénomène plus large que la découverte d’une clé API divulguée dans un dépôt public. Google a observé un écosystème comprenant des comptes volés, des inscriptions automatisées, la mutualisation de comptes, l’agrégation d’API, des services proxy et des outils anti-détection.

La mutualisation de comptes combine plusieurs identités ou clés API derrière un même service. Cette organisation peut répartir l’utilisation, réduire l’effet des bannissements individuels et rendre l’activité plus difficile à attribuer. Un agrégateur peut aussi présenter plusieurs fournisseurs via une seule interface compatible.

Google avait déjà documenté des acteurs utilisant des services qui regroupaient des comptes Gemini, Claude et OpenAI. Son rapport sur les menaces de mai décrivait des outils d’inscription, de vérification, de routage et de surveillance des quotas automatisés, ainsi que de masquage de l’empreinte du navigateur.

Certains de ces outils ont des usages légitimes. Les développeurs routent souvent les requêtes entre plusieurs modèles afin d’améliorer la disponibilité ou de contrôler les charges de travail internes. Le problème de sécurité apparaît lorsque les opérateurs alimentent ces systèmes avec des comptes volés ou créés frauduleusement.

Cette distinction évite une erreur d’analyse fréquente. Un logiciel proxy ne constitue pas en soi une preuve d’activité criminelle. Toutefois, l’association d’identifiants volés, d’inscriptions visant à échapper aux contrôles, de trafic dissimulé et de revente non autorisée crée une chaîne d’abus identifiable.

Google a également constaté que des attaquants ciblent les magasins de configuration locaux utilisés par les assistants de codage IA. En mai 2026, des opérateurs associés à la famille de malwares ACRSTEALER ont émis des règles de récupération de fichiers visant secrets.json de Cline et config.yaml de Continue AI.

Ces fichiers peuvent contenir des clés API en texte clair ou des points de terminaison personnalisés de routage de modèles. Une session de navigateur volée peut exposer un seul compte utilisateur, tandis qu’une configuration de développeur peut ouvrir l’accès aux quotas et à l’infrastructure de l’organisation.

La frontière pratique d’un compte d’IA est donc devenue difficile à définir. Elle peut inclure une identité, un jeton de session, un secret API, une configuration de ligne de commande, un rôle cloud et l’autorisation d’invoquer plusieurs modèles externes.

Pour les équipes de sécurité, cette frontière élargie crée la tension centrale de l’article. Les organisations veulent intégrer l’accès aux modèles dans le travail quotidien, mais chaque intégration pratique crée un nouvel endroit où des identifiants précieux peuvent s’échapper.

Pourquoi le vol de comptes d’IA met désormais sous pression chaque client cloud

La pression pèse sur les organisations qui adoptent l’IA le plus vite, car leur accès aux modèles se répand plus rapidement que leur gouvernance de la sécurité.

Un compte logiciel traditionnellement volé donne généralement à un attaquant accès à des données ou à des fonctions applicatives. Un compte d’IA volé peut ajouter une consommation de modèles mesurée, du calcul cloud, des outils autonomes et des connexions à des connaissances internes.

Cette combinaison modifie les dommages potentiels. Un identifiant compromis peut générer une facture, exposer des informations propriétaires et fournir une infrastructure pour des attaques contre d’autres cibles. La victime peut d’abord ne constater qu’une utilisation inhabituelle plutôt qu’un signal d’intrusion familier.

Les développeurs sont particulièrement exposés. Les assistants de codage IA fonctionnent souvent à côté de dépôts de code source, de terminaux, de gestionnaires de paquets et d’outils de déploiement. Leurs fichiers de configuration peuvent révéler des identifiants ayant une portée bien supérieure à celle d’un simple historique de conversation.

L’essor de l’IA agentique augmente encore les enjeux. Un système agentique permet à un modèle de planifier des étapes et d’utiliser des outils avec une intervention humaine réduite. Ses identifiants peuvent autoriser l’accès aux fichiers, l’exécution de code, la navigation ou la communication avec des services externes.

Google a signalé que des acteurs malveillants adoptaient également des frameworks multi-agents pour des flux de travail offensifs. Ces systèmes peuvent coordonner des analyses, résoudre des erreurs et gérer la collecte d’identifiants avec moins d’interruptions liées aux décisions humaines.

Un cas du deuxième trimestre 2026 a condensé cette évolution dans une chronologie frappante. GTIG a observé des attaquants compromettre une ressource cloud, puis planifier, construire et exécuter une campagne massive de collecte d’identifiants reposant sur des agents en moins de six heures.

Cette découverte ne signifie pas que chaque groupe criminel exploite désormais des systèmes d’attaque autonomes. Elle montre que l’automatisation peut raccourcir la période entre l’accès initial et une exploitation à grande échelle.

Les défenseurs s’appuient traditionnellement sur le temps séparant ces étapes. Une alerte peut déclencher une enquête avant qu’un attaquant n’étende son accès, ne crée une persistance ou n’atteigne des systèmes sensibles. Un cycle de construction et d’exécution de six heures laisse beaucoup moins de place au triage manuel.

La valeur des identifiants IA volés dépasse également leurs quotas directs. Un fichier de configuration peut exposer un point de terminaison privé, tandis que l’identité cloud associée peut révéler des journaux, des magasins de données ou des applications connectées.

Les organisations devraient donc traiter le vol de comptes d’IA évoqué par Google comme un problème de sécurité des identités, et pas seulement de gouvernance de l’IA. Le point de contrôle réside souvent dans l’identifiant et les autorisations qui l’entourent plutôt que dans la couche de sécurité du modèle.

Les secrets de longue durée constituent le risque le plus évident. Ils peuvent rester utilisables après qu’un employé a fermé son ordinateur portable ou changé son mot de passe web. Les attaquants peuvent les tester discrètement, acheminer le trafic via des proxys et accroître l’utilisation après avoir confirmé les services disponibles.

Les comptes de développeurs partagés créent une autre faiblesse. Lorsque plusieurs personnes ou systèmes automatisés utilisent une même identité, les activités inhabituelles deviennent plus difficiles à attribuer. Révoquer l’accès peut également perturber le travail légitime, ce qui peut retarder le confinement.

Les clients cloud font face à un deuxième problème : la consommation paraît normale au niveau de l’infrastructure. Une clé valide effectuant des requêtes de modèle valides peut ne pas déclencher les contrôles conçus pour détecter les malwares ou le trafic réseau interdit.

Les équipes ont donc besoin de signaux comportementaux. Parmi les indicateurs utiles figurent de nouvelles origines géographiques, une activation inattendue de modèles, des changements soudains de quotas, des passerelles API inconnues, un calendrier de requêtes anormal et une utilisation incompatible avec le propriétaire de l’identifiant.

Les fournisseurs de modèles subissent également cette pression. Ils doivent distinguer l’agrégation légitime de la mutualisation criminelle sans bloquer les architectures d’entreprise ordinaires. Ils doivent aussi relier les signaux liés aux comptes, au réseau, aux paiements, aux appareils et à l’utilisation entre des produits qui évoluent rapidement.

La réponse imposée est une refonte de l’identité autour de l’accès à l’IA. Les organisations ont besoin d’identifiants à courte durée de vie, d’autorisations plus limitées, d’identités de service distinctes, de limites d’utilisation, d’une révocation rapide et d’une surveillance liée au comportement attendu.

Ces mesures paraissent familières, car les défaillances sous-jacentes le sont aussi. Ce qui a changé, c’est l’actif monétisé et la vitesse à laquelle un accès volé peut soutenir d’autres opérations.

Le véritable compromis oppose la commodité de l’IA au contrôle des identifiants

L’adoption de l’IA réduit les frictions pour les utilisateurs, mais cette même commodité peut dissimuler des identifiants dans des outils, des plug-ins, des agents et des fichiers locaux.

La plupart des organisations ne déploient pas un unique système d’IA géré de manière centralisée. Les employés utilisent des applications de navigateur, des assistants de codage, des clients en ligne de commande, des passerelles de modèles, des plateformes cloud, des extensions et des automatisations personnalisées.

Chaque voie d’accès gère l’identité différemment. L’une peut utiliser un cookie de session, une autre une clé API et une autre encore un rôle cloud hérité de l’environnement de l’utilisateur. Les équipes de sécurité peuvent avoir du mal à inventorier les trois.

Les outils de codage IA rendent ce compromis particulièrement visible. Les développeurs s’attendent à une configuration rapide et à un accès ininterrompu aux modèles. Enregistrer une clé dans un fichier de configuration est pratique, mais un malware qui recherche déjà les systèmes locaux peut ajouter ce fichier à sa liste de collecte.

Les conclusions de Google montrent que les infostealers s’adaptent en conséquence. Les opérateurs de LUMMAC.V2, STEALC.V2, VIDAR et ACRSTEALER ont manifesté un intérêt pour les configurations de développeurs IA, allant au-delà du vol de profils de navigateur.

Les infostealers sont des malwares conçus pour collecter des informations précieuses depuis un appareil infecté. Ils ciblent couramment les mots de passe, les cookies, les portefeuilles et les données d’applications. L’ajout de fichiers de configuration IA constitue une extension logique d’un modèle économique établi.

Ce mécanisme aide à expliquer pourquoi le problème peut s’aggraver sans percée spectaculaire contre les modèles de pointe. Les attaquants n’ont pas besoin de vaincre l’architecture de sécurité centrale d’un modèle s’ils peuvent usurper l’identité d’un utilisateur payant.

Google a souligné cette distinction à plusieurs reprises. Ses conclusions de février indiquaient que les attaquants avaient besoin de clés API et de ressources pour détourner les services LLM à grande échelle. Cette exigence crée une incitation directe à détourner des organisations disposant d’une capacité IA importante.

Le conflit devient plus aigu lorsque les agents reçoivent de larges autorisations d’accès aux outils. Un agent peut avoir besoin d’accéder à des dépôts, à de la documentation, à des outils de suivi des tickets et à des systèmes de déploiement pour fournir une assistance utile. Chaque connecteur ajouté accroît à la fois l’utilité et l’exposition potentielle.

Le vol d’un identifiant AI ne donne pas automatiquement accès à toutes ces autorisations connectées. L’issue dépend de la manière dont l’organisation a conçu l’authentification et l’autorisation. Des identités mal séparées peuvent toutefois transformer un secret volé en plusieurs voies d’accès.

Les secrets ne doivent pas figurer dans les prompts, les fichiers sources, les notebooks ou les répertoires de configuration largement lisibles. Les organisations devraient les stocker dans des systèmes de gestion des secrets et ne les délivrer qu’à la charge de travail qui en a besoin.

Cette recommandation est facile à énoncer et plus difficile à faire respecter. Les développeurs peuvent créer des expérimentations temporaires en dehors des plateformes centrales. Les équipes peuvent partager des identifiants pour respecter une échéance, tandis que des prototypes abandonnés peuvent conserver des clés actives pendant des mois.

Les passerelles AI peuvent réduire cette prolifération en centralisant l’authentification et les politiques. Elles peuvent également devenir des cibles à forte valeur. Si une passerelle a accès à de nombreux fournisseurs et à de larges quotas, sa compromission offre à un attaquant un réservoir concentré de capacité.

La réponse n’est pas d’éviter les passerelles. Il s’agit de limiter ce que chaque identité de passerelle peut appeler, d’établir une attribution par utilisateur et d’empêcher qu’un composant compromis active des services sans lien entre eux.

Les organisations doivent également séparer l’accès aux modèles de l’accès administratif. Un service qui envoie des requêtes d’inférence ne devrait pas recevoir automatiquement l’autorisation de modifier la facturation, d’activer de nouveaux modèles, de créer des identités ou de récupérer des secrets cloud sans rapport.

Une authentification robuste est importante pour les comptes interactifs, mais l’authentification multifacteur ne résout pas toutes les voies d’attaque. Les clés API et les identités de service fonctionnent souvent sans défi interactif, et le matériel de session volé peut parfois contourner une nouvelle connexion.

Des durées de validité courtes pour les identifiants réduisent cette exposition. Il en va de même des systèmes d’identité de charge de travail qui remplacent les clés statiques par des jetons temporaires fondés sur le contexte vérifié de l’application en cours d’exécution.

Les contrôles d’usage apportent une autre couche de protection. Des budgets par identité, des limites de débit, des listes de modèles autorisés et des alertes pour les nouvelles régions peuvent réduire le temps et la capacité à la disposition d’un attaquant.

Les journaux doivent aussi conserver suffisamment de contexte pour l’enquête. Une requête vers un modèle devrait pouvoir être reliée à un utilisateur, un service, un environnement et une finalité approuvée, sans exposer inutilement le contenu sensible des prompts.

Pour les travailleurs du savoir, la leçon est plus personnelle. Une extension de navigateur, un utilitaire de programmation téléchargé ou un client non officiel peut s’interposer entre l’utilisateur et plusieurs services AI payants. En installer un implique une décision de confiance concernant son stockage et sa transmission des identifiants.

Les employés ne devraient pas coller des clés API organisationnelles dans des outils non approuvés. Ils devraient aussi signaler les alertes de connexion inattendues, les notifications d’usage de modèles et l’épuisement soudain des quotas comme de possibles incidents de sécurité, plutôt que comme de simples erreurs de facturation.

Le compromis entre commodité et contrôle ne peut pas être éliminé. Les outils AI deviennent utiles en accédant à davantage d’informations et en réalisant davantage d’actions. L’approche défendable consiste à rendre chaque connexion visible, limitée, attribuable et facile à révoquer.

L’avertissement de Google ne mesure pas toute l’ampleur du LLM-jacking

Les éléments disponibles montrent une menace réelle et en maturation, mais ils n’établissent pas combien d’organisations ont subi des pertes liées au LLM-jacking.

Le rapport de Google emploie des formulations directionnelles telles que « ciblage accru » et « nombre croissant d’intrusions ». Il fournit des exemples, des tactiques observées, des tendances de marché et des cas de réponse à incident plutôt qu’une estimation complète de la prévalence.

Cette limite est importante. Le renseignement sur les menaces reflète les environnements, clients, plateformes et espaces clandestins visibles pour les chercheurs qui le recueillent. Les activités hors de ce champ de vision peuvent ne pas être comptabilisées, tandis que les acteurs fortement surveillés peuvent sembler plus importants.

Le doublement signalé du prix moyen des comptes sur les marchés clandestins est instructif mais incomplet. Google n’a pas publié la taille de l’échantillon sous-jacent, la distribution des prix ni la méthodologie nécessaire pour comparer rigoureusement ce marché dans le temps.

Des prix plus élevés peuvent indiquer une demande croissante, une offre restreinte, une meilleure qualité des comptes ou des changements dans les places de marché suivies. Ils ne prouvent pas, à eux seuls, que les vols de comptes réussis ont doublé.

Le cadrage en termes de « hausse » devrait donc être lu comme la preuve d’une augmentation de l’activité observée, et non comme un recensement des incidents mondiaux. Les affirmations les plus solides de Google concernent ce que ses équipes ont directement constaté : davantage d’acheteurs et de vendeurs, des vols ciblés de configurations et des compromissions cloud soutenant des charges de travail non autorisées.

Il existe aussi un problème de terminologie. Le LLM-jacking peut décrire plusieurs comportements connexes, allant de l’utilisation d’une seule clé API volée au détournement d’un environnement cloud d’entreprise. Les regrouper sous une même étiquette peut masquer des différences considérables d’impact.

La recherche publique initiale sur les identifiants cloud volés définissait le LLM-jacking comme l’utilisation non autorisée de services de modèles hébergés. Des reportages ultérieurs ont élargi le tableau aux réseaux de proxys, à la revente et au développement d’agents offensifs.

Cette histoire offre une comparaison utile. Le cryptojacking cloud suivait une logique économique similaire : les attaquants volaient de la capacité de calcul parce que la victime réglait la facture. Les charges de travail AI créent une autre utilisation monétisable d’une infrastructure compromise.

Le LLM-jacking peut toutefois engendrer des risques allant au-delà des coûts de consommation. L’accès aux modèles peut aider un attaquant à analyser du code volé, à générer des leurres localisés, à automatiser la recherche ou à créer des services pour d’autres criminels.

Les propres conclusions de Google appellent une autre nuance. L’entreprise affirme que les attaquants deviennent des utilisateurs plus compétents de l’AI, mais elle a également signalé que de nombreuses tentatives d’abus de modèles avaient déclenché des systèmes de sûreté ou n’avaient produit aucun saut majeur de capacité.

Lors d’enquêtes antérieures, des groupes soutenus par des États ont utilisé Gemini pour la recherche, le codage, la traduction et le dépannage. Google a désactivé les actifs concernés et mis à jour ses défenses. L’entreprise n’a pas conclu que ces acteurs avaient vaincu les protections fondamentales du modèle.

Ce contraste est important. Le vol de comptes procure un accès, mais cet accès ne garantit ni une sortie sans restriction ni des opérations réussies. Les fournisseurs peuvent toujours détecter les abus, appliquer leurs politiques, désactiver des comptes et mettre à jour les protections des modèles.

Les criminels peuvent également préférer les comptes volés précisément parce que l’application des règles de sûreté reste active. Des viviers d’identités jetables peuvent les aider à absorber les bannissements, à répartir les requêtes et à dissimuler le schéma général.

L’affrontement qui en résulte ne se résume pas à des attaquants face aux garde-fous des modèles. Il oppose des attaquants qui font tourner les identités plus vite que les fournisseurs et les clients ne peuvent relier les comportements suspects entre les comptes.

Des recherches indépendantes étayent ce mécanisme sous-jacent. Sysdig a documenté le LLM-jacking en 2024, puis signalé des cibles et tactiques plus variées. Toutefois, les recherches de fournisseurs reposent souvent sur des incidents sélectionnés plutôt que sur un échantillon mondial représentatif.

Les lecteurs devraient résister à deux conclusions opposées. Il serait erroné d’écarter la menace parce que Google ne dispose pas d’un décompte mondial. Il serait également erroné d’affirmer que chaque compte AI ou client cloud fait face à une compromission imminente.

La conclusion défendable est plus limitée. L’accès AI volé a désormais une valeur observable sur les places de marché, des voies techniques établies et des usages criminels démontrés. Cela suffit à justifier des contrôles précis sans exagérer les éléments disponibles.

Ce qu’il faut surveiller après l’avertissement de Google sur le vol de comptes AI

La prochaine phase sera définie par la télémétrie des fournisseurs, le ciblage des infostealers et la capacité des entreprises à isoler les identités AI avant que les attaquants n’étendent leur accès.

Le premier signal sera la publication de rapports plus détaillés par les fournisseurs de modèles et de cloud. Google a établi une direction, mais les futurs rapports devront inclure des décomptes d’incidents, les types d’identifiants concernés, la durée des abus et une méthodologie de marché plus claire.

Ces divulgations renforceraient l’idée que les attaques de LLM-jacking décrites par Google constituent une catégorie distincte en croissance. L’absence d’expansion mesurable suggérerait que les rapports actuels regroupent plusieurs formes établies d’abus d’identifiants sous une étiquette spécifique à l’AI.

Le deuxième signal est le comportement des opérateurs d’infostealers. Google a observé des règles ciblées pour les configurations d’assistants de programmation AI, montrant que les criminels savent où les développeurs stockent les identifiants de modèles.

Les défenseurs devraient surveiller si davantage de familles de malwares ajoutent systématiquement des clients AI, des frameworks d’agents et des passerelles de modèles à leurs listes de collecte. Une adoption large montrerait que les secrets AI sont devenus une cible standard, aux côtés des cookies de navigateur et des portefeuilles de cryptomonnaies.

Les équipes de sécurité peuvent rechercher ce changement en interne. Les détections sur les terminaux impliquant des chemins de configuration AI méritent un examen, même lorsqu’aucun code source ni magasin de mots de passe traditionnel ne semble touché.

Le troisième signal est l’architecture des identités d’entreprise. Les organisations continueront soit à délivrer des secrets portables et à longue durée de vie, soit à migrer vers des identifiants temporaires de charge de travail, aux autorisations limitées et avec une attribution par utilisateur.

Cette transition déterminera si les accès volés restent faciles à réutiliser et à revendre. Des inventaires centralisés, une rotation rapide, des limites d’usage par défaut et des alertes lors de l’activation de modèles peuvent rendre les identifiants compromis moins précieux.

Les fournisseurs de modèles ont aussi un rôle à jouer. Ils peuvent identifier la mutualisation de comptes au moyen de signaux réseau, appareil, paiement et schémas de requêtes. Ils peuvent exiger une vérification plus forte lorsque l’activité franchit soudainement des régions, des modèles ou des profils d’utilisation.

Ces protections doivent éviter de pénaliser le routage légitime des entreprises. Une entreprise peut intentionnellement répartir ses charges de travail entre des régions ou des fournisseurs. Les systèmes de détection ont besoin du contexte des politiques clients, et pas uniquement de seuils génériques d’anomalie.

Les organisations devraient commencer par un inventaire concret. Elles doivent identifier qui peut accéder aux modèles payants, quelles applications détiennent des identifiants, quels rôles cloud peuvent activer des services et où les requêtes vers les modèles sont consignées.

Elles devraient ensuite tester la révocation. Un identifiant qui ne peut pas être localisé et désactivé rapidement constitue déjà un risque pour la réponse à incident. Les équipes devraient vérifier que la suppression d’une identité ne nécessite pas l’arrêt de charges de travail AI sans rapport.

Les développeurs peuvent réduire le risque en remplaçant les clés statiques locales, en séparant les comptes expérimentaux des systèmes de production et en refusant de partager des identifiants via la messagerie ou des dépôts sources. Les équipes de sécurité devraient rendre le chemin approuvé plus simple que le contournement.

Les dirigeants devraient poser une question simple : si un identifiant AI était volé cette nuit, l’organisation remarquerait-elle d’abord l’attaquant, la facture ou les données divulguées ?

L’avertissement de Google rend cette question urgente, car les attaquants ne considèrent plus l’accès à l’AI comme une nouveauté. Ils y voient un actif qui peut être acquis, mutualisé, consommé et vendu.

Les prochains mois devraient révéler si les fournisseurs publient des mesures plus solides et si les infostealers élargissent leurs listes de cibles. Les lecteurs devraient profiter de cette période pour auditer les accès AI avant que le marché clandestin ne mûrisse davantage.