Évaluer la sécurité de l’IA en entreprise : les questions auxquelles tout acheteur devrait pouvoir répondre

La sécurité de l’IA en entreprise évolue rapidement, et la plupart des organisations peinent encore à évaluer rigoureusement les affirmations des fournisseurs. Ce rapport de recherche de NSS Labs, élaboré en collaboration avec F5, AWS et Microsoft, fournit aux responsables de la sécurité et aux acheteurs en entreprise les questions précises à poser aux fournisseurs, les signaux d’alerte à surveiller et les critères d’évaluation nécessaires pour prendre des décisions éclairées et justifiables en matière de sécurité de l’IA.

Résumé exécutif

La sécurité de l’IA en entreprise pose un problème aux acheteurs. Les organisations savent que la sécurité de l’IA est importante, mais la plupart ne disposent pas d’un cadre fiable pour évaluer les affirmations des fournisseurs, distinguer les mesures de contrôle pertinentes de celles qui ne sont que superficielles, ou exiger des fournisseurs qu’ils apportent des preuves concrètes issues de situations réelles.

Ce livre blanc — le deuxième d’une série en deux parties de NSS Labs, élaborée en collaboration avec F5, AWS et Microsoft — ne se contente plus de définir le problème : il donne aux acheteurs les moyens d’agir. Alors que la première partie expliquait pourquoi la sécurisation du seul modèle d’IA ne suffit pas, la deuxième s’appuie sur ces fondements pour proposer des critères d’évaluation concrets couvrant sept domaines de capacités essentiels.

L’argument central est le suivant : les décisions d’achat en matière de sécurité de l’IA relèvent de la gouvernance, et pas seulement de considérations techniques. Les acheteurs doivent exiger des preuves mesurables, et non de simples schémas d’architecture. Cela implique des référentiels quantitatifs concernant l’efficacité de la détection, les performances opérationnelles, les exigences d’audit et l’alignement sur les cadres de référence — le tout validé dans des conditions réelles, et non dans le cadre de scénarios de test isolés.

Les sept domaines de capacités examinés dans le document sont les menaces liées aux entrées et le contrôle des instructions, les risques liés aux sorties et à l’exfiltration de données, la résilience des systèmes en mode dégradé, la gouvernance des politiques et des filtres, l’IA agentique et la délégation d’autorité, l’observabilité et l’analyse forensique, ainsi que l’intégration et l’interopérabilité. Chaque section met en regard le risque principal, les questions précises que les acheteurs doivent poser aux fournisseurs, les caractéristiques des solutions efficaces et les signaux d’alerte concrets à surveiller.

Le document se conclut par deux recommandations sans équivoque : exigez une validation indépendante avant tout achat et considérez cette validation comme une pratique continue plutôt que comme un contrôle ponctuel. Les fournisseurs qui refusent de se soumettre à des tests rigoureux font preuve d’immaturité, et non de solidité.

En définitive, trois phrases de la conclusion méritent d’être prises au sérieux : l’achat de solutions de sécurité fondées sur l’IA est une décision de gouvernance aux conséquences à long terme. Les entreprises qui posent d’emblée les questions difficiles sont mieux armées pour gérer les risques et éviter les défaillances qui pourraient être prévenues. Enfin, la sécurité de l’IA ne pourra pas s’imposer par la nouveauté ou l’abstraction, mais uniquement par la responsabilisation, la transparence et une évaluation rigoureuse.

Table des matières

Introduction : de la prise de conscience à l’évaluation

Établir des critères d’évaluation quantitatifs

Domaines de capacités critiques et questions que les acheteurs devraient poser

• Détection des menaces dans les entrées, contrôle des instructions et détection des techniques de contournement
• Gestion des risques liés aux sorties et à l’exfiltration de données
• Gestion de la résilience, de la robustesse, des défaillances et de la dégradation
• Efficacité des politiques/filtres et alignement sur la gouvernance
• IA agentique, sécurité de l’invocation d’outils et autorité déléguée
• Observabilité, audit et investigation numérique
• Intégration et interopérabilité

Ce que les acheteurs doivent exiger avant d’acheter

Se préparer à une validation indépendante

Conclusion : des affirmations à la responsabilité

TÉLÉCHARGER LA PARTIE 1 : La sécurité de l’IA au-delà du modèle : les enjeux auxquels les entreprises doivent prêter attention — et pourquoi

Introduction : de la prise de conscience à l’évaluation

À mesure que l’IA s’intègre sous diverses formes aux systèmes d’entreprise, elle crée de nouvelles surfaces d’attaque qui obligent les entreprises à prendre en compte les risques liés à sa sécurité. Les conseils d’administration, les autorités de réglementation et les équipes dirigeantes prennent conscience que les systèmes d’IA introduisent de nouvelles catégories de risques opérationnels, juridiques et réputationnels, en plus d’élargir la surface d’attaque. Par conséquent, les solutions de sécurité de l’IA visant à réduire ces risques figurent désormais parmi les principales préoccupations des équipes chargées de la sécurité des entreprises.

Cette prise de conscience ne garantit toutefois pas que les entreprises soient prêtes. Si elles sont de plus en plus nombreuses à reconnaître l’importance de la sécurité de l’IA, beaucoup peinent à évaluer efficacement les affirmations des fournisseurs présents sur ce marché émergent. La terminologie manque de cohérence, les démonstrations ont souvent une portée limitée et les garanties reposent fréquemment sur l’architecture plutôt que sur des preuves concrètes. Les acheteurs doivent donc prendre des décisions sans disposer d’un moyen clair de distinguer les contrôles réellement pertinents des mesures superficielles, ni d’évaluer l’efficacité réelle de la couverture proposée.

