Qu’est-ce que la cybersécurité basée sur l’IA ?

La cybersécurité de l'IA consiste à sécuriser l'intelligence artificielle en tant que partie intégrante de votre surface d'attaque : les modèles, les ensembles de données, les agents, les serveurs MCP, les invites et le code généré par l'IA au sein de vos logiciels, ainsi que les nouvelles techniques d'attaque qui les ciblent. Elle couvre également l'utilisation de l'IA pour renforcer la défense, mais c'est la première approche qui crée aujourd'hui les vulnérabilités. Voilà, en résumé, ce qu'est la cybersécurité de l'IA. Il est important d'en prendre connaissance.cisIl faut en parler, car ce terme est utilisé pour deux choses très différentes, et acheter le mauvais laisse l'autre sans protection.

Signification de la cybersécurité de l'IA, dans deux directions #

La signification de la cybersécurité liée à l'IA se divise selon une ligne simple : protégez-vous l'IA ou êtes-vous protégé par elle ?

Sécuriser l'IA. Votre organisation construit et se développe grâce à l'IA. Cela introduit des ressources non inventoriées et des modes de défaillance pour lesquels les outils conventionnels n'ont jamais été conçus : une invite acceptant des entrées non fiables, un agent disposant de permissions excessives, un jeu de données altérant un modèle, un serveur MCP non approuvé. C'est là que les incidents surviennent.

L'IA au service de la sécurité. L'apprentissage automatique appliqué à la détection, au triage, à l'explication et à la correction : réduction du bruit des alertes, priorisation des anomalies exploitables et élaboration du correctif. C'est de là que provient l'efficacité.

La plupart des fournisseurs et des articles confondent les deux. En matière de cybersécurité de l'IA, ce qui importe concrètement, c'est qu'il s'agit de programmes distincts, gérés par des responsables différents. L'un concerne la surface d'attaque, l'autre la productivité.

Que protège la cybersécurité basée sur l'IA ? #

Un inventaire avant tout contrôle. Chaque élément ci-dessous représente un actif dont l'équipe de sécurité est désormais responsable.

• Modèles, qu'elle soit auto-hébergée, optimisée ou appelée via une API de fournisseur
• Jeux de données utilisé pour la formation, le réglage fin, l'évaluation et la récupération
• Agents et serveurs d'agents qui agissent de manière autonome au sein de vos systèmes
• serveurs MCP qui exposent des outils et des données à ces agents
• Invites, fichiers de compétences, fichiers de règles et guardrails, la couche de configuration qui régit le comportement de l'IA
• Points d'arrêt de l'inférence et les qualifications qui leur permettent d'y parvenir
• Assistants de codage IA utilisés par vos équipes, et le code qu'elles génèrent
• dépendances de l'IA: les frameworks et les packages que votre pile d'IA utilise

Remarquez la faible proportion de code applicatif. C'est du pré-code.cispourquoi un SAST Un outil, un agent EDR et un outil de surveillance de la posture du cloud peuvent tous signaler une activité normale alors qu'un agent sur un ordinateur portable exfiltre des données via son propre compte de messagerie. Ces opérations ne constituent pas du code applicatif et ne sont donc pas couvertes par les outils que vous utilisez déjà.

Les trois attaques qui n'existent que grâce à l'IA #

Savoir à quelle famille d'IA vous vous adressez vous indique où se situe le contrôle, et c'est là que la signification de la cybersécurité de l'IA cesse d'être abstraite.

La première famille cible les instructions du modèle. L'injection rapide a conservé la première place dans le Top 10 de l'OWASP pour les candidatures au LLM Depuis l'existence de cette liste, pour une raison simple : tout point où un modèle lit un texte qu'il n'a pas écrit constitue un point d'entrée. La version dangereuse est indirecte. Personne ne saisit l'attaque, le modèle la récupère, par exemple à partir d'un ticket d'assistance, d'une page web ou d'un pull request Un commentaire ou un document téléchargé par un utilisateur. Le modèle ne fait pas la distinction entre les instructions et le contenu ; il interprète donc les deux. Donnez-lui des outils et cette même technique devient une injection d'outils : modifiez la fonction qu'il attribue à un outil, et il agira contre vous en utilisant vos propres identifiants. Un pouvoir excessif amplifie les dégâts. Un agent disposant de permissions plus étendues que nécessaire pour sa tâche peut transformer un simple désagrément en un véritable incident.

La deuxième famille cible la couche de configuration. Les invites, les fichiers de règles, les fichiers de compétences et les définitions du serveur MCP déterminent le comportement de l'IA dans votre environnement, et aucun de ces éléments ne fait partie du code applicatif. La faille de sécurité exploitée dans les fichiers de règles a révélé l'étendue de ce phénomène : des caractères Unicode de largeur nulle contiennent des instructions invisibles à l'œil nu pour un examinateur humain, l'assistant les exécute sans jamais les mentionner dans ses réponses. Cette technique est répertoriée dans… ATLAS MITRE comme AML.CS0041. La même couche stocke régulièrement les identifiants du fournisseur en clair et accorde aux assistants un accès en lecture à une partie du système de fichiers bien plus importante que prévu. codage agentique, Cette couche fait office de volant, et presque personne ne la vérifie.

