Attaque Man‑in‑the‑Prompt : comment ça marche et comment s'en protéger

Vous faites confiance à votre IA pour exécuter vos instructions. Mais que se passe‑t‑il si quelqu’un d’autre modifie secrètement ces instructions ? Une nouvelle technique d’attaque permet à un acteur malveillant de détourner vos prompts et d’induire le modèle en erreur. Le LLM peut alors révéler des informations confidentielles, fournir des réponses trompeuses ou inciter l’utilisateur à effectuer une action dangereuse. Ce guide explique le mécanisme, les vecteurs d’attaque courants et des mesures pratiques pour réduire le risque.

Qu’est‑ce qu’une attaque Man‑in‑the‑Prompt ?

L’attaque ressemble à un « man‑in‑the‑middle », mais elle intervient au niveau du prompt. Un composant malveillant injecte des instructions visibles ou invisibles (caractères invisibles, balises, segments de code) en parallèle de votre prompt. Le LLM exécute ensuite ces instructions et retourne une réponse qui peut contenir des fuites d’informations, des instructions nuisibles ou des liens malveillants.

Les extensions de navigateur sont le vecteur le plus courant aujourd’hui. Elles ont un accès natif au DOM où l’entrée et la sortie du chatbot sont rendues. Mais d’autres vecteurs existent : générateurs de prompts tiers, outils d’automatisation ou scripts d’entreprise.

Les environnements à risque élevé :

• LLM privés en entreprise (accès aux clés API, documents légaux, IP).
• Chatbots personnalisés qui stockent des données sensibles.

Exemples d’impact : divulgation d’une clé API, lien malveillant incitant à exécuter du code, ou instruction au modèle pour formater une réponse de façon trompeuse (bloc de code, tableau) afin de masquer l’origine malveillante.

Important : ne paniquez pas. Ces attaques sont détectables et évitables si vous appliquez des pratiques simples et des contrôles adaptés.

Principaux vecteurs et pourquoi ils fonctionnent

• Extensions de navigateur : accès au DOM, injection facile sans permissions élevées.
• Outils de génération de prompts : modifient le texte avant envoi.
• Automatisations internes : scripts et macros qui construisent des prompts à la volée.

Les extensions représentent un risque particulier car elles tournent dans l’environnement utilisateur et peuvent évoluer après installation. Une extension bienveillante aujourd’hui peut recevoir une mise à jour malveillante demain.

Contrôler les extensions de navigateur

Ne conservez que les extensions essentielles et vérifiées. Privilégiez les éditeurs connus et relisez les avis avec esprit critique. Voici une mini‑méthodologie pour auditer une extension :

1. Vérifiez l’éditeur et la page officielle de téléchargement.
2. Lisez l’historique des versions et les changements de permissions.
3. Testez dans un profil navigateur isolé ou en mode invité.
4. Surveillez l’activité réseau et les processus en arrière‑plan.

Astuce : quand vous utilisez un LLM, appuyez sur Shift + Esc pour ouvrir le gestionnaire de tâches du navigateur. Repérez les processus d’extension qui s’activent exactement au moment où vous saisissez du texte dans le chatbot. Si un processus apparaît uniquement pendant l’édition du prompt, suspectez une injection.

N’installez pas d’extensions qui modifient directement les zones de saisie des chatbots, ni celles qui prétendent « améliorer » vos prompts sans code source auditable.

Saisir manuellement les prompts et vérifier avant d’envoyer

Écrivez vos prompts directement dans la fenêtre du chatbot. Si vous copiez depuis une source externe, collez d’abord dans un éditeur de texte brut (Bloc‑notes, TextEdit en mode texte) pour révéler les caractères invisibles. Supprimez les lignes vides suspectes avec Backspace plutôt que Delete si nécessaire.

Si vous utilisez des modèles de prompt, conservez‑les localement dans une application de notes contrôlée. Évitez les catalogues de prompts publics non audités.

Démarrer de nouvelles sessions dès que le contexte change

Les attaques Man‑in‑the‑Prompt peuvent exploiter le contexte d’une session existante. Si vous avez fourni précédemment des informations sensibles, commencez une nouvelle conversation lorsque le sujet change. Un nouveau chat isole le contexte et réduit la surface d’attaque.

Vérifier les réponses du modèle

Ne prenez pas pour argent comptant une réponse inhabituelle. Signes d’alerte :

• Réponse qui contient des données sensibles non demandées.
• Informations présentées dans un bloc de code ou un tableau sans nécessité.
• Sections additionnelles ou requêtes demandant plus d’informations à la fin du texte.

Si vous observez ces signes, fermez la conversation et ouvrez une nouvelle session après enquête.