Dans notre précédent livre blanc intitulé AI Security Beyond the Model, NSS Labs expliquait pourquoi la sécurisation du seul modèle d’IA ne suffit pas et pourquoi la sécurité de l’IA en entreprise doit être abordée comme un enjeu de gouvernance et de sécurité à l’échelle du système. Les véritables défis de sécurité se manifestent dans les systèmes qui entourent le modèle, là où les données sont récupérées, les outils sont sollicités et les décisions automatisées sont exécutées.

Ce livre blanc s’appuie sur ces fondements en allant au-delà de la compréhension du problème pour évaluer les solutions potentielles et aider les acheteurs en entreprise à formuler de meilleures questions lors de la présélection des fournisseurs de solutions de sécurité de l’IA. Dans la continuité d’AI Security Beyond the Model, il porte principalement sur les garde-fous à l’exécution (les contrôles externes au modèle qui font respecter les politiques, protègent les données et produisent des éléments probants à des fins d’audit), tout en reconnaissant que la sécurité des modèles et l’IA responsable réduisent les risques intrinsèques liés aux modèles, mais ne peuvent à elles seules gérer les risques liés aux interactions en entreprise. À mesure que les systèmes d’IA s’intègrent aux processus opérationnels des entreprises, les décisions en matière de sécurité recoupent de plus en plus la gouvernance, la gestion des risques et la responsabilité réglementaire. Les organisations doivent être en mesure d’expliquer non seulement le fonctionnement des systèmes d’IA, mais aussi la manière dont les risques sont maîtrisés, surveillés et audités.

Les sections suivantes visent à reformuler les principaux domaines de capacités en matière de sécurité de l’IA sous forme de critères d’évaluation. Plutôt que de préconiser des technologies ou des architectures spécifiques, elles mettent l’accent sur ce que les acheteurs doivent être en mesure de comprendre, de tester et de justifier lorsqu’ils sélectionnent des contrôles de sécurité de l’IA pour des environnements de production.

Établissement de critères d’évaluation quantitatifs

L’évaluation de la sécurité de l’IA exige de dépasser les affirmations qualitatives pour parvenir à une validation mesurable. Les acheteurs doivent définir des exigences de référence permettant une comparaison objective des fournisseurs.

Efficacité de la détection : Les fournisseurs doivent démontrer leurs capacités de détection à l’aide de référentiels et de méthodologies de test standardisés, élaborés par des organismes de test indépendants reconnus. Les organisations doivent exiger des taux de précision mesurables sur des schémas d’attaque connus, les fournisseurs devant communiquer la méthodologie de test, les limites de couverture et les compromis liés aux faux positifs. La prévention de l’exposition des données sensibles doit faire la distinction entre les types de données structurées et les informations sensibles dépendant du contexte, tout en maintenant une précision de détection constante quels que soient les modèles de fondation et les niveaux de complexité des invites.

Performances opérationnelles : Les acheteurs doivent définir des seuils de latence conciliant sécurité et facilité d’utilisation. Les systèmes doivent démontrer leurs performances dans des conditions de charge à l’échelle de la production, et non dans des conditions de test isolées. Le taux de faux positifs est également important : un nombre excessif de faux positifs entraîne une lassitude face aux alertes et favorise l’adoption d’outils d’IA non autorisés. Les fournisseurs doivent être en mesure de fournir des indicateurs de production sur des périodes suffisamment représentatives.

Exigences en matière d’audit : La conformité réglementaire repose sur une journalisation exhaustive et suffisamment détaillée pour reconstituer les incidents plusieurs mois après. Les événements doivent pouvoir être exportés vers un SIEM dans des formats standard, avec une latence minimale. Les exigences de conservation varient selon le secteur et le cas d’usage.

Alignement sur les référentiels : Les fournisseurs doivent faire correspondre leurs contrôles aux référentiels établis par des organismes indépendants reconnus spécialisés dans les tests. Les acheteurs doivent exiger des fournisseurs qu’ils démontrent ces capacités à l’aide de jeux de tests standardisés et d’échantillons de trafic de production. Une validation indépendante par un tiers fournit des preuves fiables de l’efficacité des contrôles.

Domaines de capacités critiques et questions que les acheteurs devraient poser

Au niveau le plus élémentaire, les dispositifs de sécurité des modèles peuvent bloquer les invites malveillantes, filtrer les contenus interdits et faire respecter des règles d’utilisation simples. Ces capacités sont nécessaires, mais de nombreuses défaillances majeures de l’IA en entreprise ne résultent pas d’un manque de règles, mais d’un manque de contexte, de résilience et de visibilité.

Par exemple, un système d’IA peut respecter toutes les politiques de contenu définies tout en divulguant des informations sensibles par agrégation, inférence ou combinaison inappropriée de contextes. De même, un système peut appliquer correctement les règles dans des conditions normales, mais connaître des défaillances imprévisibles en cas de forte charge, de pannes partielles ou de défaillances de dépendances.

Détection des menaces dans les entrées, contrôle des instructions et détection des tentatives de contournement

La plupart des dispositifs de sécurité de l’IA prétendent « filtrer les prompts » ou « bloquer les entrées malveillantes », mais cette façon de présenter les choses simplifie souvent le problème à l’excès. Dans la plupart des systèmes d’IA, le risque ne provient pas uniquement de ce que les utilisateurs saisissent directement dans un système, mais aussi des instructions intégrées aux contenus exploités en aval par ces systèmes. Il peut s’agir de documents, de pages web, de tickets, d’e-mails ou de bases de connaissances, dont le contenu doit être suffisamment fiable pour être considéré comme un contexte faisant autorité.

Auteurs

Bob Walder - Analyste principal, NSS Labs
lan Foo - Directeur de la technologie et vice-président exécutif des produits, NSS Lab

Contributeurs

Cette étude a été réalisée en collaboration avec des leaders du secteur de la sécurité, du cloud et de l’IA.

Cameron Delano - Architecte solutions senior, F5
Jeanette Hurr - Architecte solutions monde, F5
Riggs Goodman III - Architecte solutions principal, sécurité et confidentialité de l’IA, AWS
Raj Bagwe - Architecte solutions senior, AWS
Zachary Riffle - Architecte sécurité, Microsoft

