IA.6 · Héberger, brancher, sécuriser
Sécuriser l'IA en production
Leçon théorique · questionnaire de validation · gratuit, dans le navigateur
Une application d'IA a les failles de toute application (authentification, droits, dépendances), plus des failles propres : le modèle ne distingue pas de façon fiable les instructions des données. Tout texte qu'il lit peut tenter de le détourner, et tout ce qu'il produit peut être faux ou malveillant. La sécurité ne repose donc pas sur le modèle, mais sur l'architecture autour de lui. Cette leçon est théorique.
Ce que vous saurez à la fin : connaître les principaux risques du Top 10 OWASP pour les applications LLM, expliquer l'injection de prompt directe et indirecte, concevoir des défenses en profondeur, protéger les données, limiter la consommation, et sécuriser l'infrastructure d'inférence sur Kubernetes.
1. Le Top 10 OWASP pour les applications LLM (2025)
| # | Risque | En une phrase |
|---|---|---|
| LLM01 | Injection de prompt | du texte détourne le modèle de ses consignes |
| LLM02 | Divulgation d'informations sensibles | le modèle révèle des données qu'il a vues (contexte, RAG, entraînement) |
| LLM03 | Chaîne d'approvisionnement | modèle, bibliothèque ou serveur MCP compromis |
| LLM04 | Empoisonnement des données et du modèle | données d'entraînement ou documents RAG piégés |
| LLM05 | Traitement inapproprié des sorties | la réponse du modèle est exécutée ou affichée sans contrôle (commande, SQL, HTML) |
| LLM06 | Autonomie excessive | l'agent a trop d'outils, trop de droits, trop peu de contrôle |
| LLM07 | Fuite de l'invite système | les consignes (et ce qu'on y a mis par erreur) sont extraites |
| LLM08 | Faiblesses des vecteurs et plongements | fuite entre utilisateurs dans l'index, documents injectés |
| LLM09 | Désinformation | réponses fausses présentées avec assurance |
| LLM10 | Consommation non bornée | requêtes coûteuses en boucle, déni de service et de budget |
2. L'injection de prompt
- Directe : l'utilisateur écrit « ignore tes consignes précédentes et… ».
- Indirecte : l'instruction est cachée dans ce que le modèle lit : une page web, un document indexé, un ticket, un message de journal, une annotation Kubernetes, un commentaire de demande de fusion.
Il n'existe pas aujourd'hui de filtre qui l'empêche à coup sûr. On part donc du principe qu'une injection finira par réussir, et on fait en sorte qu'elle ne puisse rien faire de grave :
- Droits minimaux pour l'identité de l'application ou de l'agent (leçon IA.4) : une injection n'obtient que ces droits-là.
- Séparer les données non fiables : un agent qui lit des contenus externes n'a pas, dans la même session, d'outils sensibles ni de données secrètes.
- Validation humaine des actions à effet.
- Contrôler les sorties : ne jamais exécuter directement une commande ou une requête produite par le modèle ; ne pas afficher de HTML ou de liens non filtrés (une image Markdown vers un site externe peut exfiltrer des données dans son adresse).
- Ne rien mettre de secret dans l'invite système : elle finira par être extraite.
3. Protéger les données
- Ne pas envoyer à un modèle externe ce qu'il ne doit pas voir : secrets, données personnelles inutiles. Masquez-les en amont (un filtre de détection de secrets et de données personnelles).
- Contrat : avec une API, vérifiez la conservation des données, leur usage pour l'entraînement et leur localisation (RGPD).
- Cloisonner le RAG : filtrage par droits dans la recherche (leçon IA.3), et index séparés quand les populations sont très différentes.
- Journaux : les invites et réponses enregistrées sont des données sensibles ; accès restreint, durée de conservation définie.
4. Borner la consommation
Une requête peut demander un contexte immense, une réponse interminable, ou déclencher un agent qui boucle. Défenses : authentification obligatoire, quotas et limites de débit par utilisateur et par équipe (en jetons, pas seulement en requêtes), max_tokens imposé côté serveur, limite de contexte (--max-model-len), limites d'étapes et de durée pour les agents, alertes de budget. Une passerelle d'IA (AI gateway) placée devant les modèles centralise ces contrôles, l'authentification et les journaux.
5. Sécuriser l'infrastructure d'inférence
Tout ce que vous avez appris s'applique :
- Isolation : namespace dédié, NetworkPolicy qui n'autorise que l'application cliente vers le serveur de modèle, et qui interdit au serveur de sortir vers Internet (leçons 3.5 et 6.5).
- Durcissement : utilisateur non root, pas de privilèges, système de fichiers en lecture seule quand c'est possible (leçon 2.12) ; les pods GPU n'ont pas besoin d'être
privileged, seul le device plugin l'est. - Chaîne d'approvisionnement : modèles tirés de votre registre et référencés par empreinte, provenance vérifiée, signatures ; préférez le format safetensors, qui ne contient que des poids, aux anciens formats sérialisés (pickle) qui peuvent exécuter du code au chargement.
- Exposition : le serveur d'inférence n'est jamais exposé directement sur Internet ; il passe derrière l'application ou la passerelle qui authentifie.
6. Tester et encadrer
- Tests adverses (red teaming) : un jeu de requêtes d'injection, de demandes interdites et d'extraction d'invite, rejoué dans le pipeline à chaque changement (leçon IA.5). Des outils ouverts (garak, promptfoo) en fournissent une base.
- Garde-fous de contenu : des modèles de classification dédiés filtrent entrées et sorties ; ils réduisent le risque, ils ne le suppriment pas.
- Réglementation : le règlement européen sur l'IA (AI Act) impose, selon l'usage, transparence, documentation et gestion des risques ; le RGPD s'applique aux données personnelles traitées. Impliquez tôt le juriste et le délégué à la protection des données.
La règle à retenir : traitez le modèle comme un utilisateur non fiable de vos systèmes, et tout ce qu'il lit comme une entrée non fiable.
Validez la leçon avec le questionnaire.