Systèmes d’IA
Sécurité des agents IA : outils, permissions et chaîne d’approvisionnement des modèles
La sécurité des agents IA consiste à limiter ce qu’un agent peut faire et à savoir de quoi il est fait : donnez à chaque agent uniquement les outils et les permissions dont sa tâche a besoin, exigez l’approbation d’une personne pour les actions destructrices, traitez chaque document et chaque résultat d’outil comme une entrée non fiable, et tenez un inventaire des modèles, des jeux de données et des logiciels dont il dépend.
Offre Free, sans carte bancaire.
Qu’est-ce qu’une nomenclature IA (AI bill of materials) ?
Une nomenclature des logiciels (SBOM) recense les paquets d’une application. Une nomenclature IA étend cet inventaire aux éléments propres à l’IA : les modèles, leurs versions et leurs sources, les jeux de données utilisés pour les entraîner ou les affiner, et les logiciels qui les servent en inférence. Deux formats du secteur le permettent. CycloneDX a ajouté une nomenclature d’apprentissage automatique (ML-BOM) dans sa version 1.5, publiée en juin 2023, et SPDX 3.0 comprend un profil AI et un profil Dataset.
Quel que soit le format, les champs utiles sont les mêmes : la provenance de chaque modèle, la révision exacte que vous exécutez, une empreinte (hash) qui montre qu’il n’a pas changé, sa licence et ses conditions d’utilisation, les jeux de données sur lesquels il repose lorsqu’ils sont connus, et les bibliothèques et l’environnement d’exécution dont il a besoin. C’est cet inventaire qui vous permet de répondre, le jour où un modèle ou une bibliothèque se révèle compromis, à la question de savoir si votre produit est concerné. KROMSE ne construit pas de nomenclature IA aujourd’hui ; elle figure dans la feuille de route ci-dessous.
Comment délimiter les outils et les permissions d’un agent
Un agent est un modèle capable d’appeler des outils : lire des fichiers, interroger des bases de données, envoyer des messages, exécuter des commandes. L’OWASP Top 10 for LLM Applications appelle le risque qui en découle « excessive agency » (agentivité excessive) et le fait remonter à trois causes : des fonctionnalités excessives, des permissions excessives et une autonomie excessive. Chacune a sa parade directe : moins d’outils, des identifiants plus restreints et une personne dans la boucle pour les actions qui comptent.
- Donnez à chaque agent uniquement les outils dont sa tâche a besoin, et écartez les outils généralistes comme un accès shell sans restriction.
- Utilisez des identifiants distincts et étroitement délimités pour chaque agent, en lecture seule partout où c’est possible.
- Exécutez les actions dans le contexte, et avec les permissions, de l’utilisateur pour le compte duquel l’agent agit.
- Exigez l’approbation d’une personne pour les actions destructrices ou irréversibles : suppression de données, envoi de messages, paiements, déploiements.
- Journalisez chaque appel d’outil avec ses entrées, pour pouvoir retracer et examiner les actions.
- Limitez le nombre d’actions qu’un agent peut effectuer, et leur cadence.
L’injection de prompt via les outils et les documents
L’injection de prompt désigne une entrée qui modifie le comportement d’un modèle d’une manière que ses concepteurs n’avaient pas prévue. L’OWASP distingue l’injection directe, saisie par l’utilisateur, de l’injection indirecte, où le modèle absorbe des instructions provenant d’un contenu externe, comme un site web ou un fichier. Pour un agent doté d’outils, l’injection indirecte est le risque le plus important : l’attaquant n’a jamais besoin d’accéder à l’agent, il lui suffit que l’agent lise quelque chose qu’il a écrit, comme une page web, un e-mail ou un ticket.
L’OWASP note qu’il n’est pas certain qu’il existe des méthodes de prévention infaillibles ; la défense passe donc par le confinement. Séparez clairement le contenu non fiable des instructions, gardez les secrets hors du contexte du modèle, validez ce que produit le modèle avant qu’un autre système n’agisse en conséquence, et veillez à ce qu’une instruction injectée ne puisse pas déclencher une action qu’une personne n’a pas approuvée. Si un agent lit du contenu public, partez du principe qu’une partie de ce contenu est hostile.
Fichiers de modèles dangereux et chaîne d’approvisionnement des modèles
Les poids d’un modèle sont des fichiers, et certains formats de fichiers peuvent exécuter du code au chargement. Le format pickle de Python, que la documentation de Hugging Face décrit comme le format par défaut des poids de modèles PyTorch, permet l’exécution de code arbitraire pendant le chargement : ouvrir un modèle picklé provenant d’une source non fiable est donc comparable à l’exécution d’un programme non fiable. Safetensors est un format de stockage de tenseurs conçu comme une alternative sûre à pickle.
Traitez les modèles et les jeux de données comme des dépendances. Téléchargez-les depuis des sources de confiance, fixez la révision exacte plutôt qu’un nom qui évolue, vérifiez les empreintes et privilégiez les formats qui ne peuvent pas exécuter de code. Des données d’entraînement ou un modèle pré-entraîné altérés peuvent modifier le comportement d’une manière que les tests ne révèlent pas ; le règlement sur l’intelligence artificielle (AI Act) cite l’empoisonnement des données et l’empoisonnement de modèle parmi les attaques auxquelles les mesures applicables aux systèmes d’IA à haut risque doivent répondre, au besoin. Les bibliothèques qui chargent et servent les modèles appellent les mêmes contrôles de vulnérabilités que n’importe quel autre paquet.
Quelles règles de l’UE concernent les produits d’IA ?
Deux règlements peuvent s’appliquer au même produit d’IA. L’AI Act, règlement (UE) 2024/1689, encadre les systèmes d’IA selon leur niveau de risque ; son article 15 exige que les systèmes d’IA à haut risque atteignent un niveau approprié d’exactitude, de robustesse et de cybersécurité. Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA), règlement (UE) 2024/2847, fixe des exigences de cybersécurité pour les produits comportant des éléments numériques. En vertu de l’article 12 du CRA, un produit relevant de son champ d’application qui est un système d’IA à haut risque est réputé conforme aux exigences de cybersécurité de l’AI Act lorsqu’il satisfait aux exigences essentielles du CRA et que cela est démontré dans la déclaration UE de conformité.
L’applicabilité de l’un ou l’autre règlement dépend de la nature du produit, de qui le met sur le marché et de la manière dont il est utilisé, et ce n’est pas KROMSE qui en décide. Le socle est le même dans les deux cas : connaître vos composants, gérer les vulnérabilités, restreindre ce que peuvent faire les parties automatisées du système, et conserver les preuves.
Disponible aujourd’hui dans KROMSE
Aujourd’hui, KROMSE contrôle les logiciels qui entourent votre modèle, pas le modèle lui-même.
- Recense les composants de l’application qui appelle ou sert le modèle, et confronte ses lockfiles à OSV.dev, y compris les bibliothèques d’apprentissage automatique et d’agents qu’elle déclare.
- Signale comme critiques les dépendances répertoriées dans la base OpenSSF Malicious Packages.
- Détecte avec Gitleaks les identifiants commités, comme les clés d’API, dans le code au commit analysé ; les valeurs sont masquées et jamais stockées.
- Analyse du code source pour 11 langages, dont Python, TypeScript, JavaScript et Go.
- Analyse les images de conteneurs d’un registre accessible depuis Internet à la recherche de vulnérabilités, d’erreurs de configuration et de secrets, et recherche les erreurs de configuration dans les fichiers Terraform et les Dockerfiles.
- Exporte pour chaque analyse un SBOM CycloneDX JSON et un SBOM SPDX JSON. Ils recensent des paquets logiciels, pas des modèles ni des jeux de données.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T1 2027Sécurité des agents et des modèles d’IA. KROMSE produira une nomenclature des composants d’IA (AI-BOM), examinera les outils et les permissions que vos agents peuvent utiliser, et détectera les fichiers de modèles non sûrs.
- À venir · T4 2026 (novembre)Plug-in pour agents de codage. Un plug-in pour les agents de codage IA vérifiera chaque paquet proposé par l’agent avant son intégration, y compris les paquets qui n’existent pas ou qui n’ont été publiés que quelques jours plus tôt.
- À venir · T1 2027 (janvier)Module AI Act (règlement européen sur l’IA). Un module AI Act ajoutera un inventaire des systèmes d’IA, une classification des risques et une documentation à compléter par une personne.
Questions fréquentes
Qu’est-ce que la sécurité des agents IA ?
C’est la pratique qui consiste à limiter ce qu’un agent IA peut faire et à savoir de quoi il est construit. Concrètement : des outils et des identifiants à moindre privilège, une approbation humaine pour les actions destructrices, des documents et des résultats d’outils traités comme des entrées non fiables, des formats de fichiers de modèles sûrs, et un inventaire des modèles, des jeux de données et des logiciels dont l’agent dépend.
Quelle est la différence entre un SBOM et une nomenclature IA ?
Un SBOM recense les composants logiciels d’un produit, comme les paquets et leurs versions. Une nomenclature IA y ajoute les éléments propres à l’IA : les modèles, leurs sources et leurs révisions, les jeux de données et la manière dont ils ont été utilisés. CycloneDX le permet avec sa ML-BOM, ajoutée dans la version 1.5, et SPDX avec les profils AI et Dataset de SPDX 3.0.
Les fichiers de modèles pickle sont-ils dangereux ?
Ils peuvent l’être. Charger un fichier pickle peut exécuter du code arbitraire ; un modèle picklé provenant d’une source non fiable doit donc être traité comme un programme non fiable. Privilégiez les formats conçus pour ne pas exécuter de code, comme safetensors, ne chargez des modèles que depuis des sources de confiance, fixez la révision exacte et vérifiez son empreinte.
Comment protéger un agent IA contre l’injection de prompt ?
Partez du principe qu’elle se produira, et confinez-la. Séparez le contenu non fiable des instructions, gardez les secrets hors du contexte du modèle, ne donnez à l’agent que les outils et les permissions dont il a besoin, validez ses sorties avant que d’autres systèmes n’agissent en conséquence, et exigez l’approbation d’une personne pour les actions à fort impact. L’OWASP note qu’une prévention infaillible n’existe peut-être pas.
KROMSE analyse-t-il les modèles ou les agents d’IA ?
Non. KROMSE contrôle les logiciels qui entourent le modèle : dépendances, paquets malveillants, secrets commités, code source, images de conteneurs et fichiers d’infrastructure. Il n’inspecte pas les fichiers de modèles, ne construit pas de nomenclature IA et n’examine pas les permissions des agents aujourd’hui. Ces capacités figurent dans la feuille de route.
Guides associés
Sources
- CycloneDX : Machine Learning Bill of Materials (ML-BOM)
- CycloneDX : annonce de la version 1.5
- Spécification SPDX 3.0.1 : profil AI
- OWASP Top 10 for LLM Applications 2025 : LLM01 Prompt Injection
- OWASP Top 10 for LLM Applications 2025 : LLM06 Excessive Agency
- Documentation du Hub Hugging Face : analyse des fichiers pickle
- Hugging Face : documentation de Safetensors
- Règlement (UE) 2024/1689 (règlement sur l’intelligence artificielle, AI Act)
- Règlement (UE) 2024/2847 (règlement sur la cyberrésilience)