Les acheteurs doivent demander comment un système distingue, lors de son exécution, les instructions système, les intentions des développeurs, le contenu récupéré et les saisies des utilisateurs. Dans les architectures qui utilisent la génération augmentée par récupération (RAG), cette distinction est essentielle. Si le contenu récupéré peut implicitement prendre le pas sur les politiques du système, celui-ci est vulnérable aux injections indirectes de prompts, même si aucune requête manifestement malveillante n’est jamais soumise.

Les entreprises doivent s’attendre à des réponses claires à des questions telles que :

• Dans quelle mesure le système peut-il détecter, évaluer et bloquer les requêtes et les instructions interdites par les politiques en vigueur ?
• Dans quelle mesure le système peut-il détecter et empêcher les tentatives visant à contourner son comportement prévu au moyen de requêtes saisies ?
• Dans quelle mesure le système gère-t-il les requêtes ambiguës ou à la limite de l’acceptable, dont l’intention n’est pas claire, tout en perturbant le moins possible les usages légitimes ?
• Dans quelle mesure le système peut-il empêcher que des instructions intégrées au contenu soumis influencent le modèle de manière involontaire ?
• Dans quelle mesure le système peut-il contrer efficacement les tentatives visant à contourner les contrôles au moyen d’un formatage inhabituel, d’un encodage ou de transformations du prompt ?
• Dans quelle mesure le système parvient-il à concilier la sécurité avec des cas d’usage légitimes fondés sur des rôles (par exemple, simulations de formation, red teaming, travaux créatifs), sans créer de moyens faciles de contourner les protections ?
• Dans quelle mesure le système empêche-t-il efficacement les utilisateurs (ou les contenus externes) d’influencer ou de contourner les instructions du système ou de l’agent, les règles de routage, les restrictions d’utilisation des outils ou d’autres mécanismes de contrôle « prioritaires » ?
• Le système est-il capable de détecter, d’identifier et de réguler efficacement l’utilisation du modèle afin d’éviter les usages abusifs ou excessifs (au-delà de ce que prévoit la politique), ainsi que les coûts qui en découlent ?
• Le système est-il capable d’indiquer, dans les journaux, quelle source d’instructions a prévalu en cas de conflit (système, développeur, récupération ou utilisateur) ?

Dans la pratique, les défaillances dans ce domaine surviennent souvent sans qu’aucune invite manifestement malveillante ne soit utilisée. Elles résultent plutôt de la manière dont du contenu non fiable est introduit dans le contexte de l’IA. Un attaquant peut intégrer des instructions cachées dans un document (par exemple, un document de politique interne, une page de wiki interne ou un article d’assistance client), qui est ensuite ingéré par le système d’IA au moyen d’un pipeline complexe de récupération à partir de plusieurs sources. Lorsque le modèle récupère ce contenu, il peut considérer ces instructions intégrées comme des directives faisant autorité plutôt que comme des données non fiables. Dans les environnements d’entreprise où le contenu interne peut être largement modifié, cette forme d’injection indirecte d’invite peut être particulièrement difficile à détecter.

Par exemple, il n’est pas nécessaire — ni forcément souhaitable du point de vue d’un acteur malveillant — que la modification d’une seule source d’information déclenche un signal d’alerte empêchant immédiatement de causer de graves dommages. Une meilleure stratégie peut consister à apporter des modifications mineures à plusieurs sources de données, entraînant au fil du temps des changements subtils mais persistants dans le comportement du système, comme l’assouplissement des contraintes de réponse, la divulgation des processus internes ou la priorité accordée au contexte contrôlé par l’attaquant plutôt qu’aux politiques du système. À terme, cela peut permettre l’extraction de données sensibles à plus grande échelle.

Les acheteurs doivent donc évaluer si les contrôles de sécurité de l’IA considèrent tout contenu récupéré comme potentiellement hostile et si les limites imposées aux instructions sont appliquées de manière cohérente, quelle que soit l’origine de ces instructions.

Les solutions efficaces distinguent avec une grande précision les saisies des utilisateurs du contenu récupéré. Lorsque des tentatives de contournement des instructions apparaissent dans les requêtes des utilisateurs, les systèmes les bloquent ; lorsque des formulations similaires figurent dans des articles d’assistance légitimes, ils les traitent de manière appropriée. La détection repose sur l’intention sémantique, et non sur des mots-clés, ce qui permet de repérer les attaques dissimulées par des manipulations d’encodage ou des scénarios de jeu de rôle. Les fournisseurs doivent démontrer les capacités de détection en utilisant l’architecture RAG réelle de l’organisation avec une récupération multisource. Les systèmes doivent fournir des indicateurs de production sur des périodes suffisamment représentatives, notamment les taux de détection, les taux de faux positifs et la latence.

Les signaux d’alerte comprennent : le recours à un filtrage générique des prompts ; des assurances vagues selon lesquelles « le modèle s’en charge » ; l’incapacité à démontrer le respect des limites imposées aux instructions dans des conditions adverses ; l’absence de métriques de production couvrant des périodes suffisamment longues ; l’incapacité à démontrer la détection à l’aide de l’architecture RAG interne ; et une détection reposant uniquement sur des mots-clés, sans analyse de l’intention sémantique.

L’intégrité des entrées ne consiste pas à bloquer les formulations malveillantes, mais à préserver l’autorité des politiques dans des environnements dynamiques et non fiables.

Gestion des risques liés aux résultats et à l’exfiltration de données

Les résultats générés par l’IA présentent clairement un risque important, car un agent non humain peut avoir extrait des données de nombreux systèmes différents afin de formuler sa réponse, laquelle peut révéler à des utilisateurs externes davantage d’informations que prévu initialement. De nombreuses défaillances aux conséquences majeures ne concernent pas des contenus explicitement interdits, mais plutôt la divulgation subtile d’informations qui n’auraient pas dû être communiquées à un utilisateur donné, dans un contexte donné et à un moment donné.