Playbook d’intervention en cas d’incident

Suivez ce SOP rapide si vous suspectez une attaque :

1. Isoler la session : fermez le chat et démarrez une nouvelle conversation.
2. Couper les accès : désactivez l’extension suspecte et changez les identifiants/clefs exposés.
3. Collecter les preuves : capture d’écran, logs du navigateur, horodatage.
4. Analyser : identifiez le vecteur (extension X, outil Y, script interne).
5. Remédier : retirer l’extension, mettre à jour politiques, informer l’équipe sécurité.
6. Restaurer : purge des clés compromises, rotation des secrets, vérification des accès.

Ceci constitue un incident runbook minimal. Ajoutez étapes légales et de notification selon votre politique interne.

Matrice des risques et mesures d’atténuation

Notes : les évaluations restent qualitatives. Adaptez‑les au contexte de votre organisation.

Checklist par rôle

Administrateur IT

• Déployer profils navigateur gérés sans extensions non approuvées.
• Configurer journaux et surveillance des processus.
• Forcer rotation des clés et MFA pour accès sensibles.

Développeur

• Ne stockez pas de secrets dans les prompts.
• Validez les entrées externes dans des environnements contrôlés.
• Utilisez des wrappers API qui filtrent les prompts entrants.

Utilisateur final

• N’installez que les extensions nécessaires.
• Saisissez les prompts manuellement pour les sujets sensibles.
• Ouvrez une nouvelle conversation pour chaque sujet contenant des données privées.

Équipe sécurité

• Maintenez une playbook d’incident LLM.
• Effectuez des audits réguliers des extensions et outils de collaboration.
• Formez les employés aux signes d’attaque.

Sécurisation technique recommandée

• Isoler les environnements LLM (profil navigateur, VM, poste dédié).
• Restreindre les permissions des extensions via un catalogue approuvé.
• Implémenter des proxys API qui filtrent et normalisent les prompts avant envoi.
• Activer la rotation fréquente des clés et des jetons.
• Surveiller les sorties anormales du modèle (détection d’exfiltration).

Notes sur la confidentialité et le RGPD

Si des données à caractère personnel transitent vers un LLM, considérez que l’opérateur du modèle peut traiter ou conserver ces données selon ses conditions. Avant d’envoyer des données personnelles :

• Vérifiez le contrat et la politique de confidentialité du fournisseur.
• Minimisez les données transmises (principe de minimisation).
• Documentez les finalités et obtenez les consentements si nécessaire.

Ces précautions réduisent la surface d’attaque et facilitent les obligations de notification en cas de fuite.

Mini‑méthodologie pour valider un outil de génération de prompts

1. Vérifiez l’éditeur, la provenance du code et la licence.
2. Exécutez l’outil dans un bac à sable sans accès aux ressources sensibles.
3. Comparez les prompts entrants et sortants en texte brut.
4. Surveillez les appels réseau pour déceler exfiltration.

Critères d’acceptation pour une protection minimale

• Les utilisateurs ne peuvent pas installer d’extensions non approuvées.
• Les prompts contenant secrets sont créés uniquement dans un profil isolé.
• Une procédure d’intervention documentée existe et a été testée.

Glossaire court

• LLM : grand modèle de langage.
• Prompt : instruction envoyée au modèle.
• DOM : Document Object Model, structure de la page web.

Foire aux questions

Comment reconnaître rapidement une attaque ?

Si la réponse contient des informations que vous n’avez jamais fournies ou si elle demande des actions inhabituelles (cliquer sur un lien, exécuter du code), suspectez une injection.

Les extensions open source sont‑elles sûres ?

Open source aide à l’audit, mais ne remplace pas une gouvernance : vérifiez le mainteneur, les commits récents et les dépendances.

Que faire si une clé API fuit ?

Révoquez la clé immédiatement, procédez à une rotation, analysez les logs d’usage et suivez le playbook d’incident.

Conclusion

Les attaques Man‑in‑the‑Prompt exploitent la confiance que nous accordons aux interfaces de chat LLM. Elles restent évitables avec des règles simples : limiter les extensions, vérifier les prompts en texte brut, isoler les sessions sensibles et disposer d’un playbook d’intervention. La combinaison de formation, d’outils techniques et de processus réduit fortement le risque.

Résumé des actions immédiates : désactivez les extensions non vérifiées, rédigez vos prompts dans un éditeur de texte brut lorsque nécessaire, démarrez de nouvelles sessions pour les sujets sensibles, et mettez en place une procédure d’incident.

Citation d’expert (générique) : « La sécurité des interfaces LLM repose autant sur la gouvernance utilisateur que sur les contrôles techniques. »