Prompt Injection Cheat Sheet : comment protéger assistants, agents, RAG et outils connectés
Cheat sheet complète pour prévenir la prompt injection : surfaces d'attaque, défenses par couche, sécurité agentique, mémoire, validation, HITL et surveillance.
Pour qui
- CTO, security engineers, AI engineers
- Équipes qui déploient assistants, RAG ou agents
- Entreprises exposées à des documents ou contenus externes
À utiliser pour
- Sécuriser un assistant connecté à des outils
- Réduire les risques sur RAG et agents
- Poser un cadre minimal avant mise en prod
Version PDF
Une vraie feuille de référence, pas une impression sale de page web.
La version PDF est pensée pour lecture, partage interne, impression et revue rapide. C'est le format qu'on peut transmettre à un lead tech, un PM, ou un client sans perdre la structure.
Version PDF
Télécharger la fiche en format propre.
Recevez un accès immédiat à une version PDF imprimable et propre de Prompt Injection Cheat Sheet : comment protéger assistants, agents, RAG et outils connectés, conçue pour le partage interne, la revue et la sauvegarde.
- Version print-friendly avec hiérarchie claire
- Checklist, erreurs fréquentes et FAQ propres à exporter
- Ouverture directe du document prêt à enregistrer en PDF
Pas de spam. Le PDF s'ouvre dans un nouvel onglet prêt à enregistrer en PDF.
Sheet view
La fiche elle-même
Module
1. Comprendre où l'injection entre réellement
La prompt injection n'arrive pas seulement depuis l'utilisateur. Elle entre surtout via les données que votre système décide de faire lire au modèle.
Les surfaces d'attaque les plus fréquentes :
- message utilisateur
- contenu web récupéré
- PDF, DOCX, notes internes
- ticket support
- commit message, commentaire de PR, issue GitHub
- mémoire persistante
- paramètres transmis entre agents
OWASP distingue au minimum :
- direct prompt injection
- indirect / remote prompt injection
La vraie règle d'architecture est donc :
> Tout contenu entrant doit être traité comme potentiellement hostile.
Et cela inclut vos propres documents si des utilisateurs ou systèmes externes peuvent les contaminer.
Module
2. Les défenses minimales qui comptent vraiment
Les protections efficaces ne sont pas des slogans. Ce sont des mécanismes concrets, placés aux bons endroits.
Le socle minimum :
1. Séparer instructions et données
Ne concaténez pas naïvement :
``text system prompt + contenu utilisateur + contenu externe ``
Préférez des structures qui rappellent explicitement au modèle :
- ce qui est une instruction
- ce qui est une donnée à analyser
- ce qui n'est jamais à exécuter comme commande
2. Valider et filtrer les entrées
Cherchez :
- expressions d'override
- demandes de révéler le prompt
- tentatives de jailbreak
- payloads encodés ou obfusqués
3. Valider les sorties
Avant de :
- lancer un outil
- écrire en base
- envoyer un email
- appeler une API
... vérifiez que la sortie respecte un schéma ou des règles métier.
4. Human-in-the-loop pour les actions à impact
Si l'action est :
- destructive
- financière
- juridique
- externe
... ajoutez une validation humaine.
Module
3. Cas particulier : agents, mémoire et RAG
Dès que vous ajoutez outils, mémoire ou documents, le risque change d'échelle.
Agents
Un agent mal protégé cumule :
- prompt injection
- tool abuse
- escalade de privilèges
- exfiltration de données
- denial of wallet
Mémoire
Ne stockez pas en mémoire n'importe quoi sans contrôle.
Sinon vous ouvrez la porte à :
- memory poisoning
- contamination inter-session
- dérive progressive du comportement
RAG
Le RAG améliore la factualité, mais ajoute une nouvelle surface :
- le document lui-même peut contenir une instruction malveillante
Règles simples :
- chunker proprement
- conserver la provenance
- afficher les citations
- ne jamais laisser le modèle agir juste parce qu'un document "dit de le faire"
Module
4. Politique d'outils et permissions
La sécurité d'un agent dépend beaucoup plus des permissions outils que du prompt seul.
La règle centrale d'OWASP et des bonnes pratiques Anthropic :
least privilege
Cela veut dire :
- outils limités
- actions limitées
- arguments validés
- destinations contrôlées
Exemples :
| Mauvais | Mieux |
|---|---|
| accès shell général | commandes allowlistées |
| email libre | envoi seulement vers domaines autorisés |
| écriture base sans contrôle | mutation validée par schéma |
| accès mémoire global | mémoire isolée par utilisateur / session |
Votre politique d'outils doit répondre à 4 questions :
- Que peut faire l'agent ?
- Sur quelles ressources ?
- Avec quelles limites ?
- Qui valide les actions sensibles ?
Module
5. Le plan de mise en production minimal
Vous n'avez pas besoin d'un programme de sécurité parfait avant de lancer. Mais vous avez besoin d'un minimum sérieux.
Avant mise en prod :
- input filtering
- output validation
- schéma structuré
- permissions minimales
- logs
- monitoring
- kill switch
- revue humaine sur actions critiques
Après mise en prod :
- red team périodique
- revue des logs
- tests sur injections connues
- mise à jour des filtres et garde-fous
Le but n'est pas de "supprimer" le risque. Le but est de :
- réduire la probabilité
- réduire l'impact
- détecter plus vite
- reprendre le contrôle rapidement
Checklist
Ce qu'il faut verrouiller
- ✓Séparer clairement instructions système et données à analyser
- ✓Filtrer les entrées utilisateur et contenus externes
- ✓Valider les sorties avant tout appel outil ou action métier
- ✓Limiter les outils par allowlist et périmètre
- ✓Isoler mémoire et contexte par utilisateur/session
- ✓Ajouter un human-in-the-loop sur les actions à impact
- ✓Mettre en place logs, alertes et kill switch
Erreurs fréquentes
Ce qui casse la qualité
- Croire qu'un bon prompt système suffit à lui seul
- Passer des documents externes au modèle sans les traiter comme hostiles
- Donner à un agent des outils trop puissants ou trop génériques
- Persister de la mémoire sans politique d'hygiène ni isolation
- Lancer en prod sans tests d'injection réels
FAQ
Questions fréquentes
Un RAG protège-t-il automatiquement contre la prompt injection ?
Non. Il améliore l'accès à la connaissance, mais le contenu récupéré peut lui-même contenir des instructions malveillantes ou trompeuses.
Faut-il toujours mettre une validation humaine ?
Pas pour chaque réponse. Mais pour toute action à impact élevé, oui : suppression, dépenses, email externe, mutation sensible, décision réglementée.
Quelle défense apporte le meilleur ROI ?
La combinaison la plus rentable est souvent : séparation instruction/donnée, validation schéma, permissions minimales, et contrôle humain sur les actions critiques.
Sources
Références utilisées
OWASP
LLM Prompt Injection Prevention Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
OWASP
AI Agent Security Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
Anthropic
Mitigate jailbreaks and prompt injections
https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks
Anthropic
Reduce prompt leak
https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-prompt-leak