Un attaquant ou un utilisateur non autorisé peut poser une série de questions qui, en apparence, semblent anodines et qui, prises individuellement, renvoient des données dont la divulgation est autorisée, mais qui, considérées dans leur ensemble, permettent de déduire ou de reconstituer des informations sensibles. Par exemple, un assistant d’IA connecté à des systèmes internes de gestion des tickets et de documentation pourrait résumer des problèmes opérationnels, les rôles de certains membres du personnel ou des configurations système d’une manière qui révèle indirectement l’architecture interne ou des données réglementées. Ces défaillances sont rarement détectées par les filtres basés sur des mots-clés. Le risque découle plutôt de l’agrégation des informations et du contexte. Les acheteurs doivent vérifier si les contrôles appliqués aux résultats tiennent compte de l’exposition cumulée et si les systèmes sont capables d’expliquer pourquoi une réponse a été restreinte — une exigence essentielle en matière de gouvernance et d’auditabilité.

Les acheteurs doivent s’attendre à des réponses claires à des questions telles que :

• Comment les contrôles de sécurité de l’IA déterminent-ils quelles informations réelles sont exposées en fonction du contexte, plutôt que de se limiter aux mots-clés ou expressions figurant dans le résultat généré ?
• Le système peut-il faire la distinction entre les informations publiques, les informations internes et les données réglementées ?
• Dans quelle mesure le système empêche-t-il efficacement le modèle de divulguer des données sensibles dans ses réponses, même lorsque la demande de l’utilisateur semble légitime ou ambiguë ?
• Quels types de données sensibles la protection couvre-t-elle (par exemple, les données personnelles, les données financières ou les informations confidentielles de l’entreprise), et comment peut-elle être adaptée à l’organisation ?
• Les contrôles tiennent-ils compte du rôle de l’utilisateur, de la juridiction ou de l’origine des données ?
• Le système peut-il expliquer pourquoi un résultat a été bloqué ou modifié ?
• Le système peut-il appliquer des contrôles aux requêtes comme aux réponses, notamment le refus, le masquage et la transformation sécurisée, tout en fournissant des éléments probants à des fins d’audit ?
• Quelles mesures le système peut-il prendre pour empêcher le modèle de divulguer des données sensibles (bloquer, masquer, transformer, avertir, exiger un examen ou une approbation renforcés) ?
• Dans quelle mesure le système empêche-t-il les manipulations d’invite et les stratégies de contournement visant à tromper le modèle pour qu’il divulgue indirectement des données (par exemple, en demandant des « exemples », des « modèles », des « données de test » ou des « résumés » contenant des informations réelles) ?
• Le système peut-il prévenir et détecter les fuites de données entre sessions ou entre locataires, afin de garantir que les informations provenant de la session, du contexte ou des sources de données consultées d’un utilisateur ne puissent pas apparaître dans les réponses d’un autre utilisateur ?
• Dans quelle mesure le système empêche-t-il efficacement le modèle de divulguer les prompts système, les instructions internes, les politiques masquées ou les détails de configuration opérationnelle ?
• Dans quelle mesure le système empêche-t-il efficacement l’exposition d’identifiants ou de secrets (par exemple, des clés API ou des jetons) susceptibles de figurer dans les données d’entraînement, le contexte système, les journaux, les connecteurs ou le contenu récupéré ?
• Dans quelle mesure le système empêche-t-il efficacement le modèle de produire des réponses préjudiciables, désobligeantes ou fortement biaisées, notamment dans les cas limites où un utilisateur cherche à le provoquer ?
• Dans quelle mesure le système peut-il empêcher le modèle de restituer mot pour mot de longs passages protégés par le droit d’auteur ou de reproduire de toute autre manière du contenu protégé ?
• Si le modèle est connecté à des contenus internes de l’entreprise (par exemple, des documents, un wiki ou des systèmes de gestion des tickets), le système peut-il l’empêcher de reproduire des contenus internes à accès restreint au-delà de ce que l’utilisateur est autorisé à consulter ?
• Dans quelle mesure le système peut-il empêcher le modèle de « guider pas à pas un utilisateur » dans des processus dangereux ou de produire des éléments opérationnels (par exemple, des scripts, des commandes ou du code) susceptibles de créer des failles de sécurité ou d’entraîner un comportement dangereux du système ?

Lorsque les systèmes d’IA sont connectés à des sources de données d’entreprise en temps réel, ces risques augmentent considérablement, et des défaillances liées aux résultats générés peuvent survenir lorsque les systèmes d’IA regroupent des informations provenant de plusieurs sources dans une seule réponse.

L’évaluation des contrôles des résultats nécessite de comprendre comment les solutions matures gèrent l’exposition contextuelle des données. Les systèmes sensibles au contexte comprennent le sens sémantique, et pas seulement les mots-clés. Ainsi, les données à caractère personnel structurées doivent être bloquées, tandis que les informations publiques peuvent être autorisées en fonction du contexte. L’application de règles fondées sur les rôles garantit que différents utilisateurs obtiennent des résultats différents pour des requêtes identiques, selon leur niveau d’autorisation. Les systèmes doivent détecter l’exposition cumulative au fil des sessions, lorsque des questions individuellement anodines finissent, ensemble, par révéler des informations sensibles. Les décisions de blocage doivent inclure des références précises aux politiques, les types de données concernés et les exigences en matière d’autorisation. L’intégration aux politiques existantes de classification des données évite les configurations redondantes.

Les signaux d’alerte comprennent : le filtrage reposant uniquement sur des mots-clés ; des décisions d’application opaques ; l’incapacité du système à démontrer l’application de règles fondées sur les rôles (par exemple, une même requête renvoie le même résultat quel que soit le niveau d’autorisation de l’utilisateur) ; l’incapacité du fournisseur à expliquer en termes compréhensibles pourquoi un résultat précis a été bloqué ; et l’absence de pistes d’audit. Les entreprises doivent rechercher des preuves que les contrôles des résultats tiennent compte du contexte et de l’intention, et qu’ils garantissent la traçabilité des responsabilités.

