Explication de la sécurité MCP #
L'AI-SPM (Gestion de la posture de sécurité de l'IA) consiste à découvrir, évaluer et appliquer en continu la sécurité de tous les actifs d'IA déployés au sein de votre organisation (modèles, agents, serveurs MCP, jeux de données, outils de programmation et frameworks d'IA), ainsi que des relations, des risques et des obligations réglementaires qui les relient. Si vous vous demandez ce qu'est l'AI-SPM et pourquoi c'est important aujourd'hui, la réponse est simple : on ne peut sécuriser ce qu'on ne voit pas, et la plupart des organisations ne peuvent pas voir l'IA qui s'exécute dans leurs systèmes. pipelines.
As L'IA s'intègre à toutes les étapes du développement logicielLa gestion traditionnelle de la posture de sécurité applicative n'a pas été conçue pour comprendre ce qu'est un modèle, ce qu'un agent peut faire ou ce qu'un serveur MCP peut atteindre. La gestion de la posture de sécurité par IA (AI-SPM) comble cette lacune. Ce guide explique ce qu'est la gestion de la posture de sécurité par IA et en quoi elle diffère de la gestion traditionnelle de la posture de sécurité applicative. ASPM, pourquoi cela devient une exigence de conformité et à quoi ressemblera une pratique mature en matière d'IA et de gestion de portefeuille de services (IA-SPM) en 2026.
Qu’est-ce que l’IA-SPM ? Définition détaillée #
La gestion de la posture de sécurité de l'IA (AI-SPM) est une discipline de sécurité qui applique la découverte continue, l'évaluation des risques et l'application des politiques aux actifs spécifiques à l'IA tout au long du cycle de vie du développement logiciel. Là où la gestion traditionnelle Application Security Posture Management (ASPM) regroupe et hiérarchise les résultats de SAST, SCA, DAST, et outils secrets, AI-SPM étend cette portée pour couvrir les actifs que ces outils n'ont jamais été conçus pour comprendre : grands modèles de langage, agents autonomes, serveurs de protocole de contexte de modèle, configurations d'invite, ensembles de données et assistants de codage IA.
La fonction principale de l'IA-SPM est la même que celle de toute pratique de gestion de la posture : identifier ses actifs, comprendre les risques associés et appliquer les politiques de sécurité avant que ces risques ne se transforment en incident. La différence réside dans la nature des actifs. Un serveur MCP mal configuré, un agent disposant de permissions excessives ou un modèle exploitant un jeu de données corrompu ne constituent pas un incident. vulnérabilité au sens traditionnel du CVE; Il s'agit de défaillances de posture qui nécessitent une logique de détection spécifique à l'IA, une évaluation des risques spécifique à l'IA, et Conseils de remédiation spécifiques à l'IA.
L'AI-SPM est parfois décrite comme la couche d'IA au-dessus de ASPMet parfois comme pratique autonome. Dans les deux cas, l'exigence fondamentale reste la même : les organisations ont besoin d'une méthode systématique pour recenser tous leurs actifs d'IA, évaluer les risques associés et agir en conséquence.
IA-SPM vs ASPMQuelle est la différence ? #
ASPM (Application Security Posture Management) a été conçu pour corréler les résultats des outils AppSec traditionnels (SAST, SCA, DAST, scanners secrets, IaC analyseursElle permet d'obtenir une vue unifiée des risques pour l'ensemble du portefeuille d'applications. Elle répond à la question : quelles sont les vulnérabilités présentes dans notre code et nos dépendances, et lesquelles sont les plus critiques ?
AI-SPM pose une question différente : quelle IA est exécutée dans notre environnement, que peut-elle faire et est-elle configurée en toute sécurité ?
Ces deux pratiques sont complémentaires plutôt que concurrentes :
ASPM couvre le code, les dépendances, pipelineet l'infrastructure. AI-SPM couvre les modèles, les agents, les serveurs MCP, les configurations d'invite et les ensembles de données. Où ASPM L'évaluation des risques se base sur la gravité et l'accessibilité des CVE, tandis que l'évaluation des risques par AI-SPM se base sur les vecteurs d'attaque spécifiques à l'IA, l'exposition aux injections rapides, l'agence excessive, les configurations MCP non sécurisées, l'IA fantôme et les fuites de données via les systèmes RAG.
Dans un programme de sécurité mature, l'IA-SPM alimente ASPMLe risque lié aux actifs d'IA est un signal supplémentaire dans la vue unifiée de la posture, corrélé au risque au niveau du code et pipeline security pour dresser un tableau complet de la surface d'attaque de l'organisation.
htmlPourquoi l'IA et la gestion de portefeuille de services (SPM) sont importantes aujourd'hui #
Trois facteurs ont fait passer l'AI-SPM d'une simple considération future à une nécessité opérationnelle immédiate.
- Les ressources en IA prolifèrent plus vite que la gouvernance ne peut suivre. Les développeurs configurent les serveurs MCP localement, récupèrent des modèles depuis des hubs publics, activent des assistants de programmation IA par IDE et déploient des agents autonomes dans CI/CD pipelineSouvent sans approbation formelle, l'IA est utilisée à des fins non conventionnelles. Selon une enquête menée en 2026 auprès de responsables de la sécurité, seuls 19 % d'entre eux ont déclaré avoir une visibilité complète sur l'utilisation de l'IA au sein de leur organisation. Les autres travaillent à l'aveugle.
- Les attaquants ciblent directement la couche d'intelligence artificielle. La campagne PromptMink a conçu des packages npm malveillants spécifiquement destinés à tromper les agents de programmation d'IA. Les clusters ollama-helpers et openai-agents-helpers ciblaient des packages utilisés dans les flux de travail des agents. Fuite de compétences Le modèle dissimulait un déchiffreur d'identifiants dans une compétence MCP plutôt que dans un hook d'installation, avantcisely parce que installer hooks Ce sont les zones que les scanners examinent. Les outils AppSec traditionnels ne prennent pas en compte ces surfaces d'attaque. AI-SPM, si.
- La réglementation arrive. La loi européenne sur l'IA, le cadre de gestion des risques liés à l'IA du NIST et la norme ISO/IEC 42001 exigent tous des organisations qu'elles documentent, classifient et gouvernent les systèmes d'IA qu'elles exploitent. Or, il est impossible de satisfaire à ces obligations sans connaître au préalable le type d'IA utilisé. AI-SPM est une condition préalable à la conformité, et non un complément.
Que couvre l'AI-SPM ? #
Une pratique complète en matière d'IA et de gestion de portefeuille de services (IA-SPM) couvre quatre capacités :
- Mise en vigueur. En fonction des résultats de l'analyse de la posture, il s'agit de bloquer les serveurs MCP non approuvés au niveau du point de terminaison du développeur, d'intercepter les dépendances malveillantes avant leur installation, de signaler les configurations d'invite qui dépassent les limites du moindre privilège et d'isoler les points de terminaison compromis avant qu'un incident ne se propage.
- Découverte. Recherche continue de toutes les ressources d'IA au sein de l'organisation (modèles, agents, serveurs MCP, outils de programmation IA, jeux de données et frameworks IA), y compris celles qui n'ont jamais été approuvées par le service informatique. L'IA fantôme est la plus difficile à détecter car elle réside sur les ordinateurs portables des développeurs, dans les configurations IDE locales et au sein même des systèmes. CI/CD pipelineplutôt que dans les consoles cloud.
- Notation des risques. Évaluation de chaque actif face aux vecteurs d'attaque spécifiques à l'IA : exposition aux injections rapides, risque d'empoisonnement des outils, contrôle excessif, configurations MCP non sécurisées, fuites de données via les systèmes RAG et IA fantôme sans gouvernance. La gravité des CVE à elle seule ne permet pas de saisir ces risques ; la gestion des risques liés à l'IA (AI-SPM) exige un modèle de risque conçu pour le parcours d'attaque de l'IA.
- Cartographie réglementaire. Ce processus consiste à associer chaque ressource d'IA aux obligations de conformité qui lui incombent en vertu de la loi européenne sur l'IA, du cadre de gestion des risques liés à l'IA du NIST, de la norme ISO/IEC 42001 et du Top 10 de l'OWASP pour les applications LLM et les applications agentiques. La nomenclature d'IA (AI-BOM) est le résultat prêt pour l'audit de cette cartographie : un inventaire lisible par machine de chaque ressource d'IA, indiquant son niveau de risque et sa classification réglementaire.
AI-SPM et la nomenclature AI #
La nomenclature AI-BOM (AI Bill of Materials) est le document exportable et prêt pour l'audit produit par AI-SPM. SBOM catalogue les dépendances logicielles open source et tierces, une nomenclature AI-BOM Ce catalogue recense les ressources spécifiques à l'IA : modèles, ensembles de données, agents, serveurs MCP et outils de codage IA, avec leur provenance, leur niveau de risque et leur cartographie réglementaire.
Les responsables de la sécurité reçoivent de plus en plus de demandes de la part des auditeurs et enterprise Les équipes d'approvisionnement auront besoin d'une nomenclature IA pour ce type d'élément. Les organisations capables de générer une nomenclature IA à la demande (de manière continue, grâce à leurs pratiques de gestion de portefeuille de produits IA, et non plus manuellement et ponctuellement) bénéficieront d'un avantage considérable en matière de conformité et de confiance, à mesure que les obligations d'audit de la loi européenne sur l'IA se préciseront.
AI-SPM et les cadres OWASP #
La détection et l'évaluation des risques liés aux SPM-IA devraient être alignées sur les cadres communautaires qui définissent les risques spécifiques à l'IA :
- Le Top 10 de l'OWASP pour les candidatures au LLM Ce rapport couvre les dix risques les plus critiques pour les applications basées sur de grands modèles de langage, notamment l'injection de vulnérabilités, la gestion non sécurisée des résultats, la divulgation d'informations sensibles, les pouvoirs d'agence excessifs, etc. AI-SPM évalue l'exposition de chaque ressource d'IA par rapport à ces catégories.
- Le Top 10 OWASP des applications agentiques étend ce cadre aux flux de travail d'agents autonomes, couvrant les risques tels que le détournement d'agents, l'invocation incontrôlée d'outils et l'empoisonnement de la mémoire qui sont spécifiques aux architectures d'agents.
- Le Top 10 OWASP MCP Il traite des risques de sécurité introduits par les intégrations du protocole MCP (Model Context Protocol), l'empoisonnement d'outils, l'injection de prompts via MCP, l'exécution d'outils non autorisée et les serveurs MCP fantômes.
L'alignement sur ces cadres transforme les résultats de l'IA SPM en classifications de risques exploitables et validées en externe que les auditeurs et enterprise Les acheteurs peuvent évaluer.
Critères de choix des outils AI-SPM #
Si vous évaluez les capacités d'une solution AI-SPM, voici les exigences qui distinguent une véritable gestion de la posture par l'IA d'une simple liste d'actifs statique :
S'étend dans le SDLC: découvrir l'IA dans le code, construire pipelineet sur les points de terminaison des développeurs, et pas seulement dans les consoles cloud, où la plupart des IA fantômes n'apparaissent jamais.
Comprend les types d'actifs, les modèles, les agents, les serveurs MCP, les ensembles de données et les configurations d'invite spécifiques à l'IA, et pas seulement les packages et les bibliothèques.
Évalue les risques liés aux vecteurs d'attaque spécifiques à l'IA (injection rapide, MCP non sécurisé, contrôle excessif de l'IA, IA fantôme) et pas seulement à la gravité des CVE.
Génère une nomenclature d'IA prête pour l'audit avec une correspondance réglementaire avec la loi européenne sur l'IA, le NIST AI RMF et la norme ISO/IEC 42001.
Relie la posture à l'application des règles : les constats se traduisent ainsi par des dépendances bloquées, des serveurs MCP rejetés et des points de terminaison confinés, et non pas seulement par une simple détection. dashboard des questions ouvertes.
Fonctionnement continu : capture des nouveaux actifs d’IA au fur et à mesure de leur apparition, et non pas un audit ponctuel qui devient obsolète en quelques jours.
Sécuriser la posture de l'IA avec Xygeni #
L'IA-SPM exige plus qu'une dashboardCela nécessite une découverte continue qui s'étend jusqu'au point de terminaison du développeur, une évaluation des risques conçue pour le chemin d'attaque de l'IA et la capacité d'appliquer une politique avant qu'un serveur MCP mal configuré ou une dépendance malveillante ne provoque un incident.
La plateforme de sécurité IA de Xygeni propose l'IA-SPM comme une pratique continue : découverte de chaque modèle, agent, serveur MCP et outil de codage IA au sein de votre environnement. SDLC via AI-SPM, l'évaluation des risques par rapport au Top 10 de l'OWASP pour les applications LLM, les applications agentiques et MCP, produit une nomenclature IA exportable pour les auditeurs et enterprise acheteurs, et en appliquant la politique au niveau du terminal développeur via Shield, en bloquant les serveurs MCP non approuvés et les dépendances malveillantes avant qu'ils n'atteignent les acheteurs pipeline.
Si vos équipes utilisent des assistants de programmation IA, le problème de la posture de l'IA est déjà présent. La question est de savoir si vous disposez de la visibilité nécessaire pour le gérer.
QFP #
MCAI-SPM est utilisé pour découvrir tous les actifs d'IA exécutés au sein d'une organisation, évaluer le risque de chaque actif face aux vecteurs d'attaque spécifiques à l'IA, produire une nomenclature d'IA (AI-BOM) à des fins de conformité et d'audit, et appliquer la politique au niveau du point de terminaison du développeur, en bloquant les serveurs MCP non approuvés et les dépendances malveillantes avant qu'ils ne provoquent un incident.
La réglementation européenne sur l'IA ne mentionne pas explicitement la gestion des pratiques de sécurité en matière d'IA (AI-SPM), mais ses obligations de documentation, de classification et d'enregistrement des systèmes d'IA à haut risque sont impossibles à satisfaire sans connaître le type d'IA utilisé. L'AI-SPM est la pratique qui permet de répondre à ces obligations. Il en va de même pour le cadre de gestion des risques liés à l'IA du NIST et la norme ISO/IEC 42001.
Considérez l'inventaire d'IA comme les fondations et l'AI-SPM comme l'ensemble des éléments. L'inventaire recense et catalogue chaque ressource d'IA : sa nature, son environnement d'exécution et ses cibles potentielles. L'AI-SPM s'appuie sur ces fondations et les développe : évaluation des risques liés aux vecteurs d'attaque spécifiques à l'IA, correspondance de chaque ressource avec les obligations réglementaires et application des politiques en fonction des conclusions. L'inventaire est indispensable à l'AI-SPM. Mais un inventaire seul, sans évaluation ni application des politiques, n'est qu'une simple liste.
L'IA fantôme, c'est l'IA que votre équipe de sécurité n'a pas approuvée et qu'elle ne peut pas voir : le modèle qu'un développeur a récupéré sur une plateforme publique, le serveur MCP qui tourne sur un ordinateur portable, l'agent qui s'active discrètement. pull requests dans un pipeline Aucun audit n'a été réalisé. Ce type d'IA apparaît rarement dans une console cloud, ce qui explique pourquoi la détection basée uniquement sur le cloud en manque la majeure partie. L'IA-SPM est cruciale pour lutter contre l'IA fantôme car elle permet d'accéder aux endroits où elle réside réellement : dépôts de code, environnements de compilation et terminaux de développement, et de détecter les actifs avant qu'ils ne deviennent un risque non maîtrisé.