La troisième famille cible la chaîne d'approvisionnement de l'IA. Les modèles, les jeux de données et les packages associés proviennent de sources externes. Le slopsquatting en est l'exemple le plus flagrant : les modèles de langage inventent des noms de packages, les attaquants les enregistrent, et l'agent installe le code malveillant sur demande. Une étude présentée à USENIX Security 2025 a révélé que 19.7 % des packages recommandés par les modèles de langage n'existent pas, et que les noms inventés sont suffisamment fréquents pour être exploités. À cela s'ajoutent des données d'entraînement et de récupération corrompues, des embeddings qui divulguent leur code source, des serveurs MCP non fiables directement connectés à un agent, et des frameworks d'IA vulnérables intégrés comme dépendances.

Sous ces trois aspects se cache une IA fantôme : les modèles, les agents, les assistants et serveurs MCP Ce système fonctionne déjà sans approbation, examen ni inventaire. C'est l'état par défaut dans la plupart des organisations, et c'est pourquoi le premier contrôle consiste toujours à utiliser une liste.

Qu'est-ce qui ne l'est pas ? #

Il ne s'agit pas de gouvernance de l'IA. La gouvernance détermine s'il convient d'utiliser un modèle et dans quelles conditions. La cybersécurité de l'IA détermine si le modèle, l'agent et les interconnexions entre eux sont vulnérables aux attaques.

Il ne s'agit pas d'un filtre placé devant un chatbot. Le filtrage des invites d'exécution n'est qu'un contrôle parmi d'autres. Il ignore tout du serveur MCP sur l'ordinateur portable d'un développeur, du fichier de règles corrompu dans le dépôt et des informations d'identification dans une configuration AI.

Cela n'est pas couvert par ce que vous utilisez déjà. La sécurité applicative traditionnelle s'arrête au référentiel et ignore la notion de modèle. Les outils de sécurité des terminaux surveillent le système d'exploitation sans prendre en compte les paquets, les serveurs MCP ni les assistants. Les attaques par IA exploitent cette faille.

Il ne s'agit pas uniquement d'IA générative. L'apprentissage automatique classique dans le domaine de la fraude, de la tarification et de l'évaluation des risques est également une cible, par le biais de l'empoisonnement, de l'évasion et de l'extraction de modèles.

Les cadres qui définissent le domaine #

Top 10 de l'OWASP pour les candidatures au LLM: la taxonomie de travail pour les risques liés aux applications LLM, et celle à laquelle la plupart des équipes de sécurité associent leurs résultats

Les 10 meilleures applications agentiques selon l'OWASP en 2026: la liste complémentaire des systèmes autonomes utilisant des outils, publiée en décembre 2025

Projet de sécurité OWASP GenAI: l'effort global, incluant la sécurité des données, les recommandations pour les serveurs MCP et les ressources d'entraînement aux tests d'intrusion

Cadre de gestion des risques NIST AI et son profil d'IA générative : le vocabulaire de gouvernance que les régulateurs et les conseils d'administration reconnaissent

ATLAS MITRE: la base de connaissances sur les techniques adverses pour les systèmes d'IA, avec des études de cas réels

Loi de l'UE sur l'IA: le cadre juridique, y compris les obligations de documentation technique qu'un inventaire IA vous aide à respecter

Par où commencer #

Inventaire. Identifiez tous les modèles, ensembles de données, agents, serveurs MCP et assistants IA utilisés, à partir du code, des dépendances et de la configuration plutôt que par le biais d'une enquête.

Cartographier les relations. Le risque réside dans le câblage : quel agent accède à quel outil, quel ensemble de données alimente quel modèle.

Lisez la couche de configuration. Considérez les invites, les fichiers de compétences, les fichiers de règles et les définitions MCP comme des artefacts de sécurité et examinez-les comme du code.

Autorisations d'accès. Donnez à chaque agent la surface d'outils la plus réduite possible et l'autonomie minimale que lui permet sa fonction.

Appliquez-le là où il s'exécute. La plupart des risques liés à l'IA se situent sur les machines des développeurs ; la politique de sécurité doit donc s'appliquer au niveau du terminal, avant l'exécution d'un serveur non autorisé ou d'un package malveillant.

Sécuriser l'IA que vous utilisez et l'IA que vous créez avec #

La réponse pratique à la question de la cybersécurité de l'IA est qu'elle commence par la visibilité et se termine par l'application des règles. Xygeni détecte tous les actifs IA de votre infrastructure. SDLCCette analyse, qui recense les modèles, agents, serveurs MCP, jeux de données, fichiers de compétences et invites non déclarés, cartographie leurs connexions et détecte les risques spécifiques : injection d’invites et d’outils, instructions malveillantes dans les règles et les fichiers de compétences, configuration MCP non sécurisée, secrets dans les fichiers d’IA et dépendances d’IA squattées. Les résultats sont alignés sur le Top 10 OWASP pour les applications LLM et indiquent le fichier et la ligne exacts. Une nomenclature d’IA (AI-BOM) fournit aux auditeurs un document justificatif, et la politique est appliquée au niveau du développeur, là où la plupart des risques liés à l’IA se manifestent.

Les mêmes informations s'appliquent aux données issues des scanners que vous possédez déjà ; la sécurité par IA vient donc compléter votre infrastructure au lieu de la remplacer. Découvrez à quoi vos agents sont connectés sur Xygéni.

QFP #