Gestion de la résilience, de la robustesse, des défaillances et de la dégradation

Les entreprises ont l’habitude d’évaluer les contrôles de sécurité en fonction de leur efficacité dans des conditions réseau normales, mais la sécurité de l’IA exige une approche différente. Certaines des défaillances les plus importantes surviennent non pas lorsque les systèmes sont directement attaqués, mais lorsqu’ils sont mis à rude épreuve par le volume, la complexité, la défaillance de dépendances ou des schémas d’interaction inattendus.

Les principales questions à se poser seraient les suivantes :

• Dans quelle mesure le système reste-t-il disponible et réactif lors d’interactions utilisateur inhabituellement longues ou complexes (par exemple, des sessions « marathon ») ?
• Les contrôles sont-ils appliqués de manière cohérente lors de sessions de longue durée ou de workflows d’agents en plusieurs étapes ?
• Comment le système empêche-t-il l’épuisement des ressources ou la dégradation du service lorsqu’il reçoit des rafales d’entrées répétitives, mal formées ou dénuées de sens ?
• Que se passe-t-il lorsque les contrôles de sécurité de l’IA se dégradent ?
• Les vérifications des politiques expirent-elles, et en cas d’échec, l’application des règles autorise-t-elle ou bloque-t-elle l’accès ?
• Comment le système concilie-t-il sécurité et disponibilité en cas de défaillance des dépendances, et ce comportement est-il configurable et auditable ?

Les systèmes d’IA déployés dans des environnements réels fonctionnent dans des conditions variables, telles que des pics d’utilisation, des interruptions de services en amont, des fournisseurs d’identité lents ou des services de récupération dégradés. Dans de tels scénarios, les composants chargés de l’application des règles peuvent connaître des défaillances partielles plutôt que totales. Par exemple, un service d’évaluation des politiques peut dépasser le délai imparti, ou une étape de classification peut être ignorée afin de préserver la réactivité. Si ces défaillances ne sont pas gérées avec soin, les systèmes peuvent adopter par défaut un comportement permissif sans alerter les opérateurs et, dans les workflows agentiques, permettre ainsi l’exécution d’actions sans les contrôles appropriés. Il ne s’agit pas de cas limites hypothétiques, mais de modes de défaillance courants dans les systèmes distribués. Les acheteurs doivent donc exiger des démonstrations du comportement des contrôles de sécurité de l’IA lorsque les dépendances se dégradent, afin de vérifier si les modes de défaillance sont prévisibles, visibles et conformes au niveau de tolérance au risque de l’entreprise.

Un système résilient ne doit pas se contenter de tout bloquer en cas de problème, ni autoriser silencieusement des comportements dangereux. Il doit plutôt fonctionner en mode dégradé de manière prévisible, signaler clairement les erreurs et continuer à assurer une protection adéquate à mesure que les conditions se détériorent.

Les systèmes bien conçus doivent documenter des modes de défaillance explicites pour chaque dépendance. Lorsque les services dépassent le délai d’attente, les systèmes doivent réagir de manière appropriée, consigner les événements, alerter les équipes de sécurité et afficher des messages clairs aux utilisateurs. Lors des tests de résistance, la précision de la détection doit rester élevée, la latence doit demeurer dans des limites acceptables et les requêtes ne doivent pas pouvoir contourner les contrôles de sécurité. La dégradation doit se produire de manière prévisible et déclencher des alertes, et non passer inaperçue, tandis que les disjoncteurs doivent interrompre rapidement les processus qui s’emballent. Les fournisseurs doivent être en mesure de décrire les objectifs de disponibilité des mécanismes d’application et leur comportement en cas de défaillance. Lorsque leur application est critique pour la mission, les acheteurs peuvent exiger des engagements contractuels.

Les signaux d’alerte comprennent : l’incapacité à décrire les modes de défaillance ; l’absence de tests de résistance ou l’affirmation selon laquelle « le système n’a jamais connu de défaillance en conditions réelles » ; une dégradation silencieuse sans alerte ; l’absence de coupe-circuits pour interrompre les processus incontrôlés ; l’incapacité à démontrer que la précision de la détection reste élevée lors des tests de résistance ; et les systèmes qui permettent aux requêtes de contourner les contrôles de sécurité en cas de dégradation.

Efficacité des politiques/filtres et alignement sur la gouvernance

Les contrôles de sécurité de l’IA, aussi sophistiqués soient-ils sur le plan technique, résistent rarement à l’épreuve du terrain — c’est-à-dire aux réalités de l’entreprise — lorsqu’ils sont inadaptés sur le plan opérationnel. Dans les environnements d’entreprise, les décisions relatives aux politiques ne sont généralement ni binaires ni immuables et relèvent, en définitive, de la gouvernance.

Les acheteurs doivent se poser les questions suivantes :

• Comment les politiques sont-elles définies, approuvées, versionnées et auditées ?
• Les politiques peuvent-elles être définies en fonction du rôle, de la sensibilité des données, de la zone géographique ou du contexte métier ?
• Le système peut-il expliquer pourquoi une décision a été prise ?
• Dans quelle mesure le système permet-il de mettre en œuvre des politiques reflétant la posture de conformité propre à l’organisation (réglementations sectorielles, politiques internes, restrictions d’utilisation acceptable), et comment ces politiques sont-elles maintenues au fil du temps ?
• Dans quelle mesure le système contribue-t-il efficacement à empêcher les réponses susceptibles d’entraîner des risques juridiques ou de non-conformité (par exemple, des conseils ou des recommandations qui enfreignent les règles ou normes applicables) ?

