Un fichier de compétences. Un fichier de règles. Une configuration de serveur MCP. Trois lignes de texte brut. commitCes documents ressemblent à de la documentation, ils sont relus comme de la documentation, et aucun ne ressemble à du code. Pourtant, chacun d'eux peut discrètement modifier les instructions données à votre assistant IA et les ressources auxquelles il est autorisé à accéder. C'est la vérité dérangeante concernant la sécurité de l'IA. en 2026.L'industrie a passé deux ans à s'inquiéter du contenu du code généré par l'IA. Le problème le plus complexe s'est avéré être la chaîne d'approvisionnement de l'IA elle-même : les modèles, les agents, les serveurs MCP et les fichiers de configuration qui coexistent désormais avec votre code source et vos dépendances open source, souvent sans inventaire ni contrôle. C'est précisément pourquoi la sécurité de la chaîne d'approvisionnement de l'IA est devenue une discipline à part entière, et pourquoi choisir la bonne entreprise spécialisée en sécurité de l'IA est aussi important que de choisir le bon outil d'analyse.
La surface d'attaque que personne n'avait prévue au budget.
Auparavant, un logiciel ne comportait que quelques points d'entrée pour un attaquant : le code, les dépendances, etc. pipelineL'IA en a ajouté deux autres, et toutes deux alimentent directement la chaîne d'approvisionnement de l'IA.
Le modèle et l'agent. Empoisonnement d'outils, injection de prompts, autonomie des agents dépassant les limites prévues. Une instruction cachée dans la description d'un serveur MCP peut discrètement rediriger les actions d'un copilote, sans que le développeur ne s'en aperçoive.
L'environnement propre au développeur. IDE, copilotes IA, serveurs MCP, interfaces de ligne de commande d'agents : invisibles pour les scanners AppSec traditionnels, qui ignorent ce qu'est un modèle, et invisibles pour les solutions EDR, qui surveillent le système d'exploitation sans savoir ce qu'est une dépendance ou un appel MCP.
Rien de tout cela n'est théorique. Au cours des dix-huit derniers mois :
- Une faille de sécurité cachée dans les fichiers de règles Unicode permettait aux attaquants d'injecter des instructions invisibles dans les fichiers de configuration lus par Copilot et Cursor, compromettant ainsi silencieusement le code généré par l'assistant. GitHub a ajouté un avertissement à ce sujet en 2025.
- Une faille d'injection de commandes dans un pont MCP populaire (CVSS 9.6) a touché plus de 400 000 téléchargements avant d'être corrigée, le premier cas documenté d'exécution complète de code à distance déclenchée simplement par la connexion à un serveur MCP non fiable.
- Un ver npm auto-propagateur a transformé les développeurs eux-mêmes en mécanisme de diffusion, et le schéma s'est répété à grande échelle dans les mois suivants à travers d'autres écosystèmes, un échec de sécurité de la chaîne d'approvisionnement de l'IA typique.
- Les chercheurs ont découvert qu'une part importante des packages recommandés par les LLM n'existent tout simplement pas : il s'agit de noms « slopsquattés » qu'un attaquant enregistre avant même qu'un véritable développeur ne demande au modèle de les importer.
Les recherches menées par Google sur la sécurisation de la chaîne d'approvisionnement des logiciels d'IA aboutissent à une conclusion similaire, sous un angle différent : les modèles qui circulaient en 2023 et 2024 semblaient légitimes, mais contenaient du code susceptible d'exfiltrer des données ou d'installer une porte dérobée une fois téléchargés. La solution ne résidait pas tant dans une nouvelle catégorie d'outils que dans l'application de règles de sécurité strictes à la chaîne d'approvisionnement, telles que la traçabilité et la signature, à des éléments qui n'avaient jamais fait l'objet d'un suivi auparavant. Voilà, en résumé, le problème de sécurité de la chaîne d'approvisionnement de l'IA : les éléments sont nouveaux, mais les règles de sécurité nécessaires ne le sont pas.
Pourquoi vos outils actuels s'arrêtent-ils en cours de route ?
SAST lit le code. SCA On lit un manifeste des dépendances. Ni l'un ni l'autre ne sait ce qu'est un modèle, ce qu'expose un serveur MCP, ni ce qu'un fichier de compétences indique à un agent. C'est précisément dans cet écart que les attaques de l'ère de l'IA trouvent un écho, dans l'espace entre le « code que nous analysons » et « l'IA que nous avons discrètement adoptée ».
Le résultat est une catégorie d'IA fantôme non CISO peut actuellement répondre aux questions suivantes : quels modèles sommes-nous en cours d'exécution ? Quels agents peuvent accéder à quelles ressources ? À quel serveur MCP quelqu'un s'est-il connecté mardi dernier sans en informer personne ? Répondre correctement à cette question est le rôle de la sécurité de la chaîne d'approvisionnement de l'IA, et c'est pourquoi les outils AppSec génériques restent insuffisants dans ce domaine.
Que signifie réellement la sécurité de l'IA ?
Xygéni est la société de sécurité IA qui traite cela comme trois mouvements connectés à travers le SDLC: découvrir, détecter et faire respecter.
Découvrez : sachez quelle IA vous possédez réellement.
La découverte continue et automatique de vos référentiels met en évidence toutes les ressources d'IA : modèles, frameworks, jeux de données, points de terminaison d'inférence, agents, serveurs MCP, compétences, invites, guardrailset les outils de programmation d'IA que vos développeurs utilisent réellement. Pas d'enquêtes. Pas d'auto-déclaration. Si une trace est laissée dans un dépôt, elle apparaît dans l'inventaire, première et principale exigence d'une véritable sécurité de la chaîne d'approvisionnement en IA.
Le graphique d'IA cartographie ensuite les connexions entre ces ressources : quel modèle alimente un ensemble de données, quel agent active quel outil, quel serveur MCP est associé à quel assistant. Une ressource isolée est peu informative. Le graphique révèle où se concentrent les risques.
À partir de cette même découverte, Xygeni génère un Nomenclature AI-BOMUn inventaire complet et exploitable par machine de toutes les technologies d'IA présentes dans vos logiciels, prêt pour un audit. Lorsqu'un organisme de réglementation, un auditeur ou un client vous demande quelles IA vous utilisez, la réponse se résume à un simple téléchargement, au lieu de trois semaines de recherche interminable.
Détection : les risques que les scanners conventionnels ne peuvent pas voir.
Un scanner IA dédié recherche les modes de défaillance spécifiques aux systèmes d'IA : injection de prompts, injection d'outils et invocation d'outils non fiables, fuite de données lors de la récupération, contournement des prompts système et intervention excessive du système. Chaque détection est associée à un Top 10 de l'OWASP pour les candidatures au LLM et indique le fichier et la ligne exacts qui créent l'exposition, et non une vague alerte du type « revoyez votre utilisation de l'IA ».
Cette même couche de détection considère les fichiers de compétences, les fichiers de règles et les configurations MCP comme des éléments de sécurité essentiels, et non comme une simple documentation. Elle signale les compétences malveillantes ou corrompues, inspecte les configurations du serveur MCP pour détecter toute contamination des outils et met en évidence les invites qui pilotent réellement vos charges de travail d'IA.
Prioriser : l'entonnoir qui élimine le bruit, pas les raccourcis
Chaque découverte est filtrée progressivement : d’abord pour identifier les vulnérabilités accessibles dans le code applicatif, puis celles réellement exploitables, et enfin celles présentes dans le code en cours de développement par votre équipe. Seule la liste restreinte des vulnérabilités menaçant réellement la production est transmise au développeur, accompagnée de la documentation relative au framework, à la période d’exposition et aux mesures d’atténuation.
Appliquer : l'arrêter avant qu'il ne s'exécute
Shield Il applique les politiques de sécurité directement au niveau du développeur : il bloque les installations non autorisées et malveillantes, les modèles non approuvés et les serveurs MCP non autorisés avant toute exécution. En dessous se trouve Xygeni. Alerte précoce de logiciels malveillants (MEW)Cette couche, qui intercepte les paquets malveillants avant même l'existence d'une signature, reste fiable aux outils basés sur la réputation car personne n'a encore signalé le paquet. Il s'agit de la partie « application » de la sécurité de la chaîne d'approvisionnement par l'IA : la découverte et la détection permettent d'identifier les problèmes. Shield C'est ce qui l'arrête réellement.
Votre exposition à l'IA ne se limite pas à votre code d'IA.
Une vision complète de la sécurité de la chaîne d'approvisionnement en IA nécessite plus qu'un simple inventaire de modèles, et elle se limite rarement aux éléments les plus spectaculaires :
- identifiants du fournisseur d'IA laissés dans les fichiers d'invite, les configurations d'agent ou pipeline Les journaux d'activité sont des secrets comme les autres, et le système de détection de secrets de Xygeni les intercepte avant qu'ils n'atteignent un registre public.
- Dépendances vulnérables en matière d'IA et d'apprentissage automatique Ces vulnérabilités (CVE) sont courantes et sont mises en évidence par la même analyse de composition logicielle qui couvre déjà le reste de votre infrastructure. Des études tierces sur l'adoption de l'IA ont montré que la plupart des infrastructures d'IA modernes reposent sur des packages externes et des composants cachés ; c'est précisément ce que l'analyse de composition logicielle vise à détecter.
- Colis malveillants publié plus rapidement que tout avis pipeline Ils peuvent être catalogués s'ils sont interceptés avant signature, la même capacité MEW protégeant le reste de votre chaîne d'approvisionnement.
La couche agentielle : DevAI et CoreAI
La découverte et la détection couvrent ce qui se trouve déjà dans vos référentiels. DevAI Ce système intervient là où le risque se crée : au sein même de l’IDE, sous la forme d’une couche proactive et continue qui analyse le code généré par les humains et l’IA en temps réel, sans intervention de l’utilisateur. Il explique l’intégralité du chemin d’exploitation à l’origine d’une vulnérabilité détectée et propose des correctifs validés par MCP que les développeurs peuvent appliquer en toute confiance, sans perturber la compilation.
CoreAI Elle se situe au-dessus des scanners individuels en tant que couche d'intelligence : elle met en corrélation le code, les dépendances, pipelineet intègre les données de posture dans un modèle de risque unique, répond aux questions en langage naturel et produit les rapports prêts à être présentés à la direction dont un responsable de la sécurité a besoin pour démontrer que la gouvernance est réellement en place et non pas seulement affirmée.
Développez ce que vous avez déjà en matière de sécurité de l'IA. Ne supprimez rien.
L'objection la plus courante à la création d'une nouvelle catégorie de sécurité est : « Nous avons déjà suffisamment d'outils. » En tant qu'entreprise spécialisée dans la sécurité de l'IA, Xygeni ne vous demande de remplacer aucun outil : le même processus de triage, d'explication et de priorisation appliqué à ses propres résultats s'applique également aux résultats de vos systèmes existants. SAST, SCAet les scanners tiers. Votre infrastructure actuelle devient un atout, et non une fatalité, et la sécurité de votre chaîne d'approvisionnement en IA s'améliore sans nécessiter de refonte complète.
Pourquoi cela est important maintenant, et pas plus tard
Les organismes de réglementation convergent vers une même exigence, bien que leurs approches diffèrent : la loi européenne sur l’IA, la norme NIS2 et la norme espagnole ENS insistent toutes sur l’inventaire et la traçabilité des systèmes d’IA, preuves que la nomenclature des composants d’IA (AI-BOM) est précisément conçue pour fournir. La tendance est claire, même si les modalités exactes de conformité restent encore à définir : on ne peut attester de l’existence d’une IA dont on n’a jamais dressé l’inventaire, et l’on ne peut garantir la sécurité de la chaîne d’approvisionnement d’IA si cette dernière est invisible.
Choisir une entreprise de sécurité IA
Les entreprises spécialisées en sécurité de l'IA n'ont pas toutes la même approche. Certaines se contentent d'analyser votre propre code généré par l'IA, tandis que d'autres s'arrêtent au point de terminaison. La question de la sécurité de la chaîne d'approvisionnement de l'IA est bien plus vaste : elle englobe le modèle, l'agent, le serveur MCP, le fichier de compétences et toutes les dépendances sous-jacentes. C'est cette vision complète du cycle de vie, de la détection à la mise en œuvre des mesures de sécurité, regroupée dans une seule interface avec vos autres résultats d'analyse de sécurité applicative, qu'il faut privilégier lors de l'évaluation d'une entreprise spécialisée en sécurité de l'IA plutôt que d'un simple outil ponctuel.
Les fichiers que personne ne vérifie sont devenus la porte d'entrée. La sécurité de l'IA consiste à les examiner, et la sécurité de la chaîne d'approvisionnement de l'IA garantit le respect de cette discipline de bout en bout, sur la même plateforme où vous examinez déjà tout le reste.
Découvrez ce que votre IA est réellement autorisée à faire. Commencer gratuitement or planifier une démo.
QFP
Le code de Xygeni quitte-t-il jamais mon infrastructure ?
Non. Les analyses s'exécutent dans votre environnement et le code source n'est jamais téléchargé sur les serveurs de Xygeni. L'inventaire IA et la nomenclature IA sont générés à partir des données détectées localement par l'analyseur, et non à partir d'une copie externe.
Quelle est la différence entre la sécurité de l'IA, l'IA de développement et l'IA de base ?
La sécurité IA découvre et détecte les menaces : elle crée l’inventaire IA (la nomenclature IA) et identifie les risques tels que l’injection de prompts ou les fichiers de compétences corrompus. DevAI s’intègre à l’IDE pendant que les développeurs écrivent du code, en proposant des correctifs au fur et à mesure. CoreAI, quant à elle, centralise les résultats sur l’ensemble de la plateforme et répond aux questions relatives à votre niveau de sécurité en langage naturel.
À quels cadres de sécurité de l'IA Xygeni s'aligne-t-il ?
Les résultats correspondent aux 10 principaux critères OWASP pour les applications LLM, les 10 principaux critères OWASP pour le MCP et les 10 principaux critères OWASP pour les compétences d'agent, ainsi qu'à la norme NIST SP 800-218A et CISDirectives A/G7 relatives aux nomenclatures IA. Cette correspondance permet d'utiliser la nomenclature IA comme preuve de conformité et non comme simple inventaire.
Cela va-t-il signaler chaque bibliothèque ou modèle d'IA comme présentant un risque ?
Non. Le processus de priorisation restreint les résultats à ce qui est accessible dans le code de l'application, réellement exploitable et en développement actif, de sorte que la liste vue par un développeur est courte et ne constitue pas un déversoir de toutes les ressources d'IA détectées.
