Un assistant fondé sur un LLM change la nature de la surface d'attaque : le texte devient une entrée exécutable. Un document indexé, un email ou la réponse d'un outil peut contenir des instructions que le modèle suivra. Les instructions système ne constituent donc pas une frontière de sécurité.
Les référentiels à utiliser
Deux références structurent l'analyse. L'OWASP Top 10 for LLM Applications (édition 2025) liste les classes de vulnérabilités applicatives. MITRE ATLAS décrit les tactiques et techniques d'attaque observées contre les systèmes d'IA, sur le modèle d'ATT&CK.
- LLM01 Prompt Injection, directe ou indirecte.
- LLM02 Sensitive Information Disclosure.
- LLM03 Supply Chain : modèles, jeux de données, dépendances.
- LLM04 Data and Model Poisoning.
- LLM05 Improper Output Handling.
- LLM06 Excessive Agency.
- LLM07 System Prompt Leakage.
- LLM08 Vector and Embedding Weaknesses.
- LLM09 Misinformation.
- LLM10 Unbounded Consumption.
Les risques spécifiques au RAG
Contrôle d’accès au moment de la recherche
Le défaut le plus fréquent : l'index vectoriel contient des documents que l'utilisateur n'a pas le droit de lire. Le modèle les cite alors sans que personne ne l'ait voulu. Les droits d'accès doivent être appliqués au moment de la récupération, avec l'identité de l'utilisateur final, pas celle du service.
Empoisonnement du corpus
Toute source que l'assistant indexe peut porter une injection indirecte : page wiki modifiable, pièce jointe, ticket client. Il faut tracer la provenance de chaque document, limiter les sources autorisées en écriture et tester l'assistant avec des documents piégés.
Les risques spécifiques aux agents et au MCP
Un agent qui appelle des outils via le Model Context Protocol ajoute un risque d'action : envoyer, modifier, supprimer. La gravité d'une injection réussie dépend directement des permissions de l'agent.
- Descriptions d’outils et réponses de serveurs MCP traitées comme des données non fiables.
- Serveurs MCP issus de sources vérifiées, versions épinglées.
- Jetons d’accès au périmètre minimal, par outil, révocables.
- Confirmation humaine avant toute action irréversible ou externe.
- Validation des arguments d’outils par du code, indépendamment du modèle.
Les garde-fous qui tiennent
- Séparer ce qui est de confiance (instructions de l'application) de ce qui ne l'est pas (documents, emails, résultats d'outils).
- Ne jamais exécuter ni interpréter la sortie du modèle sans validation : pas de HTML brut, pas de requête SQL, pas de commande shell.
- Appliquer le moindre privilège aux données et aux outils, refus par défaut.
- Journaliser les appels d’outils et les décisions, sans journaliser les secrets.
- Limiter la consommation : quotas, taille de contexte, nombre d’appels par session.
- Tester en continu avec des scénarios adverses et documenter le risque résiduel.
Considérez qu'une injection finira par réussir. Le travail de sécurité consiste à en borner les conséquences.
Questions fréquentes
Un filtre anti-prompt-injection suffit-il ?
Non. Les filtres réduisent le volume d'attaques mais peuvent être contournés. Ils complètent le moindre privilège, la validation des sorties et la confirmation humaine, sans les remplacer.
Faut-il héberger le modèle soi-même ?
Pas nécessairement. La décision dépend de la sensibilité des données, des engagements contractuels du fournisseur sur la conservation et l'entraînement, et de la localisation du traitement. L'hébergement interne déplace le risque sans le supprimer.
Quelle différence entre OWASP Top 10 LLM et MITRE ATLAS ?
L'OWASP classe des vulnérabilités applicatives pour guider la conception. ATLAS décrit le comportement des attaquants pour guider le threat modeling et la détection. Les deux se complètent.
Ressource associée : Grille de threat modeling LLM, RAG et MCP.
Sources
Cet article informe et ne constitue pas un avis juridique.