Les défaillances des politiques ne résultent souvent pas de mauvaises intentions, mais d’un décalage entre leur mise en œuvre technique et la réalité opérationnelle. Par exemple, un système d’IA peut bloquer à juste titre l’accès à certaines catégories de données, mais le faire d’une manière qui entrave des processus métier légitimes, poussant ainsi les utilisateurs à contourner entièrement les contrôles au moyen d’outils non autorisés. À l’inverse, des politiques définies de manière trop vague peuvent permettre l’exposition d’informations sensibles dans des contextes qui contreviennent à des obligations réglementaires ou contractuelles. Au fil du temps, des ajustements ponctuels visant à répondre aux réclamations peuvent compromettre l’intégrité des politiques et la responsabilisation. Les acheteurs doivent donc vérifier si les plateformes de sécurité de l’IA permettent une gouvernance structurée des politiques, notamment grâce à des approbations documentées, à un historique des versions et à la possibilité d’examiner les résultats de leur mise en œuvre. Sans cette rigueur, la pertinence des politiques devient subjective et difficile à défendre après un incident de sécurité.

Une application trop stricte des règles peut perturber les activités et éventuellement inciter des utilisateurs frustrés à mettre en place des systèmes d’IA « fantômes » non autorisés, tandis qu’une application trop laxiste peut entraîner des risques réglementaires et nuire à la réputation. Dans les deux cas, il s’agit d’un problème de gouvernance plutôt que d’une défaillance du modèle.

Une gestion efficace des politiques doit considérer celles-ci comme du code, avec un contrôle des versions, des workflows d’approbation et des pistes d’audit. Toute modification d’une politique doit faire l’objet d’approbations documentées de la part des parties prenantes chargées de la sécurité, des affaires juridiques et des activités métier avant son déploiement en production. Chaque décision d’application doit pouvoir être rattachée à une clause, une version et une section précises de la politique, ainsi qu’à la logique d’autorisation correspondante. Dans la mesure du possible, l’amélioration des politiques doit s’appuyer sur les données issues des tableaux de bord du système, notamment les tendances en matière de faux positifs, les blocages à fort impact et, lorsque cela est possible, des recommandations d’ajustement.

Les signaux d’alerte comprennent : une prise de décision opaque ; des ajustements ponctuels ou l’affirmation que les politiques sont « auto-apprenantes » sans qu’aucune responsabilité ne soit établie ; l’absence de contrôle des versions et de processus d’approbation pour les modifications apportées aux politiques ; des décisions d’application qui ne peuvent être rattachées à des clauses précises des politiques ; et des conflits entre politiques sans règles de résolution documentées.

IA agentique, sécurité de l’invocation d’outils et autorité déléguée

À mesure que les systèmes d’IA dépassent le cadre de l’assistance passive et commencent à agir pour le compte des utilisateurs et d’autres systèmes, une nouvelle catégorie de risques apparaît : la délégation d’autorité. Les systèmes d’IA agentique peuvent faire appel à d’autres outils, modifier des enregistrements et déclencher des workflows complexes à la vitesse des machines.

Les acheteurs qui évaluent la sécurité de l’IA agentique doivent examiner plusieurs domaines de contrôle clés :

• Quelles actions le système peut-il effectuer de manière autonome ?
• Comment les autorisations sont-elles limitées ?
• Dans quelle mesure le système fait-il respecter ce qu’un agent est autorisé ou non à faire lorsqu’il se voit déléguer le pouvoir d’agir au nom d’un utilisateur ?
• L’autonomie peut-elle être modulée en fonction du niveau de risque ou du contexte, sachant qu’en l’absence de limites claires, de petites erreurs peuvent se propager rapidement d’un système à l’autre ?
• Dans quelle mesure les contrôles du système empêchent-ils une invite d’amener le système à effectuer des actions qui dépassent les limites prévues (même si l’utilisateur « demande gentiment »), lorsqu’il est capable d’interagir avec des outils et agents externes ou de les exploiter ?
• Le système empêche-t-il ou contient-il efficacement les boucles récursives ou les comportements « incontrôlés » dans lesquels un agent continue d’agir sans atteindre l’objectif ?
• Dans quelle mesure le système empêche-t-il efficacement l’utilisation non autorisée d’outils, l’escalade des API ou des actions, l’autonomie excessive ou les boucles incontrôlées, ainsi que l’enchaînement non sécurisé de plusieurs outils ?
• Dans les architectures multi-agents, dans quelle mesure le système empêche-t-il que des données sensibles récupérées ou générées par un agent soient inutilement transmises à des agents en aval ou à des outils effectuant des tâches connexes ?
• Dans les architectures multi-agents, il est essentiel que les autorisations soient correctement transmises au-delà des frontières du système. Dans quelle mesure le système préserve-t-il le contexte d’identité tout au long des chaînes d’agents, afin de garantir que les agents et outils en aval opèrent strictement dans le cadre des autorisations de l’utilisateur d’origine, plutôt qu’avec des privilèges système élevés ?

Les défaillances liées à la délégation d’autorité surviennent souvent lorsque les systèmes d’IA bénéficient d’un accès étendu aux outils afin de permettre l’automatisation, sans contraintes appropriées. Par exemple, un agent d’IA chargé de résoudre des problèmes d’assistance peut être en mesure d’interroger des bases de données, de mettre à jour des enregistrements et d’envoyer des notifications aux utilisateurs. Une instruction mal interprétée ou un contexte inattendu peut entraîner une modification incorrecte des données ou une communication prématurée avec les clients. Ces actions étant exécutées à la vitesse des machines, les erreurs peuvent se propager avant qu’une supervision humaine puisse intervenir. Dans les workflows complexes, plusieurs actions individuelles à faible risque peuvent se combiner et avoir des conséquences majeures. Les acheteurs doivent vérifier si les contrôles de sécurité de l’IA appliquent le principe du moindre privilège, exigent une confirmation pour les actions sensibles et prévoient des mécanismes permettant de limiter ou de révoquer l’autonomie de manière dynamique. Il est essentiel de considérer le comportement agentique comme un enjeu de gouvernance afin d’éviter toute escalade silencieuse.

