Un assistant connecté à la messagerie, au CRM ou aux fichiers ne traite pas seulement les consignes de son utilisateur. Il lit aussi des contenus externes qui peuvent contenir des instructions conçues pour le détourner. Cette attaque, appelée prompt injection, devient plus importante lorsque le système peut agir.
Injection directe et indirecte
L’injection directe apparaît lorsqu’un utilisateur demande explicitement au modèle d’ignorer ses règles. L’injection indirecte se cache dans une page web, un courriel, un PDF, un ticket ou une donnée récupérée. L’assistant peut interpréter cette donnée comme une nouvelle instruction alors qu’elle devrait rester un simple contenu à analyser.
Par exemple, une page peut tenter d’ordonner à l’agent de révéler son contexte, d’envoyer un fichier ou de modifier une tâche. Le texte peut être invisible pour un humain ou présenté comme une note technique anodine.
Pourquoi un meilleur prompt système ne suffit pas
Une consigne robuste réduit certains comportements mais ne constitue pas une frontière de sécurité absolue. Le modèle manipule des instructions et des données dans un même espace sémantique. Il faut donc limiter les conséquences possibles indépendamment de sa réponse.
Séparer lecture et action
Un agent chargé de résumer des documents n’a pas besoin de supprimer des fichiers ni d’envoyer des courriels. Construisez des outils distincts, exposez uniquement les fonctions nécessaires et donnez des permissions minimales.
Lorsqu’une action est sensible, demandez une confirmation présentant clairement la destination, les données transmises et l’effet attendu. Une validation générique « continuer ? » ne permet pas à l’utilisateur de détecter le détournement.
Considérer les contenus récupérés comme non fiables
- étiqueter la provenance des données ;
- séparer les instructions internes des documents externes ;
- filtrer ou neutraliser les formats inutiles ;
- ne pas autoriser un contenu lu à choisir seul un nouvel outil ou destinataire ;
- limiter les volumes et domaines accessibles.
Protéger les secrets
Le modèle ne devrait pas recevoir les clés API complètes si une passerelle peut exécuter l’action à sa place. Les jetons doivent être liés à un périmètre, une durée et un compte technique. Ne placez pas de secret permanent dans un prompt ou un document accessible à l’assistant.
Journaliser les décisions importantes
Conservez la demande, les sources consultées, l’outil appelé, les paramètres sensibles et le résultat. Les journaux doivent eux-mêmes être protégés et ne pas devenir un second réservoir de données confidentielles.
Tester avec des scénarios réalistes
- Document contenant une fausse instruction administrative.
- Courriel demandant d’envoyer une pièce jointe à une autre adresse.
- Page web tentant de déclencher un outil.
- Résultat de recherche contenant des données conçues pour exfiltrer le contexte.
- Utilisateur légitime demandant une action au-delà de ses propres droits.
Mesurez non seulement si l’agent reconnaît l’attaque, mais surtout si l’architecture empêche l’action dangereuse lorsqu’il se trompe.
Prévoir l’arrêt et la reprise
Ajoutez un moyen de désactiver rapidement une intégration, révoquer les jetons et suspendre les automatisations. Définissez qui reçoit les alertes et comment examiner une séquence d’actions. Un agent autonome sans bouton d’arrêt ni propriétaire devient difficile à gérer en incident.
Valider les sorties avant leur utilisation
Un contenu généré peut inclure une URL, une commande, une adresse ou un format inattendu. Appliquez des contrôles déterministes avant de transmettre la sortie à un autre système : liste de domaines autorisés, schéma de données, taille maximale, type de fichier et règles métier. Une réponse en texte libre ne devrait pas devenir directement une requête de base de données ou une commande système.
Pour les tâches à fort impact, utilisez un aperçu montrant exactement l’action préparée et demandez une validation à une personne disposant elle-même du droit nécessaire. L’agent ne doit pas permettre de contourner les habilitations normales de l’utilisateur.
La règle de conception
Traitez le modèle comme un composant capable de raisonner utilement mais susceptible d’être influencé par ses entrées. La sécurité doit venir des permissions, des contrôles déterministes, des validations et de l’observabilité — pas uniquement de la formulation des instructions.
Article informatif. Les obligations et caractéristiques des services peuvent évoluer : vérifiez les sources officielles et faites valider les situations complexes par un professionnel compétent.
