Le risque lié à un modèle d’IA dépend de ce à quoi il peut accéder

Une nouvelle étude de Snyk menée dans des milliers d’environnements d’entreprise analysés montre pourquoi un score de risque élevé pour un modèle marque le début du triage, et comment les équipes de sécurité doivent réagir.

Imaginez deux applications qui font référence au même modèle d’IA. L’une résume des notes de réunion, tandis que l’autre utilise un agent pour interroger des dossiers clients et déclencher des processus métier. Le modèle peut obtenir les mêmes scores aux tests adversariaux dans les deux applications. Mais les conséquences d’une défaillance peuvent être très différentes, tout comme la défaillance qui importe. Pour un outil de résumé de réunions, il faut savoir si le modèle peut être amené à produire des résultats trompeurs. Pour un agent qui accède aux dossiers clients, il faut savoir s’il peut être amené à divulguer des données ou à effectuer des actions non autorisées. C’est pourquoi un score pour chaque type d’attaque est plus utile qu’une moyenne unique calculée sur l’ensemble.

Cette distinction est au cœur du rapport de Snyk 2026 State of Agentic AI Adoption, Volume III. Les deux premiers volumes ont établi que l’IA d’entreprise constitue un écosystème logiciel interconnecté, et non une simple collection de modèles. Cette nouvelle analyse ajoute des scores de risque pour les modèles identifiables et pose la question à laquelle les responsables de la sécurité doivent vraiment répondre : quels résultats nécessitent une action, et quelle action permettra de réduire le risque ?

Près de la moitié des inventaires de modèles d’IA comprennent une référence avec un score critique

Comment fonctionnent les scores : Snyk teste chaque modèle face à 29 objectifs d’attaque, comme l’extraction de données personnelles ou l’exécution de commandes, et attribue à chacun un score de 0 à 1 000. Le score combine la fréquence de réussite d’une attaque et les dommages qu’elle pourrait causer. Un score de 500 ou plus est élevé ; à partir de 750, il est critique. Les modèles sont testés avec une protection de base : les scores décrivent donc un modèle protégé, et non un modèle sans protection.

Parmi les 1 693 environnements où au moins un identifiant de modèle a été détecté, 74,5 % font référence à un modèle ayant obtenu un score élevé (500+) pour au moins un objectif d’attaque, et 49,2 % à un modèle ayant obtenu un score critique (750+). Dans cet échantillon, les résultats critiques concernent l’extraction de données personnelles et l’exécution de commandes.

Ces chiffres doivent inciter à enquêter, pas à paniquer. L’étude met en correspondance les identifiants de modèles trouvés dans le code avec les résultats de tests adversariaux. Elle ne prouve pas que chaque modèle est actif en production, qu’un outil ou un jeu de données donné est accessible, ni qu’une attaque a réussi dans l’application d’une organisation.

La couverture est une autre raison d’être précis : seuls 37,5 % des occurrences de modèles détectées sont associées à un score de risque. Environ 17 % des environnements comprenant des modèles n’en ont aucun avec un score. Considérez les références sans score ou sans version comme des inconnues qui doivent tout de même être examinées.

La taille de l’inventaire change le nombre de résultats, mais pas leur répartition. La probabilité de trouver au moins un modèle avec un score élevé passe de 34,6 % pour les plus petits inventaires à 100 % pour les plus grands. Pourtant, la part des occurrences liées à des modèles avec un score élevé reste comprise entre 21 % et 25 % quelle que soit la taille, et entre 18,9 % et 25,5 % dans huit secteurs. Utilisez le nombre pour dimensionner le retard d’examen et la proportion pour comparer vos choix de modèles à ceux de vos pairs. Aucun de ces chiffres ne révèle ce qu’une application active permet à un modèle de faire.

Pour chaque modèle avec un score élevé, les premières questions sont : est-il actif, à quoi peut-il accéder et que se passe-t-il en cas de défaillance ?

Les agents et les serveurs MCP rendent impossible d’ignorer le contexte de déploiement

Un modèle peut produire une réponse dangereuse à lui seul. Connecté à des outils, des données et des processus, il peut aussi agir sur la base de cette réponse. Voilà la différence entre l’exposition testée d’un modèle et la portée du système qui l’entoure.