Dans les systèmes bien conçus, ces risques sont atténués grâce à des contrôles architecturaux. Les systèmes correctement encadrés appliquent le principe du moindre privilège à chaque outil, avec des limites d’autorisation documentées. Une autonomie progressive doit exiger une confirmation pour les actions à impact modéré et une approbation humaine pour celles à fort impact, tandis que la préservation du contexte d’identité garantit que les agents héritent des autorisations de l’utilisateur, et non de celles du système. Lorsque les utilisateurs demandent des opérations sensibles, les agents ne doivent récupérer que les informations autorisées tout en bloquant les accès non autorisés. Des mécanismes coupe-circuit doivent interrompre rapidement les boucles incontrôlées, et toutes les actions des agents doivent être intégralement consignées, avec le raisonnement suivi, les contrôles d’autorisation et les résultats.

Ces contrôles mettent en évidence une distinction importante entre les contraintes architecturales, qui empêchent techniquement un agent d’utiliser certains outils ou d’effectuer certaines actions, et les contraintes comportementales, où l’agent pourrait effectuer l’action, mais reçoit pour instruction de ne pas le faire. Dans la mesure du possible, les limites critiques pour la sécurité doivent reposer sur des contrôles architecturaux plutôt que sur de simples instructions comportementales.

Les signaux d’alerte comprennent : Parmi les signes révélateurs d’une gouvernance défaillante des agents figurent l’octroi d’un accès généralisé aux outils ou le recours au seul alignement du modèle pour prévenir les abus ; l’absence de limites d’autorisation documentées pour chaque outil ; l’incapacité à préserver le contexte d’identité afin de garantir que les agents héritent des autorisations des utilisateurs ; l’incapacité à détecter les séquences d’actions dangereuses au moyen d’une analyse en chaîne ; ainsi qu’une journalisation incomplète des actions des agents, sans consignation du raisonnement ni des contrôles d’autorisation.

Observabilité, audit et analyse forensique

Lorsqu’un problème survient dans un système d’IA, il est important de pouvoir démontrer comment et pourquoi il s’est produit, voire de pouvoir le reproduire.

Les acheteurs doivent demander s’il est possible de reconstituer de bout en bout les interactions avec l’IA, notamment les entrées, le contexte, les politiques, les sorties, les actions, les outils sollicités et les données consultées. Les systèmes efficaces doivent également permettre une surveillance continue et l’émission d’alertes, afin que les équipes de sécurité puissent détecter les comportements anormaux, les chaînes d’actions dangereuses ou les interactions inattendues entre agents avant que les incidents ne s’aggravent. Sans une visibilité suffisante sur le comportement du système, la réponse aux incidents repose sur des conjectures et les efforts de gouvernance perdent en crédibilité.

Lorsque des incidents liés à l’IA surviennent, les organisations peuvent être tenues de fournir des preuves plutôt que des explications. En l’absence de journaux détaillés des entrées, du contexte récupéré, des politiques appliquées, des résultats et des actions, les équipes chargées de la réponse aux incidents sont contraintes de reconstituer les événements à partir d’hypothèses plutôt que de faits. Cette situation est particulièrement problématique dans les systèmes d’IA, dont le comportement peut ne pas être reproductible en raison de leur caractère non déterministe. Par exemple, une autorité de régulation ou un auditeur interne peut demander pourquoi certaines informations ont été divulguées ou pourquoi une action automatisée a été exécutée. Or, sans observabilité de bout en bout, les organisations ne peuvent pas démontrer l’intention, la proportionnalité ni l’efficacité des contrôles. Les acheteurs doivent donc vérifier si les plateformes de sécurité de l’IA offrent le niveau de visibilité nécessaire pour faciliter la réponse aux incidents, la production de rapports de conformité et le retour d’expérience après incident.

Une journalisation complète doit permettre de reconstituer les requêtes de bout en bout, notamment le prompt d’origine, le contexte récupéré et ses sources, le contexte d’identité et d’autorisation, les politiques évaluées et leurs versions, la sortie du modèle, les modifications apportées, la réponse finale adressée à l’utilisateur et les actions en aval. Les événements de sécurité liés à l’IA doivent pouvoir être intégrés aux systèmes SIEM avec une latence minimale, afin de permettre leur corrélation avec le trafic réseau et les événements d’authentification. Les violations critiques doivent déclencher rapidement des alertes fournissant suffisamment de contexte pour permettre une intervention immédiate, ainsi que des tableaux de bord unifiés permettant de suivre les indicateurs de sécurité, de performance et de qualité, avec une analyse des tendances.

Du point de vue de la gouvernance, des risques et de la conformité (GRC), les systèmes qui ne peuvent pas être observés ne peuvent pas être gouvernés.

Intégration et interopérabilité

Les contrôles de sécurité de l’IA fonctionnant de manière isolée créent des angles morts et empêchent une réponse coordonnée. Les architectures de défense en profondeur nécessitent des contrôles qui partagent les données de télémétrie et coordonnent l’application des politiques entre les différentes couches de sécurité.

Gestion des identités et des accès : Les limites d’autorisation doivent s’étendre de l’authentification de l’utilisateur jusqu’à la sortie finale, en passant par la récupération des données. Les organisations doivent évaluer la manière dont les systèmes s’intègrent aux fournisseurs d’identité et vérifier si les changements de rôle sont correctement répercutés. Les systèmes doivent conserver le contexte d’autorisation lorsque des agents d’IA agissent pour le compte d’utilisateurs, avec des chaînes d’autorisations traçables ; les politiques d’accès doivent par ailleurs être héritées des modèles RBAC existants, sans configuration en double. Au niveau de la récupération, les systèmes doivent appliquer le principe du moindre privilège en filtrant les documents selon le niveau d’autorisation de l’utilisateur à l’origine de la demande.

