Analyses de F5 Labs sur la sécurité des modèles d’IA : ce que les RSSI doivent mesurer avant et après le déploiement

Malcolm HeathChercheur principal en cybermenaces | F5

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

L’IA d’entreprise entre dans une nouvelle phase. L’écart de performances entre les modèles les plus avancés se réduit, mais pas l’écart en matière de sécurité. Les dernières données du F5 Labs Comprehensive AI Security Index (CASI) montrent que les capacités et la résilience face aux attaques divergent de plus en plus, tandis que les résultats du F5 Agentic Resistance Score (ARS) indiquent que cette résilience peut à nouveau évoluer lorsque les modèles sont testés au fil du temps dans des scénarios agentiques en plusieurs étapes.

Pour les RSSI, cela change la nature même de la sélection des modèles. Il ne s’agit plus simplement de déterminer quel modèle est le plus performant, mais de savoir si ses caractéristiques de sécurité sont adaptées au rôle qu’il remplira, au niveau d’autorité qui lui sera accordé et aux conséquences d’une éventuelle manipulation réussie.

Aucun référentiel de sécurité unique ne permet de déterminer si un modèle est adapté à un déploiement donné. Les résultats de septembre de F5 CASI et F5 ARS le montrent clairement : seuls trois modèles figurent parmi les dix premiers des deux classements. Pour les RSSI, cela signifie que les éléments de sécurité sur lesquels repose l’approbation d’un modèle doivent refléter ses conditions réelles de fonctionnement, notamment son degré d’autonomie, son accès aux données et aux outils, ainsi que les répercussions potentielles sur l’activité en cas de compromission.

Cela s’inscrit dans le prolongement d’une série de constats que nous suivons tout au long de l’année. Dans un précédent article de blog de F5, nous avons expliqué pourquoi des éléments de preuve mesurables en matière de sécurité doivent être pris en compte dans la sélection et l’acquisition d’un modèle avant son approbation. Dans un autre article de blog, nous avons examiné les recherches de F5 Labs qui montrent que les conséquences d’une défaillance d’un modèle dépendent fortement des ressources et des actions auxquelles le système environnant lui donne accès.

Nos dernières recherches sur les menaces et nos classements d’août et de septembre réunissent ces idées : les RSSI ont besoin d’éléments probants sur le modèle lui-même, mais aussi sur l’environnement dans lequel il sera utilisé.

Une tendance qui se dégage des données de septembre est particulièrement instructive. Anthropic occupe les cinq premières places du classement F5 CASI, tandis que le top 10 du classement F5 ARS se répartit entre cinq modèles OpenAI, quatre modèles Anthropic et un modèle MiniMax. Pris dans leur ensemble, ces classements montrent pourquoi la réputation du fournisseur, la famille du modèle et ses performances ne constituent pas des indicateurs fiables du type précis de résilience requis pour un déploiement. Pour les RSSI, cela signifie que les éléments attestant de la sécurité au niveau du modèle doivent éclairer la décision de déploiement dès le départ.

La performance n’est pas une mesure de sécurité

Les résultats récents de F5 Labs révèlent un écart persistant entre les capacités d’un modèle et sa résistance aux attaques. En août, GLM-5.2 se classait quatrième sur 31 modèles en matière de capacités, mais 24e selon le F5 CASI ; DeepSeek V4 Flash se classait sixième en matière de capacités et 28e selon le F5 CASI. Grok 4.5 présentait la même divergence du côté des modèles fermés. Cette tendance dépendait du modèle lui-même, et non du fournisseur ou de la licence.

Les résultats en matière de sécurité peuvent présenter des écarts tout aussi marqués. Trois modèles Qwen3.5 ont obtenu des scores F5 ARS de 91,04, 89,81 et 88,23, tandis que leurs scores F5 CASI correspondants étaient de 58, 31 et 53 (le score maximal pour les deux classements étant de 100). Il ne faut pas en conclure qu’une mesure fait davantage autorité que l’autre. Elles mettent en évidence des faiblesses différentes face à diverses formes d’attaque.

Cela change la manière dont les évaluations comparatives des modèles doivent être utilisées dans un processus d’approbation. Les performances peuvent aider à réduire le nombre de modèles présélectionnés, mais elles ne suffisent pas à démontrer qu’un déploiement est sûr. Un bon résultat obtenu selon une seule mesure de sécurité doit également être interprété dans son contexte. Les éléments probants doivent tenir compte du rôle que remplira le modèle, de son degré d’autonomie et des systèmes auxquels il pourra accéder.

