Prompt injection

Un assistant reçoit parfois dans un même contexte les règles fixées par son concepteur, la demande d’un utilisateur et des contenus externes. Une injection tente de présenter une donnée non fiable comme une consigne à suivre : « ignore tes règles », « révèle les informations précédentes » ou « utilise tel outil ». Le modèle traite du langage ; il n’applique pas spontanément une frontière de sécurité parfaite entre tous ces textes.

Le risque augmente lorsque l’assistant consulte une boîte de réception, un site web ou une base documentaire puis peut appeler des outils. Une phrase hostile insérée dans un document peut alors chercher à orienter une recherche, une réponse ou une action. Ce n’est pas seulement un problème de formulation : c’est un problème de capacité accordée à l’application.

• Le contenu externe est une donnée, jamais une autorisation.
• Les outils accessibles à l’assistant ont un objectif étroit et vérifiable.
• Une demande inhabituelle peut être bloquée ou soumise à une personne.

Les LLM sont utiles pour interpréter une demande, mais ils ne remplacent pas les contrôles d’accès d’un logiciel. Un agent correctement conçu n’obtient aucune permission nouvelle parce qu’un texte le lui demande. Cette séparation est centrale dans tout projet d’agent IA.

Un assistant isolé qui rédige un brouillon présente surtout un risque de réponse trompeuse. Un assistant connecté peut lire des documents internes, chercher des contacts, créer une tâche ou préparer une modification dans un outil métier. L’impact dépend donc des données auxquelles il accède et des actions qu’il est autorisé à effectuer, pas seulement de la qualité de son prompt.

Les sources apparemment ordinaires sont des vecteurs possibles : pièce jointe, commentaire dans un ticket, page consultée par un agent de veille ou document partagé par un tiers. Une équipe doit cartographier ces entrées et identifier ce qui se produirait si leur contenu était malveillant. Les règles métier, elles, restent dans une configuration contrôlée et revue.

• Limiter chaque connecteur aux dossiers, champs et opérations nécessaires.
• Éviter les exports généraux et les suppressions sans validation.
• Tester les scénarios où un contenu demande une action hors périmètre.

Un protocole tel que MCP facilite la connexion d’outils, mais il ne transforme pas un contenu non fiable en contenu sûr. La protection se décide dans les droits de l’outil, l’authentification, la validation des paramètres et la journalisation. Une intégration IA sérieuse rend ces responsabilités explicites avant l’ouverture au flux réel.

Il n’existe pas de phrase magique qui empêche toutes les injections. Les consignes données au modèle sont une couche utile, mais elles s’ajoutent à des mesures techniques et opérationnelles. La première consiste à réduire les conséquences possibles : un assistant ne peut pas transmettre une donnée ou modifier un dossier si son identité n’en a pas le droit.

Pour les actions sensibles, l’interface demande une confirmation lisible à la personne responsable. Elle peut afficher la destination, les données concernées et la raison de l’action proposée. Les paramètres transmis aux outils sont ensuite validés par le logiciel, plutôt que confiés tels quels à une génération de texte.

• Utiliser des autorisations minimales et temporaires lorsque cela est possible.
• Journaliser les appels d’outils, leurs paramètres et le résultat obtenu.
• Prévoir un arrêt rapide du connecteur et une revue des incidents observés.

Un audit IA peut recenser les sources, les droits et les décisions à faire valider avant le développement. Les tests incluent des documents volontairement trompeurs et des demandes indirectes, puis vérifient que l’agent refuse, demande confirmation ou reste dans son rôle. Ce travail est à reprendre lorsqu’un nouvel outil, une nouvelle source ou un nouveau périmètre est ajouté. Les incidents sont aussi utiles à l’équipe : ils indiquent quel accès doit être réduit, quelle étape exige une confirmation et quel contenu doit être isolé.