La prompt injection est passée du sujet académique à la réalité prod en 18 mois. Du coup tout le monde veut détecter en runtime — pas seulement tester en red team. Voilà ce que je rencontre vraiment chez les équipes qui ont mis ça en prod, et où chaque outil casse.
Ce que veut dire "détection runtime"
Trois choses différentes mises sous le même mot :
- Filtrer un prompt utilisateur avant qu'il atteigne le LLM (classification d'intent malveillant).
- Filtrer un contenu externe (RAG, web, document chargé) avant qu'il soit injecté dans le contexte.
- Filtrer un output LLM avant qu'il soit renvoyé à l'utilisateur ou utilisé par un agent.
La plupart des outils ne font pas les trois. Le choix dépend de votre architecture.
Les solutions que je rencontre
Lakera Guard
SaaS commercial suisse. API simple, classifier rapide. Couvre prompt injection user-side et output side. Bonne précision en anglais, plus moyenne en français spécialisé.
Faiblesse : envoi de prompts/outputs à un tiers (en Suisse, ce qui aide RGPD-wise). Coût qui scale avec le volume.
À utiliser quand : vous avez un assistant grand public, vous voulez du clé-en-main, le surcoût latence (50-150 ms) est acceptable.
Rebuff
Open-source. Détection multi-couche (heuristiques, canary tokens, classifier ML, vector DB de prompts injection connus). Le classifier ML est fine-tunable.
Faiblesse : la qualité dépend du fine-tuning, les heuristiques peuvent générer du faux positif sur des prompts métiers normaux.
À utiliser quand : vous voulez un OSS auto-hébergeable, vous avez du temps pour adapter au métier, vous traitez du volume où une plateforme commerciale coûterait cher.
NeMo Guardrails (NVIDIA)
Framework OSS de guardrails programmables. Plus large que la prompt injection : intent classification, topic restriction, fact checking, content moderation. Programmé en Colang.
Faiblesse : courbe d'apprentissage Colang non négligeable. Performance variable selon la complexité des règles.
À utiliser quand : vous voulez orchestrer plusieurs garde-fous (pas juste prompt injection), vous avez une équipe qui peut investir le temps.
Promptfoo (runtime mode)
Bien que principalement test, Promptfoo offre des assertions exécutables côté runtime via des plugins. Pas une solution complète mais utile en complément.
À utiliser quand : vous avez déjà Promptfoo en CI et vous voulez réutiliser les mêmes assertions en runtime.
Classifiers maison fine-tunés
Approche custom : entraîner un classifier (souvent DistilBERT, RoBERTa, ou un LLM léger) sur un dataset de prompts injection annoté. Inférence locale, rapide.
Faiblesse : nécessite du dataset annoté de qualité, doit être ré-entraîné régulièrement.
À utiliser quand : vous avez de la R&D ML, vous traitez du volume important, vous voulez la maîtrise totale.
Constitutional AI / system prompts durcis
Approche pas un outil de détection mais souvent confondue. C'est une stratégie de défense préventive intégrée au prompt système et au modèle (Anthropic notamment). Réduit l'attaque, ne la détecte pas. Voir Constitutional AI vs guardrails classifieur.
Solutions cloud-natives (Azure AI Content Safety, AWS Bedrock Guardrails)
Si vous êtes déjà sur Azure ou AWS, les services managés couvrent prompt injection + content moderation. Intégration native dans Bedrock / Azure AI.
Faiblesse : couplage cloud provider, qualité variable selon les langues, coût.
À utiliser quand : vous êtes déjà engagé sur le cloud provider, vous voulez la simplicité d'intégration.
Tableau de décision rapide
| Cas d'usage | Recommandation initiale | |---|---| | MVP / POC | Rebuff OSS, démarrer en 2 jours | | Assistant grand public | Lakera Guard, en attendant scale | | Volume élevé, OSS-only | Classifier maison fine-tuné + Rebuff en fallback | | Stack NVIDIA / multi-guardrails | NeMo Guardrails | | Déjà sur Azure/AWS | Bedrock Guardrails ou Azure AI Content Safety | | Métier régulé sans envoi tiers | Rebuff + classifier custom self-hosted |
Les pièges classiques
Croire qu'un seul outil suffit
La prompt injection a beaucoup de variantes : indirecte (via document RAG), encodée (base64, ROT13), via langue exotique, multi-turn, via instructions cachées dans des images si modèle multimodal. Aucun outil ne couvre tout. Défense en couches obligatoire.
Mesurer uniquement le faux négatif
L'outil qui bloque 99% des injections en bloquant aussi 30% des prompts légitimes est inutilisable. Mesurer les deux : taux de détection ET faux positifs sur du trafic métier réel. Si pas de baseline traffic réel, le chiffre marketing ne veut rien dire.
Oublier la défense en profondeur
Détection runtime = couche, pas protection. À côté il faut : least-privilege côté tools (voir sécurité MCP), validation humaine sur actions à impact (voir migration chatbot vers agent), isolation tenant côté RAG, log d'audit.
Ne pas avoir de boucle de feedback
Quand un prompt malveillant passe à travers, il faut : alerte → investigation → ajout du pattern aux tests → ré-évaluation outil. Si cette boucle n'existe pas, vous régressez sans le voir.
Mon avis en 1 ligne
Pour une PME ou scale-up qui démarre : Rebuff en OSS, intégré sur les trois étages (input user, contenu externe, output agent), avec mesure des faux positifs sur 2 semaines avant de durcir les règles. C'est le combo qui me semble offrir le meilleur ratio temps/résultat sans engager un budget plateforme.