Dans un rapport de juillet 2026, Gartner a étudié le rôle croissant de la sécurité comparative. Les données récentes en clarifient la raison d’être : le choix d’un modèle doit tenir compte non seulement de ses capacités, mais aussi des limites à partir desquelles sa résilience commence à faiblir.

Mesurez ce à quoi le modèle est autorisé à faire confiance

L’un des enseignements les plus importants de l’étude menée en août concerne une capacité activement recherchée par les entreprises : celle de pouvoir travailler dans le respect des politiques et des règles fournies.

« Dilemme moral », une attaque étudiée par F5 Labs, exploite ce comportement. Au lieu de dissimuler une instruction malveillante, l’attaquant fournit une règle trompeuse et demande au modèle de raisonner à partir de celle-ci. Le taux de réussite moyen de l’attaque allait de 44,8 % contre Llama 3.1 8B à 91,1 % contre Gemini 2.5 Pro, F5 Labs ayant également relevé la faible efficacité des modèles de garde-fous appliqués au niveau des prompts face à cette technique.

L’enjeu de sécurité consiste à déterminer si un modèle peut suivre des instructions tout en distinguant celles qu’il est en droit de considérer comme faisant autorité. Un document récupéré peut être jugé fiable en tant que source d’informations sans pour autant être considéré comme une source de règles. La réponse d’un outil peut fournir des données sans avoir l’autorité nécessaire pour redéfinir ce qu’un agent peut en faire.

Pour les RSSI qui évaluent les modèles avant leur déploiement, les équipes doivent savoir d’où provient le contexte externe et quelles sources sont autorisées à influencer le comportement des modèles.

Un prompt ne constitue pas une frontière de sécurité

Ces mêmes travaux de recherche mettent en évidence la frontière entre la gouvernance des modèles et l’architecture de sécurité. F5 Labs a examiné trois cas dans lesquels des agents sont sortis des environnements d’évaluation qui leur étaient destinés. Dans l’un d’eux, un agent qui n’était censé avoir accès à Internet que par l’intermédiaire d’un proxy de registre de paquets a découvert une vulnérabilité zero-day dans ce proxy, atteint un nœud connecté à Internet et obtenu l’exécution de commandes avec les privilèges root dans un bac à sable externe. Dans les autres cas, une connexion active restait disponible alors que les modèles avaient reçu l’instruction qu’ils fonctionnaient sans accès à Internet, et une mauvaise configuration du réseau a permis de s’échapper d’un bac à sable.

Le problème commun ne tenait pas simplement au fait qu’un agent avait ignoré une instruction. La limite elle-même avait été présumée, simplement décrite ou mal mise en œuvre. La conséquence pratique est claire : décider de ce qu’un agent devrait être autorisé à faire n’a de sens que si l’environnement impose la même limite.

Les données relatives aux identités confirment ce constat. GitGuardian a découvert 4 576 jetons d’API n8n uniques dans des commits GitHub publics ; sur 896 instances accessibles, 321 ont accepté au moins un jeton exposé. Aucune vulnérabilité logicielle n’était nécessaire. Comme ces workflows peuvent se connecter à des systèmes de gestion de code source, des services cloud, des bases de données et des applications SaaS, l’exposition peut s’étendre bien au-delà du workflow lui-même.

La question n’est donc pas seulement de savoir si un agent peut être manipulé, mais aussi ce qui devient possible s’il l’est. L’accès au réseau, les outils, les identifiants et les systèmes en aval déterminent l’étendue des conséquences. Ces contrôles doivent exister indépendamment de ce que le modèle a été autorisé ou non à faire.

Les modèles à poids ouverts déplacent la responsabilité

Le rapport de F5 Labs, « Modèles d’IA chinois à poids ouverts : risques et avantages en matière de cybersécurité », ajoute un autre critère à prendre en compte lors du choix d’un modèle : le fait qu’il soit « à poids ouverts » ne constitue pas en soi une évaluation de sécurité.

En juillet, Qwen3.5-397B-A17B a obtenu un score de 81,13 au F5 CASI, Xiaomi MiMo-V2.5 un score de 73,80 et GLM-5.2 un score de 46,58. Cet écart est plus instructif que toute conclusion générale sur cette catégorie. Il montre pourquoi la famille de modèles, le fournisseur et le modèle de licence ne sauraient remplacer l’évaluation du modèle précis envisagé.

Ce que le déploiement de modèles à poids ouverts change, en revanche, c’est la répartition des responsabilités. Un contrôle accru sur la localisation des données, l’infrastructure et la personnalisation implique également une responsabilité accrue en matière de provenance, d’application des correctifs, de journalisation et d’intégrité des artefacts de modèle. F5 Labs recommande de traiter les artefacts de modèle comme des composants de la chaîne d’approvisionnement logicielle, notamment en vérifiant leur provenance, en verrouillant les versions fiables et en analysant les artefacts avant leur déploiement.