Intégration au SIEM : Les événements de sécurité liés à l’IA doivent être corrélés avec les données de télémétrie de sécurité au sens large. Pour ce faire, les systèmes doivent exporter les événements vers les plateformes SIEM dans des formats standard tels qu’OCSF ou CEF, avec une latence minimale. Les formats de journaux propriétaires empêchent toute corrélation avec le trafic réseau, les événements d’authentification et les schémas d’accès aux données. Les organisations doivent vérifier s’il est possible de créer des règles de détection personnalisées à partir des événements de sécurité liés à l’IA et si les alertes s’intègrent aux processus existants de réponse aux incidents.

Alignement sur les référentiels de conformité : Les solutions doivent établir une correspondance entre les contrôles et les référentiels reconnus, en précisant la couverture des contrôles et les éléments probants d’audit. Les rapports de conformité doivent également pouvoir être personnalisés en fonction d’exigences réglementaires spécifiques. Les déclarations générales de conformité dépourvues de correspondances précises avec les contrôles sont insuffisantes.

Prise en charge des API et de l’automatisation : Les opérations de sécurité modernes nécessitent un contrôle programmatique, avec des systèmes prenant en charge les workflows de type « policy as code » et l’intégration de l’infrastructure en tant que code. Les API non documentées ou fréquemment modifiées fragilisent les intégrations.

Ce que les acheteurs doivent exiger avant d’acheter

Les entreprises devraient exiger des preuves plutôt que des schémas d’architecture et des supports marketing séduisants, des résultats reproductibles plutôt que des démonstrations bien rodées, et une validation indépendante plutôt que de simples affirmations.

Les acheteurs doivent s’attendre à ce que les fournisseurs expliquent les limites de leurs solutions, prennent en charge des tests réalistes et fournissent des éléments capables de résister à un examen approfondi.

Les contrôles de sécurité qui ne peuvent être ni testés ni expliqués ne doivent pas être considérés comme fiables pour protéger les systèmes d’IA essentiels à l’activité.

Se préparer à une validation indépendante

Évaluer la sécurité de l’IA est difficile, mais cette difficulté ne saurait justifier l’absence de validation. Les tests indépendants restent l’un des rares moyens dont disposent les entreprises pour s’assurer que les contrôles et les fonctionnalités se comportent comme annoncé.

Les acheteurs doivent s’attendre à des méthodes de validation qui reflètent les conditions réelles, notamment les entrées adverses, les scénarios de dégradation et les exigences de gouvernance. Les fournisseurs qui refusent de participer à une validation sérieuse font preuve d’immaturité, et non de solidité.

La validation ne doit pas non plus être considérée comme un exercice ponctuel. Les contrôles de sécurité de l’IA qui se révèlent efficaces lors de l’évaluation initiale peuvent perdre en efficacité à mesure que les menaces évoluent, que les capacités des modèles progressent et que de nouvelles techniques d’attaque apparaissent. Le paysage des menaces évolue rapidement, et les incidents de sécurité liés à l’IA peuvent faire intervenir des méthodes d’attaque encore jamais observées. Les organisations doivent donc définir des exigences de validation continue en complément des tests initiaux.

Intégration des renseignements sur les menaces : Les organisations doivent évaluer la fréquence à laquelle les fournisseurs mettent à jour leurs solutions afin d’y intégrer les vulnérabilités récemment divulguées par les fournisseurs de renseignements sur les menaces et les organismes de recherche en sécurité. Les fournisseurs doivent démontrer leur capacité à détecter les attaques récemment publiées, et ne pas se limiter aux données d’entraînement historiques. L’intégration automatisée des renseignements sur les menaces permet de réagir plus rapidement que les processus d’examen manuels.

Compatibilité avec l’évolution des modèles : Les capacités des modèles de fondation évoluent rapidement, ce qui exige une adaptation des contrôles de sécurité. Les organisations doivent demander des données sur l’efficacité de la détection propres à chaque modèle pour différents modèles de fondation et se méfier des affirmations génériques dépourvues de preuves quantitatives, qui peuvent masquer des angles morts. Les fournisseurs doivent communiquer des calendriers précis pour la certification des nouvelles versions des modèles, ainsi que des mesures d’atténuation provisoires pendant les périodes où celles-ci ne sont pas encore certifiées.

Validation pilotée par les acheteurs : Les organisations doivent tester en permanence les contrôles plutôt que de se fier uniquement à la validation des fournisseurs. Les acheteurs doivent négocier des droits contractuels leur permettant de mener régulièrement des exercices de red team, des tests automatisés continus de contournement et des tests A/B des modifications de politiques en production. Les fournisseurs qui limitent les tests effectués par leurs clients ou refusent de communiquer des données télémétriques détaillées font preuve d’un manque de maturité.

Les organisations devraient considérer la validation comme un partenariat continu plutôt que comme une évaluation ponctuelle, afin de préserver leur efficacité à mesure que le paysage des menaces évolue. Sans cette pratique, même des contrôles bien conçus peuvent finir par se révéler insuffisants face aux nouvelles techniques d’attaque.

Conclusion : des affirmations à la responsabilité

L’achat d’une solution de sécurité pour l’IA n’est pas une simple décision technique ; c’est une décision de gouvernance aux conséquences à long terme.

Les entreprises qui posent d’emblée les questions difficiles sont mieux armées pour gérer les risques, justifier leurs décisions et éviter les défaillances qui auraient pu être prévenues.

La sécurité de l’IA ne pourra être assurée par la nouveauté ou l’abstraction, mais par la responsabilisation, la transparence et une évaluation rigoureuse.

© 2026 NSS Labs®. Tous droits réservés. Aucune partie de cette publication ne peut être reproduite, copiée ou numérisée, stockée dans un système d’archivage, envoyée par e-mail, ni diffusée ou transmise de quelque autre manière que ce soit sans le consentement écrit exprès de NSS Labs (« nous »).