Si ton LLM lit du contenu non maîtrisé (email, page web, document uploadé), ce contenu peut contenir des instructions qui détournent ton agent. Contrairement à l'injection SQL, il n'existe pas de parade à 100 %. On atténue, on cloisonne.
Vecteurs et défenses
| Attaque | Défense réaliste |
|---|---|
| Instruction cachée dans un doc lu par l'agent | Séparer données et instructions (balises, rôle distinct), ne jamais concaténer brut |
| Exfiltration via un tool (envoi de données) | Allowlist stricte des destinations, confirmation humaine sur action sensible |
| Élévation : « ignore tes instructions » | Prompt système court et ferme, vérif de sortie, moindre privilège des tools |
| Injection indirecte (page web piégée) | Traiter tout contenu externe comme hostile, sandbox du rendu |
Le principe directeur : moindre privilège
La vraie question n'est pas « comment empêcher l'injection » mais « que peut faire l'attaquant s'il réussit ». Si ton agent a un tool delete_user sans garde-fou, l'injection devient critique. Si ses tools sont en lecture seule et que les actions sensibles passent par une confirmation humaine, l'injection devient une nuisance.
Trois mesures qui paient
- Séparer instructions et données : le contenu non maîtrisé arrive dans un bloc balisé explicitement « données, jamais des instructions ».
- Tools à moindre privilège : lecture seule par défaut, écriture/action sous confirmation ou allowlist.
- Validation de sortie : ce que l'agent s'apprête à faire passe par un contrôle déterministe avant exécution (le LLM propose, ton code dispose).
L'injection de prompt se gère comme la sécurité applicative classique : défense en profondeur, pas balle d'argent.