La décision consiste donc moins à déterminer si un modèle ouvert ou fermé est intrinsèquement plus sûr qu’à identifier les risques que l’organisation est en mesure d’assumer.

Ce que les RSSI doivent mesurer avant le déploiement

Les conclusions récentes montrent qu’il ne faut pas considérer la sécurité des modèles comme une simple étape de validation. Une évaluation pertinente avant le déploiement doit répondre à plusieurs questions :

• Capacité et résilience face aux attaques adverses : Le modèle est-il capable d’accomplir la tâche, et comment se comporte-t-il face aux attaques pertinentes pour cette tâche ?
• Résilience au niveau des prompts et des agents : Les éléments probants reflètent-ils la manière dont le modèle fonctionnera réellement, en particulier lorsque des outils, des identifiants ou des actions autonomes entrent en jeu ?
• Autorité des instructions : Quels systèmes peuvent fournir du contexte, et lesquels sont autorisés à influencer les règles ou le comportement ?
• Limites imposées : Qu’est-ce qui est techniquement hors de portée du modèle, quelles que soient les instructions qui lui sont données dans un prompt ?
• Identité et provenance : Quels identifiants, versions de modèles et artefacts sont considérés comme fiables, et comment sont-ils régis ?
• Réévaluation : Quels changements invalideraient l’approbation initiale, notamment les mises à jour du modèle, l’ajout de nouveaux outils, les modifications des autorisations ou l’apparition de nouvelles techniques d’attaque ?

En répondant à ces questions, les RSSI éviteront de réduire plusieurs décisions distinctes en matière de risques à la seule question de savoir si un modèle est « sécurisé ».

Comment F5 Labs mesure la résilience de l’IA

F5 CASI et F5 ARS doivent être considérés comme des éléments probants, et non comme des certifications. F5 CASI mesure la vulnérabilité aux attaques courantes par injection de prompt et contournement des restrictions, tandis que F5 ARS évalue la résilience dans des scénarios impliquant des agents autonomes et des processus en plusieurs étapes. Les classements de septembre 2026 fournissent la comparaison la plus récente pour ces deux indicateurs.

Un score est particulièrement utile lorsqu’il est mis en perspective avec le déploiement envisagé. Il ne permet pas de déterminer si un agent dispose de privilèges excessifs, si un bac à sable est correctement configuré ou si une source externe peut introduire des instructions auxquelles le modèle ne devrait pas se fier. En revanche, il peut fournir aux équipes de sécurité des informations précises sur le comportement de ce modèle dans des conditions adverses définies.

C’est le fil conducteur de cette série de travaux de recherche. Et les dernières conclusions de F5 montrent clairement qu’avant de déployer des modèles d’IA, les organisations doivent savoir quelles propriétés de sécurité ont réellement été mesurées, lesquelles ne l’ont pas été, et si les contrôles environnants sont suffisants au regard du risque résiduel.

Pour en savoir plus :

• Consultez les derniers classements de sécurité de l’IA F5 CASI et F5 ARS pour comparer la résilience des modèles et suivre leur évolution au fil du temps.
• Découvrez la F5 AI Security Platform pour sécuriser les modèles, applications et agents d’IA dans toute l’entreprise.
  
  

À propos des auteurs

Malcolm HeathChercheur principal en cybermenaces | F5

Malcolm Heath est chercheur principal en menaces chez F5 Labs. Au cours de sa carrière, il a travaillé dans la réponse aux incidents, la gestion de programmes, les tests d’intrusion, l’audit de code, la recherche sur les vulnérabilités et le développement d’exploits, au sein d’entreprises de toutes tailles. Avant de rejoindre F5 Labs, il était ingénieur senior en sécurité au sein de la F5 SIRT.

Autres articles de Malcolm Heath

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

Louise Scully est Senior Manager en marketing produit pour la sécurité de l’IA et le renseignement sur les menaces chez F5. Au cours de sa carrière, elle a exercé dans les domaines du marketing produit, de la gestion de produits, de la stratégie de mise sur le marché, de la communication, du leadership d’opinion et du développement de catégories, dans les secteurs de la sécurité de l’IA et des technologies d’entreprise. Avant de rejoindre F5, Louise a dirigé le marketing chez CalypsoAI et Artomatix, contribuant à la commercialisation de technologies et de travaux de recherche en IA.

Autres articles de Louise Scully