Parmi les 1 051 comptes américains faisant référence à MCP, 744 (70,8 %) présentent des signes de création d’un serveur MCP à l’aide d’un SDK. Les autres ne montrent que des connexions client ou des références de configuration. Créer un serveur, en configurer un et l’exploiter sont trois signaux différents ; seule une vérification à l’exécution confirme le dernier.

Parmi les environnements où aucun signal d’agent ou de MCP n’a été détecté, 49,1 % font référence à un modèle avec un score élevé, contre 96,6 % de ceux où l’on trouve à la fois un indicateur d’agent et du code de création de serveur MCP.

Ce dernier groupe dispose également d’un inventaire médian de modèles bien plus important : 104 modèles contre 4. Si l’on compare les environnements qui comptent de 5 à 19 modèles, l’écart passe de 47 à 26 points (62,1 % contre 87,8 %). Il s’agit d’une association. Ce que les agents et les serveurs MCP changent, c’est la portée d’un modèle et de son score : c’est donc là qu’il faut regarder en premier.

Pour les équipes de sécurité, l’étape suivante consiste à vérifier : confirmez quels agents et serveurs MCP sont actifs, quels outils ils exposent, quelles données ils peuvent récupérer et quelles approbations séparent la sortie d’un modèle d’une action ayant des conséquences. Un score de modèle ne permet pas de répondre à ces questions.

Ne prescrivez pas la même solution à toutes les faiblesses de l’IA

Une fois que vous savez à quoi un modèle peut accéder, il faut déterminer quelle solution convient à la défaillance. Un programme efficace de gestion des risques liés aux modèles ne s’arrête pas aux niveaux de gravité. Il cherche à déterminer quel objectif d’attaque importe pour l’application et si un autre modèle fait nettement mieux sur cet objectif. Deux cas se présentent :

• Quand changer de modèle peut aider. Pour l’exécution de commandes, 77 % des modèles testés ont obtenu un score nul, tandis que le pire a atteint 834. Pour les portes dérobées dans le code, 57 % ont obtenu un score nul, tandis que le pire a atteint 695.

• Quand les contrôles de l’application font le travail. Pour la désinformation, le modèle médian a atteint le score maximal possible. Pour les biais liés à la race, aucun modèle testé n’a obtenu un score nul.

Un score nul signifie qu’aucune attaque n’a réussi lors du test. Un modèle performant sur un objectif peut échouer sur un autre ; validez donc tout modèle de remplacement par rapport à chacun des objectifs dont dépend la charge de travail. Lorsque les résultats sont regroupés, la défense doit se trouver dans l’application : limitez les accès, validez les sorties, exigez des approbations, surveillez l’utilisation et analysez le code généré et ses dépendances avant leur intégration à une compilation.

Les seuils d’alerte ne racontent eux aussi qu’une partie de l’histoire : 18 des 29 objectifs d’attaque ne peuvent jamais atteindre le seuil d’alerte par défaut de 500, car les dommages qu’ils peuvent causer plafonnent leur score maximal en dessous de ce seuil. Ces défaillances restent importantes, même lorsque la file d’alertes est vide.

Lorsque les modèles diffèrent, testez-en un autre. Dans le cas contraire, réduisez les accès et les privilèges de l’application.

Quels objectifs un changement de modèle peut-il réellement corriger, et lesquels ne déclencheront jamais d’alerte ? Découvrez les 29 objectifs dans le graphique. Téléchargez le rapport complet.

Votre liste de modèles approuvés mérite peut-être d’être réexaminée

La notoriété, la licence et le prix ne remplacent pas l’examen du modèle lui-même.

Les modèles aux capacités plus limitées méritent un examen prioritaire

Dans le groupe évalué, les modèles aux capacités plus limitées ont obtenu de moins bons résultats en matière de fuite de données personnelles, de contournement des décisions et de génération de code non sécurisé. Pour le contournement des décisions, la moyenne est passée de 501 pour les modèles dont le score à l’Epoch Capabilities Index (ECI) est inférieur à 130, à 45 pour ceux dont le score ECI est de 150 ou plus. Ces modèles aux capacités les plus limitées représentent environ un tiers des occurrences de modèles dans la comparaison évaluée : ce résultat va donc bien au-delà d’un cas isolé.

