Black Kite révèle des vulnérabilités critiques chez 34,2 % des entreprises d'IA analysées

Une équipe connecte un assistant IA à son dépôt de code afin qu'il analyse les erreurs et propose des correctifs. L'assistant reçoit un jeton d'accès, lit le code et exécute parfois des commandes. Désormais, la sécurité du projet dépend aussi de la façon dont le fournisseur stocke ce jeton et protège sa propre infrastructure. Les bonnes réponses du modèle ne disent rien à ce sujet.

L'article de ZDNet daté du 10 novembre présente les résultats du rapport de Black Kite sur les fournisseurs d'IA. Sur 18 160 entreprises analysées, 34,2 % présentaient au moins une vulnérabilité critique non corrigée. Pour un développeur comme pour un fondateur, c'est une raison de vérifier quelles portes sont déjà ouvertes aux services externes : de la lecture des demandes clients à la modification du code et à l'accès à l'infrastructure de production.

Ce que les chercheurs ont trouvé

L'échantillon couvre des entreprises de toutes tailles, des petites équipes aux organisations de plus de mille salariés. Il comprend des éditeurs d'applications, des prestataires de projets de déploiement de l'IA, des services sectoriels et des fournisseurs de données, de puissance de calcul et de modèles. Les entreprises qui n'utilisent l'IA qu'occasionnellement ont été exclues.

Outre les vulnérabilités critiques, les chercheurs signalent des problèmes de DMARC chez 61,7 % des entreprises et des faiblesses de DKIM chez 37,3 %. Ce sont des mécanismes d'authentification du courrier électronique. Une mauvaise configuration peut faciliter l'usurpation d'e-mails et le hameçonnage, par exemple lorsqu'un employé reçoit une prétendue demande interne de réautoriser une intégration.

Par ailleurs, 29,7 % des entreprises ont obtenu une note de forte exposition aux attaques par rançongiciel selon l'indice de Black Kite. Il faut bien lire ce chiffre : il s'agit d'une évaluation du risque, et non de la part des organisations déjà chiffrées par des criminels. De même, la présence d'une vulnérabilité critique ne prouve pas à elle seule qu'elle permette d'atteindre les données d'un client donné.

Le compte rendu indique aussi que des identifiants d'entreprise volés étaient liés à 6,8 % des fournisseurs de l'échantillon. Une telle découverte impose de vérifier la validité des mots de passe, des sessions actives et de l'authentification multifacteur. Elle n'équivaut pas à une compromission avérée de tous les systèmes clients.

Comment le problème d'un fournisseur devient le vôtre

Imaginons un assistant de support connecté à un CRM. Pour préparer un brouillon de réponse, il a besoin du texte de la demande et de quelques champs de la fiche client. Mais lors du paramétrage, l'équipe donne au service la possibilité d'exporter toute la base et de modifier les enregistrements : c'est plus rapide pour lancer un pilote.

Si un attaquant accède au fournisseur, les conséquences dépendront de ces autorisations. Pouvoir lire certaines demandes ou pouvoir exporter la base clients n'entraîne pas les mêmes dégâts. Il est donc utile d'évaluer une intégration par une question concrète : que pourra faire la personne qui s'empare de son jeton ?

Une analyse distincte de composants MCP, mentionnée par ZDNet, contient 1 732 constats de sécurité. Parmi eux, 48,8 % sont classés à un niveau élevé ou critique, y compris des possibilités d'injection de code et de commandes. Il s'agit de la part des constats dans une analyse particulière. On ne peut pas en conclure que 48,8 % de tous les serveurs MCP ou de toutes les entreprises sont vulnérables.

MCP lui-même aide à relier les applications d'IA aux outils et aux systèmes métier. La vérification pratique porte ici sur l'implémentation : qui peut appeler l'outil, quels arguments il accepte et avec quels droits l'action s'exécute.

Ce qu'il faut vérifier avant la prochaine connexion

Commencez par dresser la liste des services d'IA auxquels des accès ont déjà été accordés. Pour chacun, consignez le responsable au sein de l'équipe, les données accessibles, les actions autorisées et le moyen de désactiver rapidement l'intégration. Une telle liste transforme la discussion sur la sécurité en une tâche d'ingénierie claire.

Réduisez ensuite les autorisations à ce qui est nécessaire au scénario de travail. Pour un assistant qui rédige des brouillons, le droit d'envoyer des messages, de modifier des enregistrements ou d'exécuter des commandes doit être justifié séparément. Pour les actions dangereuses, il est utile de prévoir une confirmation humaine et un journal des opérations.

Auprès du fournisseur, il convient de s'informer sur la manière dont il corrige les vulnérabilités critiques, protège les comptes et signale les incidents. Il est particulièrement utile de renouveler la vérification lorsque l'accès s'élargit : hier le service lisait la documentation, aujourd'hui il peut écrire dans le dépôt.

Le rapport a ses limites : d'après le compte rendu disponible, on ne peut ni comparer le risque des entreprises d'IA à celui des fournisseurs SaaS classiques, ni évaluer la sécurité d'un produit donné. En revanche, il fournit un motif concret de revoir les autorisations. Avant d'étendre un pilote, vérifiez que l'accès du service correspond à la tâche pour laquelle vous l'avez connecté.