Ingénierie de la sécurité IA
Vos modèles sont du code exécutable. La plupart des organisations les traitent comme de simples fichiers de données. C'est dans cet écart que surviennent les violations.
4,63 M$
Coût moyen d'une violation impliquant le shadow AI
IBM Cost of a Data Breach 2025
83 %
Des organisations n'ont pas de contrôles de sécurité IA automatisés
Kiteworks 2025
352 K
Problèmes dangereux détectés parmi 51 700 modèles sur des registres publics
Protect AI 2025
Les modèles d'IA ne sont pas des artefacts statiques. Ce sont du code qui s'exécute pendant le chargement, l'entraînement, l'inférence et l'exécution d'agents. Quatre catégories d'attaques dominent le modèle de menace.
torch.load() exécute du Python arbitraire pendant la désérialisation. Ce n'est pas un bug. C'est le comportement conçu de la sérialisation pickle, et plus de 80 % des modèles de ML l'utilisent.
Un modèle nommé « baller423 » sur Hugging Face s'est révélé établir un reverse shell vers Kreonet. Le modèle paraissait normal. Il passait les analyses de base. Il exécutait du code arbitraire au moment même où quelqu'un le chargeait.
PickleScan, la défense la plus largement utilisée, présente au moins 3 contournements zero-day connus (CVE-2025-10155). L'analyse fondée sur des listes noires est fondamentalement défaillante parce que l'attaquant contrôle le format de sérialisation.
Llama 3.1 8B chute de 0,95 à 0,15 en résilience à l'injection de prompt après un seul cycle de fine-tuning. C'est une dégradation de 84 % de l'alignement de sécurité résultant d'un entraînement normal et non adverse.
Presque personne ne réévalue la sécurité après le fine-tuning. Le modèle passe l'évaluation de sécurité initiale, est fine-tuné sur des données métier, et part en production avec ses garde-fous effectivement supprimés. Ce n'est pas une attaque exotique. C'est le flux de travail par défaut dans la plupart des organisations.
98 % des organisations ont une utilisation non autorisée d'IA. Ce chiffre n'est pas une coquille. Le coût supplémentaire de 670 K$ par violation pour les incidents de shadow AI reflète une réalité simple : on ne peut pas sécuriser ce que l'on ne peut pas voir.
62 % des équipes de sécurité ne parviennent pas à identifier où les LLM sont déployés dans leur environnement. Les développeurs téléchargent des modèles depuis Hugging Face, appellent les API d'OpenAI avec des clés personnelles, et déploient des modèles fine-tunés sur des comptes cloud personnels. Les outils de sécurité actuels font remonter environ 38 % de cette activité.
La vulnérabilité RCE de GitHub Copilot (CVE-2025-53773, CVSS 7.8) a transformé une injection de prompt dans la documentation d'un dépôt en compromission complète du système via le mode YOLO. L'agent a lu une instruction malveillante, l'a exécutée comme du code, et la machine de l'utilisateur a été compromise.
Le cleaner.md fichier d'Amazon Q a distribué des commandes destructrices à plus de 950 K utilisateurs via la fenêtre de contexte de l'agent. La place de marché d'OpenClaw a accumulé 138 CVE en 63 jours, avec 12 % des compétences soumises jugées malveillantes.
Les agents transforment les injections de prompt en compromissions au niveau système parce qu'ils disposent d'un accès aux outils, d'identifiants et de privilèges d'exécution dont les LLM traditionnels sont dépourvus.
L'écosystème des fournisseurs mûrit rapidement. Voici une vision honnête de ce que couvre chaque acteur et des lacunes qui subsistent.
| Fournisseur | Ce qu'ils font | Ce qu'ils ne font pas | Idéal pour |
|---|---|---|---|
| Palo Alto / Protect AI | Analyse de modèles, génération d'AI-BOM, intégré à la plateforme Prisma AIRS | Conception d'architecture, ingénierie de pipelines personnalisés, conduite du changement organisationnel | Entreprises déjà sur la plateforme PANW |
| HiddenLayer | Détection et réponse IA à l'exécution, surveillance de sécurité agentique | Architecture de chaîne d'approvisionnement, mise en œuvre de ML-BOM, cartographie de conformité | Équipes SOC ajoutant de la visibilité IA |
| JFrog | MLSecOps, sécurité du registre de modèles, intégration Hugging Face | Red-teaming adverse, validation de l'alignement de sécurité, conception de la gouvernance | Équipes DevOps gérant des artefacts de modèles |
| Wiz | AI-BOM dans un contexte de sécurité cloud, analyse de modèles | Sécurité des modèles on-prem, sécurité du fine-tuning, architecture agentique | Organisations cloud-first |
| NVIDIA NeMo Guardrails | Guardrails à l'exécution open-source pour LLM | Analyse de modèles, sécurité de la chaîne d'approvisionnement, suivi de la provenance | Équipes développant des applications LLM personnalisées |
| Big 4 / Grands intégrateurs | Cadres de gouvernance, documentation de conformité, présentations pour conseils d'administration | Mise en œuvre. Construction de pipelines d'analyse, configuration de ML-BOM, déploiement de la signature de modèles. Les missions débutent à 500 K$ pour la stratégie et atteignent 3 à 10 M$. | Organisations ayant besoin d'une documentation prête pour l'audit |
| Open Source (ModelScan, PickleScan, SafeTensors) | Analyse de base gratuite et formats de sérialisation plus sûrs | Orchestration de niveau entreprise, sandboxing comportemental, provenance, application des politiques | Équipes dotées d'une solide ingénierie de sécurité interne |
Une lacune que personne ne comble bien. Le changement de culture organisationnelle est la partie la plus difficile. Aucun outil ni cabinet de conseil n'élimine la tendance humaine à contourner la gouvernance pour gagner du temps. Nous construisons les contrôles techniques, mais le CISO a tout de même besoin de l'adhésion de la direction. Quand un data scientist peut télécharger un modèle depuis Hugging Face en 30 secondes, tout verrou de sécurité prenant 30 minutes sera contourné. Les contrôles doivent être assez rapides pour que la conformité soit plus simple que le contournement.
Six capacités, chacune conçue pour s'intégrer à votre pile de sécurité existante et à vos pipelines CI/CD.
Nous construisons une vérification automatisée qui s'intercale entre les dépôts publics de modèles et votre registre interne. Chaque modèle passe par un sandboxing comportemental (chargé dans des conteneurs isolés, appels système surveillés), une analyse approfondie multi-format (pickle, PyTorch, GGUF, Keras, SafeTensors) et une signature cryptographique avec votre PKI d'entreprise.
Nous privilégions l'analyse comportementale à l'analyse statique parce que les contournements zero-day de PickleScan prouvent que les approches par liste noire sont fondamentalement défaillantes. L'analyse statique demande « ce fichier contient-il des motifs malveillants connus ? » Le sandboxing comportemental demande « que fait réellement ce code lorsqu'il s'exécute ? » La seconde question détecte les attaques inédites.
Génération de ML-BOM CycloneDX intégrée au CI/CD. Chaque modèle reçoit une nomenclature documentant la provenance des données d'entraînement, les versions de framework, les arbres de dépendances et l'historique de fine-tuning.
Nous utilisons CycloneDX plutôt que SPDX parce que l'outillage ML-BOM est plus mature, tout en assurant un export SPDX 3.0 pour les organisations qui ont besoin des deux. Le ML-BOM n'est pas une case de conformité à cocher. C'est la structure de données qui rend possible tout autre contrôle de sécurité : on ne peut pas signer ce que l'on n'a pas inventorié, et on ne peut pas auditer ce que l'on ne peut pas tracer.
Détection au niveau réseau des téléchargements de modèles et des appels d'API IA non autorisés. Intégration avec votre SIEM/SOAR existant. Nous cartographions chaque point de contact IA, y compris les déploiements clandestins, puis construisons une application de politiques qui bloque le risque sans bloquer l'innovation.
L'objectif : votre équipe de sécurité voit 100 % de l'utilisation de l'IA, et non les 38 % que les outils actuels font remonter. La détection couvre les téléchargements Hugging Face, les appels d'API OpenAI/Anthropic/Google, les transferts de poids de modèles via HTTP/S et l'exécution locale de modèles via la surveillance des processus sur les terminaux gérés.
Réévaluation automatisée de la sécurité après chaque cycle de fine-tuning. Suite de benchmarks OWASP LLM Top 10, sondage adverse des déclencheurs de portes dérobées et tests de régression de l'alignement de sécurité.
Nous construisons cela parce que presque personne ne réévalue la sécurité après le fine-tuning. Les données de dégradation de sécurité de la section ci-dessus le démontrent. Le pipeline de validation s'exécute comme un verrou CI/CD. Un modèle qui échoue à la régression de sécurité ne peut pas être promu en production, quelle que soit sa performance sur la tâche.
Séparation des privilèges pour les agents IA. Couches de politiques déterministes qui empêchent l'escalade du prompt vers l'exécution de code à distance (le vecteur d'attaque exact dans CVE-2025-53773). Application des politiques d'utilisation des outils, verrous avec intervention humaine pour les opérations à haut risque, et surveillance du comportement à l'exécution.
L'architecture détecte les actions anormales des agents avant qu'elles ne se propagent. Un agent qui se met soudain à écrire dans des chemins de système de fichiers hors de son sandbox, à appeler des API qu'il n'a jamais appelées auparavant, ou à tenter une escalade de privilèges est arrêté et signalé pour examen.
Pour les CISO qui construisent la fonction de zéro. Cartographie des contrôles NIST AI 100-2, architecture de conformité à l'EU AI Act, quantification du risque au niveau du conseil d'administration et plans de réponse aux incidents pour les attaques propres à l'IA.
Nous aidons à traduire le risque technique en justification budgétaire que les conseils d'administration approuvent. « Nous avons détecté 352 K problèmes dangereux sur des registres publics de modèles » est un point de donnée. « Nos ingénieurs ont téléchargé 47 modèles non vérifiés le trimestre dernier, 3 contenaient du code exécutable dans leur couche de sérialisation, et nos contrôles actuels n'en ont détecté aucun » est une justification budgétaire.
Trois phases, chacune avec des livrables définis et des mises en garde honnêtes sur ce à quoi s'attendre.
Semaines 1 à 3
Livrable : Rapport de posture de sécurité IA avec registre des risques priorisé
Mise en garde : Cette phase fait souvent remonter 3 à 5 fois plus d'utilisation d'IA que le CISO ne l'attendait. C'est normal. La découverte du shadow AI est la partie la plus précieuse et la plus inconfortable de la mission.
Semaines 4 à 10
Livrable : Contrôles de sécurité prêts pour la production, intégrés aux flux de travail existants
Mise en garde : Le calendrier dépend de la maturité du CI/CD. Les équipes dotées de pipelines DevOps matures déploient plus vite. Les organisations qui déplacent encore les modèles par clés USB ou dossiers partagés (plus courant qu'on ne le croit) ont besoin d'un travail d'infrastructure supplémentaire.
Semaines 11 à 14
Livrable : Opérations de sécurité IA autonomes avec runbooks documentés
Mise en garde : La première red-team adverse trouve toujours quelque chose. C'est précisément le but. Une red-team qui ne trouve rien n'a soit pas cherché assez sérieusement, soit été cadrée de façon trop étroite.
Répondez à huit questions pour évaluer votre posture de sécurité IA. Aucune donnée n'est collectée. Tout s'exécute dans votre navigateur.
4 à 6 semaines pour un pipeline de base couvrant l'analyse statique et la vérification de signature. 8 à 12 semaines pour un sandboxing comportemental complet avec intégration CI/CD. Le goulot d'étranglement est rarement la technologie d'analyse elle-même. C'est l'intégration avec votre registre de modèles existant (MLflow, Weights & Biases, JFrog ML) et la définition de la logique de politique : ce qui est bloqué vs signalé vs mis en quarantaine. Nous avons constaté que les décisions de politique prennent plus de temps que l'ingénierie.
La complexité des formats ajoute du temps. Pickle, PyTorch, GGUF, Keras et SafeTensors nécessitent chacun des approches d'analyse différentes. Pickle reste le format le plus à risque parce que torch.load() exécute du Python arbitraire pendant la désérialisation, ce qui explique pourquoi le sandboxing comportemental compte davantage que l'analyse statique pour ce format. SafeTensors est l'option de sérialisation la plus sûre et la plus simple à analyser, mais moins de 20 % des modèles de production l'utilisent aujourd'hui. Votre pipeline doit tous les gérer car vous ne pouvez pas contrôler le format que choisissent les fournisseurs de modèles en amont.
Ces plateformes excellent dans ce qu'elles font. L'intégration Protect AI de Palo Alto (via Prisma AIRS) vous offre l'analyse de modèles au sein de votre pile de sécurité existante. Le MLSecOps de JFrog gère la gouvernance du registre de modèles. Wiz ajoute l'AI-BOM à la visibilité cloud. Ce qu'elles ne font pas : concevoir l'architecture de bout en bout, configurer la génération de ML-BOM dans votre pipeline CI/CD spécifique, construire la logique de politique pour votre contexte réglementaire, ou réorganiser votre flux de travail de déploiement de modèles. Ce sont des outils d'analyse. Nous sommes l'équipe de mise en œuvre qui les fait fonctionner ensemble.
De nombreuses missions débutent avec des organisations qui disposent déjà de ces plateformes mais ont besoin d'aide pour les opérationnaliser. Un schéma courant : l'équipe de sécurité a acheté Protect AI il y a six mois, a lancé une analyse, obtenu 400 résultats, puis s'est enlisée parce que personne n'a relié ces résultats à des flux de remédiation ni intégré l'analyse au pipeline de promotion des modèles.
La barrière technique à l'empoisonnement de modèle est plus basse que ne le supposent la plupart des CISO. La recherche démontre qu'aussi peu que 250 documents empoisonnés dans un corpus d'entraînement peuvent installer une porte dérobée dans un modèle à 13 milliards de paramètres. Microsoft a publié des méthodes de détection révolutionnaires en février 2026, mais la plupart des organisations n'ont aucune capacité de détection déployée. Le problème de dégradation de sécurité due au fine-tuning est plus immédiat et plus courant : Llama 3.1 8B chute de 0,95 à 0,15 en résilience à l'injection de prompt après un seul cycle de fine-tuning. Ce n'est pas une attaque. C'est un fine-tuning normal sans réévaluation de la sécurité.
Les incidents documentés d'empoisonnement intentionnel de modèles en production restent rares. Mais les conditions sont réunies : plus de 80 % des modèles de ML utilisent la sérialisation pickle, 62 % des équipes de sécurité ne parviennent pas à identifier où les modèles sont déployés, et un modèle nommé « baller423 » sur Hugging Face s'est révélé établir un reverse shell vers Kreonet. Le précédent de la FTC en matière de restitution de modèles (Weight Watchers/Kurbo, 2022) signifie qu'un modèle empoisonné pourrait vous forcer à le supprimer et à le réentraîner de zéro, pour des coûts qui éclipsent la violation elle-même.
L'EU AI Act est pleinement applicable le 2 août 2026. Pour les systèmes d'IA à haut risque, vous avez besoin d'une documentation technique couvrant la provenance, la portée, les caractéristiques et les méthodologies de nettoyage des données d'entraînement. Les obligations de chaîne d'approvisionnement exigent que les importateurs et distributeurs vérifient l'évaluation de conformité, la documentation technique et le marquage CE. Concrètement, cela signifie des ML-BOM pour chaque modèle de votre pipeline, des attestations signées pour la provenance et des pistes d'audit pour les décisions de fine-tuning.
Le ML-BOM CycloneDX est le standard le plus prêt à être mis en œuvre. SPDX 3.0 a ajouté des profils IA/ML en 2024, et certaines organisations ont besoin des deux formats pour différents publics réglementaires. Nous construisons le pipeline de documentation afin que le suivi de la provenance soit automatisé, et non un exercice de conformité manuel. L'erreur courante est de traiter cela comme un projet de documentation ponctuel. Chaque cycle de fine-tuning, chaque mise à jour de modèle et chaque changement de jeu de données doit générer des enregistrements de provenance mis à jour. Si votre ML-BOM est statique, il est erroné en quelques semaines.
La séparation des privilèges en est le fondement. Chaque agent reçoit un profil au moindre privilège qui définit quels outils il peut appeler, quelles API il peut consulter et quels chemins du système de fichiers il peut toucher. Cela reproduit le modèle de capacités de Linux appliqué aux agents IA. La RCE de GitHub Copilot (CVE-2025-53773, CVSS 7.8) s'est produite parce que le mode YOLO donnait à l'agent un accès système sans restriction, et une injection de prompt dans la documentation d'un dépôt a dégénéré en exécution de code à distance complète. Les couches de politiques déterministes empêchent entièrement ce chemin d'escalade.
La surveillance à l'exécution ajoute une base de référence comportementale qui détecte les actions anormales des agents (appels d'outils inattendus, schémas d'API inhabituels, tentatives d'escalade de privilèges) sans ajouter de latence aux opérations normales. Il Y A un léger coût de latence pour les vérifications de sécurité sur les opérations à haut risque : écritures de système de fichiers, appels d'API cloud, accès aux identifiants. Pour la plupart des déploiements en entreprise, cela représente 50 à 200 ms par opération contrôlée. Les opérations à faible risque (lecture de sources de données approuvées, génération de texte, appel d'API préapprouvées) passent sans aucune latence ajoutée. La question est de savoir si 50 à 200 ms sur les appels à haut risque est acceptable comparé à un agent disposant d'un accès système complet et sans garde-fous.
Les incidents de sécurité IA exigent une criminalistique différente des intrusions réseau. Pour les attaques au niveau modèle (empoisonnement, portes dérobées), la séquence de réponse est : isoler le modèle de la production, vérifier l'intégrité du pipeline d'entraînement, rechercher une exfiltration de données via les sorties du modèle (les modèles peuvent encoder des données volées dans leurs poids et les divulguer via des prompts soigneusement conçus), et déterminer si vous devez réentraîner à partir d'un point de contrôle réputé sain.
Pour les incidents d'IA agentique, vous devez également tracer chaque appel d'outil et chaque action effectuée par l'agent, vérifier l'intégrité de sa mémoire et de sa fenêtre de contexte (l'injection de prompt peut persister entre les sessions si le contexte est stocké), et rechercher un mouvement latéral via les permissions de l'agent. Les processus de réponse aux incidents génériques ne couvrent pas la criminalistique au niveau modèle parce que les artefacts sont différents. Vous n'analysez pas des journaux réseau et des vidages mémoire. Vous analysez des poids de modèles, la provenance des données d'entraînement, les historiques de fine-tuning et les journaux d'actions des agents. Nous construisons des plans spécifiques à ces scénarios, incluant des procédures de préservation des preuves pour les poids de modèles (qui peuvent atteindre des centaines de gigaoctets), une documentation de chaîne de possession pour les données d'entraînement, et des modèles de communication pour les régulateurs susceptibles d'exiger une restitution de modèle.
Les fondements techniques de cette solution, publiés sous forme de whitepapers détaillés.
WP-91
ML-BOM, analyse de modèles, signature cryptographique, détection du shadow AI et confidential computing pour les pipelines ML d'entreprise.
WP-18
Validation IA multicouche, tests de robustesse adverse et cadres de conformité NIST AI RMF.
WP-89
Analyse des violations 2025, garde-fous neuro-symboliques et architecture de sécurité IA constitutionnelle pour les systèmes en production.
WP-93
Détection de l'empoisonnement des données, suivi de la provenance et infrastructure d'IA souveraine pour les environnements à haute assurance.
62 % des équipes de sécurité ne parviennent pas à identifier où les modèles d'IA sont déployés dans leur propre environnement.
La plupart des organisations découvrent leurs lacunes de sécurité IA après un incident. Nous vous aidons à les trouver avant qu'il ne survienne.