Comment détecter l'injection de prompt dans votre stack LLM
Réponse courte
Senthex exécute 26 shields entrée/sortie à chaque appel au niveau du proxy — motifs d'injection de prompt et de jailbreak, PII, fuite de secrets et stéganographie unicode — chacun renvoyant un verdict, un score et une version de règle, avec une action configurable : log, warn, block ou redact. C'est basé sur des motifs et best-effort, pas exhaustif : l'OWASP classe l'injection de prompt en LLM01 justement parce qu'aucun filtre n'attrape tout.
Comment détecter l'injection de prompt dans une application LLM ?
Vous placez un contrôle sur le chemin que parcourt le texte non maîtrisé. Senthex est un reverse proxy : chaque requête et réponse le traverse avant d'atteindre le modèle et avant de revenir à votre app. À chaque appel, il exécute ses shields et enregistre, par shield, ce qui a déclenché, le score et la version de règle. Vous choisissez l'action par shield :
- log — observer en mode shadow sans changer le comportement ;
- warn — signaler pour revue ;
- block — refuser l'appel ;
- redact — retirer PII ou secrets avant que le modèle ne les voie.
La détection en MVP est basée sur des motifs, pas un second LLM qui juge le premier — cela garde le budget de latence faible et évite une surface d'attaque récursive.
Quels types d'injection cherche-t-il ?
Les shields visent les familles d'attaques courantes :
- Jailbreaks et overrides type « DAN » qui tentent d'annuler votre system prompt ;
- Détournements de persona qui re-castent le modèle dans un autre rôle ;
- Exfiltration de system prompt et de données ;
- Attaques multi-tours qui se construisent à travers les messages ;
- Stéganographie unicode qui cache des instructions dans des caractères invisibles ;
- Fuites de secrets (clés d'API, tokens) côté requête et réponse.
Nous avons écrit un guide pratique pour tester votre propre LLM face à ces attaques, pour voir ce qui est attrapé avant de compter sur quoi que ce soit.
Pourquoi détecter au proxy plutôt que dans l'app ou chez le fournisseur ?
Deux raisons. D'abord, juridiction et couverture : un proxy applique le contrôle avant qu'un token ne quitte votre environnement, et vous donne un seul endroit pour détecter sur tous vos fournisseurs (OpenAI, Anthropic, Mistral, Gemini, OpenRouter) avec un audit log unique. Ensuite, la couche d'intégration : les guardrails côté fournisseur (Bedrock, Azure Content Safety, Vertex) sont à l'intérieur du périmètre de confiance du fournisseur et valent la peine d'être laissés activés — mais ils ne voient en général pas les attaques qui exploitent votre intégration, comme l'injection par upload de document ou l'abus d'appel d'outils. Gardez les guardrails fournisseur activés et mettez un contrôle devant.
Les limites honnêtes
Aucune couche de détection n'est une garantie, et nous ne la vendons pas comme telle.
- Best-effort, jamais exhaustif. La détection par motifs a des faux positifs et des faux négatifs ; un attaquant déterminé peut trouver des failles. C'est la nature de LLM01.
- Défense en profondeur, pas une solution miracle. Senthex est une couche — gardez le durcissement de vos prompts, la conception d'outils à moindre privilège et la revue humaine.
- Pas une « conformité article 15 ». Les shields sont un contrôle technique qui se mappe à la cybersécurité de l'article 15(5) (résilience aux altérations) ; ils ne rendent pas votre système conforme article 15 à eux seuls.
Où pouvez-vous stopper l'injection de prompt ?
| Propriété | Code applicatif seul | Guardrails côté fournisseur | Proxy Senthex (devant) |
|---|---|---|---|
| Tourne avant qu'un token ne quitte votre juridiction | Oui, mais à vous de le bâtir et le maintenir | Non — dans le périmètre du fournisseur | Oui — proxy EU-hosted devant le modèle |
| Un contrôle unique sur plusieurs fournisseurs | Non | Non — par fournisseur | Oui — OpenAI, Anthropic, Mistral, Gemini, OpenRouter |
| Preuve par shield dans un audit log | Ce que vous construisez | Limitée | Verdict, score, version de règle par appel |
| Attrape les attaques de la couche d'intégration (upload, abus d'outils) | Si vous avez écrit les contrôles | En général non | Visé par des shields dédiés |
| Exhaustif / une garantie | Non | Non | Non — best-effort (OWASP LLM01) |
Questions fréquentes
Comment détecter l'injection de prompt dans mon application LLM ?
Placez un contrôle sur le chemin que parcourt le texte non maîtrisé. Senthex proxifie chaque appel et exécute 26 shields entrée/sortie — motifs d'injection et de jailbreak, PII, fuite de secrets et stéganographie unicode — chacun renvoyant un verdict, un score et une version de règle, avec une action par shield : log, warn, block ou redact. C'est basé sur des motifs et best-effort.
La détection d'injection de prompt est-elle fiable à 100 % ?
Non, et aucun fournisseur honnête ne vous dira le contraire. La détection est basée sur des motifs et best-effort, avec des faux positifs et des faux négatifs. L'OWASP classe l'injection de prompt en LLM01 justement parce qu'aucun filtre n'est exhaustif. Utilisez-la comme une couche de défense en profondeur, avec le durcissement des prompts et des outils à moindre privilège.
Pourquoi détecter à un proxy plutôt que via les guardrails de mon fournisseur ?
Gardez les guardrails fournisseur activés — ils sont utiles. Mais ils sont à l'intérieur du périmètre du fournisseur et manquent en général les attaques de votre couche d'intégration (injection par upload de document, abus d'appel d'outils). Un proxy devant applique les contrôles avant qu'un token ne quitte votre juridiction et donne un audit log unique sur tous les fournisseurs.
Peut-il rédiger les PII avant que le modèle ne les voie ?
Oui — le mode redact retire les PII ou secrets détectés de la requête avant qu'elle n'atteigne le modèle. La détection de PII est best-effort et dépendante de la langue ; comme la détection d'injection, c'est un contrôle pour réduire l'exposition, pas une garantie de couverture parfaite.
Utiliser Senthex me rend-il conforme à l'article 15 de l'EU AI Act ?
Aucun fournisseur ne le fait à lui seul. Les shields sont un contrôle technique qui se mappe à la cybersécurité de l'article 15(5) (résilience aux tentatives d'altérer l'usage, les sorties ou la performance), et l'enregistrement par appel alimente la tenue de registres de l'article 12 — mais l'évaluation de conformité et la documentation, c'est votre travail.
Testez-le sur votre propre trafic
Démarrez sur le plan Free (1 000 requêtes/mois, sans carte), pointez votre base_url vers Senthex, et regardez les shields scorer des appels réels. Si vous utilisez des agents ou des outils MCP, lisez ensuite comment l'injection cascade entre agents.