Les capacités sont une mesure distincte de la sécurité, et même un modèle plus performant doit être testé pour la tâche qu’il accomplira. Réexaminez les versions approuvées aux capacités plus limitées et testez d’autres modèles de votre fournisseur actuel, car cette tendance se retrouve également dans les gammes de produits de fournisseurs individuels.

Le fournisseur est un premier indicateur utile, mais il est moins révélateur pour les modèles les plus avancés. Pour les modèles de milieu de gamme, les moyennes des fournisseurs vont de 113 à 356 ; parmi les modèles les plus performants, trois grands fournisseurs se situent dans une fourchette de 22 points. Si votre liste approuvée s’appuie sur un seul fournisseur, le rapport complet montre les points forts et les points faibles de ses modèles. Six fournisseurs sont comparés côte à côte sur sept types d’attaque, de l’exfiltration de données à la manipulation des sorties. Dans cet échantillon, les modèles haut de gamme n’ont pas présenté d’avantage de sécurité constant, en grande partie parce que cette catégorie comprend surtout des modèles plus anciens et aux capacités plus limitées.

Modèles à poids ouverts et provenance des données d’entraînement

Le rapport relève également des scores moyens de fuite de données personnelles plus élevés parmi les 16 modèles à poids ouverts évalués que parmi les modèles propriétaires : 562 contre 274. L’échantillon étant restreint, considérez cet écart comme un signal à examiner pour les charges de travail traitant des données personnelles.

La visibilité sur la provenance révèle une même différence. Dans 904 des 1 693 environnements comprenant des modèles, les analyses n’ont trouvé aucune information sur la provenance des données d’entraînement, principalement parce que les fournisseurs de modèles propriétaires ne publient pas leurs jeux de données d’entraînement. Les éléments à examiner dépendent donc du type de modèle : demandez aux fournisseurs de modèles propriétaires des garanties documentées et examinez la provenance des jeux de données publiée par les modèles à poids ouverts.

Quatre mesures pour les responsables de la sécurité

1. Dressez l’inventaire et qualifiez les inconnues : suivez les identifiants et versions des modèles, leurs responsables, leurs utilisations actives, les agents, les outils, les serveurs MCP et les informations disponibles sur leur provenance. Gardez visibles les modèles non associés ; ne les considérez pas silencieusement comme à faible risque.

2. Vérifiez la portée : confirmez le chemin d’exécution entre chaque modèle actif, les données sensibles, les identifiants, les outils et les actions en aval. Distinguez le code de création de serveur de la configuration et des connexions réelles.

3. Adaptez la remédiation à chaque objectif : hiérarchisez les défaillances selon leurs conséquences métier. Testez des modèles de remplacement précis lorsque les résultats adversariaux varient ; appliquez le principe du moindre privilège, vérifiez les sorties, exigez des approbations et analysez le code lorsque ce n’est pas le cas.

4. Inscrivez les décisions dans votre gouvernance : consignez le modèle et sa version, les preuves de test, le responsable, les contrôles approuvés, leur justification et la date de réexamen. Réévaluez la situation lorsque les modèles, les autorisations, les données de réglage fin ou les applications changent.

À retenir du Volume III : le score d’un modèle indique son exposition, mais c’est le système qui l’entoure qui détermine sa portée. Agissez sur les deux plans : changez de modèle lorsqu’ils diffèrent et renforcez les contrôles lorsqu’ils ne diffèrent pas.

Méthodologie : données anonymisées et agrégées d’analyse de nomenclature de l’IA (AI-BOM) provenant d’organisations utilisant Snyk, à partir de septembre 2026 : 3 023 environnements, dont 1 693 comportant au moins un identifiant de modèle. Les résultats au niveau des modèles couvrent les comptes américains.

Les responsables de la sécurité doivent savoir quelles défaillances peuvent avoir des conséquences pour leur activité et quels changements de contrôle peuvent modifier le résultat. Quel modèle d’agent et de MCP décrit votre environnement, et comment votre fournisseur se compare-t-il sur sept types d’attaque ? Le rapport complet détaille ces deux aspects, ainsi que les résultats par secteur et par gamme de prix, et les six questions auxquelles chaque responsable de la gouvernance devrait pouvoir répondre. Téléchargez le rapport 2026 State of Agentic AI Adoption, Volume III.

Prêt à évaluer votre propre écosystème d’IA ? Découvrez Evo AI-SPM.