TL; DR
L’expression « menaces à la sécurité de l’IA » recouvre deux choses différentes : les attaques visant les systèmes d’IA et les attaques utilisant l’IA comme une arme. Ces listes nécessitent des mécanismes de contrôle, des responsables et des preuves différents, et la plupart les mélangent, ce qui explique pourquoi il est si difficile d'agir. Les cinq premières ci-dessous ciblent votre IA. Les cinq suivantes utilisent l'IA contre votre chaîne d'approvisionnement.
- Les menaces qui pèsent sur les systèmes d'IA résident principalement dans leur configuration, et non dans le modèle lui-même. Le périmètre de l'outil, les informations d'identification sous lesquelles un agent s'exécute, un fichier de règles, un
.mcp/servers.jsonAucun élément de ce point d'entrée n'est accessible depuis le point de terminaison du modèle, ce qui explique pourquoi les tests d'intrusion menés par une équipe dédiée ne révèlent aucune anomalie. - Les attaques pilotées par l'IA arrivent principalement via les dépendances, et non via votre périmètre. Noms de paquets hallucinés enregistrés par des attaquants, vers auto-propagateurs utilisant des identifiants de développeur, clés de fournisseurs d'IA comme objectif.
- Neuf des dix questions portent sur des choses précises. Quels serveurs MCP, quels agents, quelle étendue, quelles informations d'identification, quel fichier de règles, quel package ? Un document de stratégie ne répond à aucune de ces questions.
- Chacune des dix conditions a une condition préalable. On ne peut pas défendre une ressource IA qu'on n'a jamais cartographiée, ce qui fait de la découverte l'étape précédant les commandes plutôt que celle qui les suit.
Quels sont les deux types de menaces à la sécurité liées à l'IA ?
La plupart des listes de menaces à la sécurité liées à l'IA mélangent les deux, ce qui explique pourquoi il est difficile d'agir en conséquence.
- Menaces pesant sur les systèmes d'IA Considérez votre IA comme la cible. Une personne manipule un modèle, corrompt ses instructions ou abuse des permissions accordées à un agent. Le rôle du défenseur est de contenir l'attaque : limiter l'étendue des capacités d'une IA compromise.
- Attaques pilotées par l'IA Considérez l'IA comme l'instrument de l'attaquant. La cible est votre logiciel habituel : dépendances, identifiants, systèmes de compilation, développeurs. Le rôle du défenseur est de détecter rapidement les attaques, car l'économie de ces attaques a évolué et leur volume a explosé.
Ils nécessitent des contrôles, des responsables et des preuves différents. Une équipe ayant testé la sécurité de son chatbot n'a rien fait contre le slopsquatting. Une équipe dotée d'un excellent système de filtrage des dépendances peut néanmoins exécuter un agent disposant d'un accès en écriture aux référentiels de production, sans limitation de portée. Ces deux situations constituent des menaces pour la sécurité de l'IA. Aucune ne protège l'autre.
Menaces pesant sur les systèmes d'IA : les cinq plus fréquentes
01. Injection rapide atteignant un puits d'outil
Du contenu non fiable arrive, est intégré à une invite système, et l'agent distant peut alors exécuter des outils. Ce n'est pas l'invite elle-même qui constitue la vulnérabilité, mais le cheminement entre une entrée non fiable et une fonctionnalité dangereuse.
C’est pourquoi le filtrage des prompts à lui seul est décevant. Il renforce une extrémité de la chaîne, alors que la question intéressante est de savoir si un garde-fou est prévu entre l’entrée et l’appel de l’outil. Top 10 de l'OWASP pour les candidatures au LLM Elle maintient l'injection rapide en tête de liste, mais l'associe à une intervention excessive précisément pour cette raison.
À surveiller : entrées non fiables atteignant une invite système, contexte d'alimentation de récupération sans assainissement et outils accessibles sans garde-fou intermédiaire.
02. Règles malveillantes et fichiers de compétences
Un fichier de règles est un fichier texte brut. commitCe document, semblable à de la documentation, a été examiné et relu, et il indique à l'assistant la marche à suivre. Les caractères de largeur nulle rendent les lignes invisibles dans un pull request différent tout en restant parfaitement lisible pour l'agent.
ATLAS MITRE Ce cas est répertorié comme une porte dérobée dans un fichier de règles, étude de cas AML.CS0041. Le réviseur approuve une convention de formatage. L'agent lit une instruction lui demandant d'importer un paquet contrôlé par un attaquant sans en faire mention.
À surveiller : Les fichiers de règles, les fichiers de compétences et les modèles d'invites sont analysés comme du code plutôt que comme de la prose, avec détection des caractères invisibles.
03. Configuration non sécurisée du serveur MCP
Configuration MCP C'est là qu'un agent reçoit ses ordres et que les identifiants sont collectés. Ces deux aspects posent problème. La vulnérabilité CVE-2025-6514, divulguée en juillet 2025, était une injection de commandes système critique dans un pont MCP largement utilisé. Avec un score CVSS de 9.6, elle permettait l'exécution de commandes arbitraires sur le client lors de la connexion à un serveur non fiable.
La gestion des identifiants est encore plus problématique car elle est passive. Une étude menée en 2026 a révélé que plus de 24 000 secrets étaient stockés dans des fichiers de configuration MCP sur GitHub public, dont plus de 2 000 étaient encore valides.
À surveiller : un inventaire des serveurs MCP en service, leurs versions, leurs outils déclarés et la détection des secrets exécutés sur les fichiers de configuration.
04. Agence excessive
Un agent doté de larges capacités d'exécution et d'identifiants à longue durée de vie constitue une source permanente d'élévation de privilèges, prête à être exploitée. Il suffit d'une faille pour que cela nuise. Un agent mal informé et un agent compromis causent des dommages similaires lorsqu'ils disposent tous deux d'un accès en écriture dont ils n'ont jamais eu besoin.
C'est le problème le moins glamour de la liste, mais aussi le plus courant. Sa solution est également la plus simple : la réduction du périmètre. Or, cette solution est rarement appliquée, car personne ne s'approprie la question.
À surveiller : quels agents existent, ce que chacun peut invoquer, sous quelles autorisations et si quelqu'un a approuvé cette étendue.
05. Modèles, ensembles de données et dépendances en IA empoisonnés
La pile d'IA repose sur des packages et des artefacts hébergés classiques. Les modèles sont téléchargés depuis des plateformes publiques. Les jeux de données proviennent de sources diverses. Ces deux éléments présentent le même problème de provenance que toute dépendance, avec toutefois moins d'outils et un contrôle bien moindre.
À surveiller : les modèles, les cadres et les ensembles de données traités comme des composantes de la chaîne d'approvisionnement, avec la même analyse de composition et les mêmes Le suivi des CVE, comme pour le reste de vos dépendances.
Attaques pilotées par l'IA : les cinq qui transforment votre chaîne d'approvisionnement
06. Squatting de mauvaise qualité
Une étude présentée à USENIX Security en 2025 a généré 2.23 millions d'échantillons de code répartis sur 16 modèles et a révélé que 19.7 % des paquets recommandés étaient inexistants, produisant ainsi plus de 205 000 noms hallucinés uniques. Environ 43 % de ces noms sont réapparus lors d'exécutions répétées de la même invite de commande, ce qui les rend exploitables.
Les attaquants n'ont plus besoin de compromettre un responsable de la maintenance. Ils enregistrent le nom inventé par votre agent et attendent l'installation. Le paquet ne comporte ni signature ni avertissement, car il est nouveau et personne ne l'a jamais vu auparavant.
À surveiller : Un système de filtrage des logiciels malveillants basé sur le comportement plutôt que sur la réputation, appliqué à chaque dépendance ajoutée par un agent.
07. Vers de la chaîne d'approvisionnement à propagation automatique
Le Ver npm de septembre 2025 Ce moment a marqué le passage où les machines des développeurs sont devenues le vecteur de propagation plutôt que la cible. Ce schéma s'est répété à grande échelle jusqu'en 2026. Chaque identifiant de développeur compromis publie la prochaine vague de paquets compromis, et l'impact se propage au lieu de s'amplifier.
À surveiller : activité éditoriale anormale, inhabituelle commit des schémas et une utilisation des identifiants qui ne correspondent pas au comportement normal du développeur.
08. Ciblage étatique des identifiants d'IA
En mars 2026, un logiciel comptabilisant environ 100 millions de téléchargements hebdomadaires a été compromis pendant quelques heures, dans le but d'obtenir des clés API de fournisseurs d'IA. La durée de cette compromission était volontairement courte : suffisamment longue pour permettre la collecte des données, mais suffisamment courte pour minimiser les risques de détection.
Les identifiants d'IA sont désormais une cible de premier ordre, car ils permettent d'acheter de la puissance de calcul, un accès et une identité plausible. Les attaques visant à les voler ont fortement augmenté entre fin 2025 et début 2026.
À surveiller : Les clés des fournisseurs d'IA sont traitées comme des secrets, avec les mêmes procédures de détection et de révocation que les identifiants cloud.
09. Logiciel malveillant créé ou implanté à l'aide d'un LLM
En 2026, des cas documentés d'utilisation d'un modèle de langage comme arme pour implanter du code malveillant dans le flux de travail d'un agent ont été recensés. Le problème ne réside pas dans la nouveauté du logiciel malveillant, mais plutôt dans le fait que l'identification de son auteur n'était plus un obstacle, ce qui a entraîné une augmentation du nombre de codes malveillants d'apparence plausible accessibles aux attaquants.
À surveiller : détection cela ne dépend pas du fait d'avoir déjà vu l'échantillon.
10. Analyse de l'effondrement des capacités
Il ne s'agit pas d'une attaque, c'est pourquoi elle figure en dernier et pourquoi elle est si importante. Lorsqu'un agent produit mille fichiers par semaine, la revue de code cesse d'être un contrôle et devient une simple file d'attente. Toutes les autres menaces de cette liste deviennent plus faciles à gérer lorsque le dernier contrôle humain est saturé.
À surveiller : Les résultats sont classés par exploitabilité plutôt que par gravité brute, de sorte que seul le petit nombre de résultats menaçant la production parvienne effectivement à un développeur.
La carte recense dix menaces. Traiter chacune d'elles prendrait plus de temps qu'un article de blog, nous avons donc eu une discussion approfondie. Dans cet épisode de Discussions sur SafeDevJesús Cuadrado, PDG de Xygeni, s'entretient avec Atanas Nikolov, expert en DevSecOps et SSDLC Responsable technique, sur les logiciels malveillants polymorphes, l'injection de messages, la falsification de modèles et les solutions efficaces pour les contrer. Sans formulaire, pas de barrière.
Pourquoi ne peut-on pas défendre des ressources d'IA que l'on n'a pas cartographiées ?
Relisez les dix questions, et le schéma devient évident. Neuf d'entre elles portent sur des éléments précis : quels serveurs MCP, quels agents, quelle étendue, quelles informations d'identification, quel fichier de règles, quel package.
Aucun document de politique ne peut répondre à ces questions. Elles dépendent d'un inventaire, or la plupart des organisations n'en possèdent pas. L'IA a été déployée rapidement par les développeurs, sans procédure standardisée, sans appel d'offres ni inscription dans un référentiel la présentant comme telle.
Cela fait de la cartographie une condition préalable plutôt qu'une première étape. Un programme de sécurité contre les menaces liées à l'IA qui commence par des contrôles les appliquera à l'IA qu'il connaît, un sous-ensemble qu'il ne peut dimensionner. La découverte doit précéder : modèles, frameworks, jeux de données, points d'inférence, agents, serveurs MCP, compétences, invites et outils de programmation IA utilisés par vos développeurs, ainsi que leurs interactions. En effet, un élément isolé est peu informatif et le risque se concentre tout au long de la chaîne.
Le Cadre de gestion des risques NIST AI La fonction `map` est placée avant `measure` et `manage` pour la même raison : c’est la fonction la moins intéressante du framework, et pourtant celle dont tout le reste dépend.
Quelles menaces liées à la sécurité de l'IA devez-vous traiter en priorité ?
Pas les plus sophistiqués. Les plus accessibles.
- Cette semaine: Recensez vos serveurs MCP et analysez leurs fichiers de configuration à la recherche de secrets. La menace 03 présente le ratio exposition/effort le plus élevé de la liste, et pourtant, elle n'a quasiment jamais été prise en compte.
- Ce mois-ci: Identifiez vos agents et notez les actions que chacun peut effectuer, ainsi que les identifiants sous lesquels ils peuvent les entreprendre. Cela permet de contrer la menace 04, la plus courante et la plus facile à éliminer.
- Ce trimestre : Intégrez un filtrage comportemental des logiciels malveillants en amont de chaque dépendance ajoutée par un agent. Cela permet de couvrir simultanément les menaces 06, 07 et 09, car toutes trois, étant nouvelles, échappent aux contrôles basés sur la réputation.
Tout le reste peut attendre après ces trois-là, car tout le reste suppose que vous savez déjà ce que vous possédez.
Les organisations qui géreront efficacement les menaces de sécurité liées à l'IA en 2027 ne seront pas celles dont les modèles seront les mieux évalués. Ce seront celles qui pourront répondre, n'importe quel mardi, à la question de savoir quelles IA sont exécutées dans leurs logiciels et à quelles données elles sont autorisées à accéder. Voilà la situation. Xygéni a été conçu autour de : la découverte continue de chaque ressource d'IA dans les référentiels et pipelines, les risques évalués par rapport aux cadres que vos auditeurs reconnaissent déjà, et le contrôle de la chaîne d'approvisionnement qui détecte ce qui n'a pas encore été identifié.
Dix menaces, deux catégories, une carte sous-jacente.
QFP
Les menaces à la sécurité de l'IA sont-elles réellement différentes des menaces à la sécurité des applications ordinaires ?
En partie. Les conséquences sont connues : exécution de code, vol d’identifiants, fuite de données. Ce qui change, c’est le point d’entrée et la vitesse. Les fichiers de configuration, auparavant inertes, contiennent désormais des instructions exécutables, et le coût de production d’un code malveillant convaincant a diminué. Vos contrôles existants restent pertinents ; ils ne couvrent simplement plus l’intégralité du système.
L'expérimentation de nos modèles par une équipe rouge permet-elle de contrer la plupart de ces menaces ?
Cela répond partiellement à l'un de ces problèmes. Le test d'intrusion (Red Teaming) permet de déterminer si un modèle peut être amené à refuser une action, ce qui est véritablement utile. Il ne peut pas consulter le périmètre de l'outil, les identifiants, le fichier de règles ni la configuration MCP, car aucun de ces éléments n'est accessible via le point de terminaison du modèle. Un rapport d'intrusion sans erreur et un agent disposant de privilèges excessivement élevés peuvent coexister sans contradiction.
Laquelle de ces menaces à la sécurité de l'IA est la plus sous-estimée ?
Il s'agit d'une vulnérabilité excessive, et de loin. Sans CVE, sans exploit à démontrer, et sans fournisseur de produit dédié, elle ne génère aucune urgence. C'est aussi ce qui distingue un incident circonscrit d'un incident non circonscrit, car son étendue détermine la propagation des dégâts après la première erreur.
Comment les attaques pilotées par l'IA modifient-elles ce que nous devrions mesurer ?
Ils déplacent l'indicateur pertinent de la gravité vers le temps. Lorsque les paquets malveillants sont générés plus rapidement que les signatures ne sont publiées, le nombre de vulnérabilités critiques ouvertes importe moins que la rapidité avec laquelle une nouvelle vulnérabilité est signalée. Il convient de mesurer le délai entre l'intégration d'une dépendance dans le code source et son analyse, ainsi que le délai entre le signalement d'une vulnérabilité et sa transmission à un développeur capable d'agir.
