Publié le 6 mai 2026 · L'équipe Byss Group
Donner des outils à un modèle de langage, c'est donner des mains à un système qui lit tout ce qu'on lui met sous les yeux. Le risque central en découle : l'injection de prompt, des instructions malveillantes cachées dans un contenu que l'agent traite, un email, une page web, un document, et qui tentent de détourner son comportement.
Pourquoi c'est le risque numéro un
Contrairement à une faille logicielle classique, l'injection exploite la nature même du modèle : il ne distingue pas structurellement les instructions légitimes des instructions lues dans les données. Aucun filtre ne l'élimine à 100 %. La réponse n'est donc pas un patch, c'est une architecture qui borne ce qu'une injection réussie peut obtenir.
Le triptyque défensif
Un : permissions minimales, chaque outil est scopé (lecture seule par défaut, écriture sur liste blanche, jamais de suppression directe), et l'agent n'accède qu'aux données du dossier en cours. Deux : actions irréversibles sous validation, paiement, envoi externe, suppression passent par un dry-run puis une confirmation humaine ou un quota strict. Trois : traçabilité totale, chaque étape, prompt, appel d'outil et résultat est journalisé, horodaté, rejouable pour l'audit.
Les garde-fous en couches
Avant le modèle : validation des entrées, masquage des données personnelles, détection de contenus suspects. Après le modèle : vérification des sorties contre les règles métier, filtres de sécurité, contrôle de format. Autour : evals de sécurité rejouées à chaque changement, kill switch qui coupe l'agent en cas de dérive détectée, et revue périodique des traces.
La panne qui ne lève aucune erreur
En production, la défaillance la plus coûteuse n'est pas le plantage. C'est la réponse fausse servie proprement : requête aboutie, aucune exception, aucune alerte. Le 5 août 2026, nous avons relevé trois défauts de ce type, à la main, sur l'un de nos agents de recherche : une offre exigeant le bac proposée à une personne qui venait d'écrire qu'elle n'en avait pas, les six mêmes fiches servies trois fois de suite, et l'affirmation qu'une offre n'existait pas alors qu'elle figurait au catalogue. Aucun n'avait laissé de trace dans les journaux d'erreurs. Une surveillance qui n'attrape que les pannes ne mesure pas la qualité d'un agent. Il faut évaluer ce qu'il dit, sur des cas nés de vrais échecs, rejoués à chaque livraison.
Ce que renvoie un outil pèse plus que la consigne
L'injection ne vient pas seulement d'un attaquant. Nous l'avons constaté sur nos propres agents : quand la consigne générale dit « réponds d'abord, note ensuite » et que le message renvoyé par un outil dit « confirme que c'est noté », c'est le second qui gagne, parce qu'il arrive juste avant que le modèle rédige. Un chef d'entreprise repartait avec « un conseiller vous rappellera », et rien d'autre. Un texte malveillant glissé dans un courriel, une page ou un document emprunte exactement ce chemin. Deux règles en découlent. Tout ce qui revient d'un outil est une donnée à contrôler, jamais une instruction à suivre. Et les consignes du système et celles des outils doivent dire la même chose : sinon, la dernière lue l'emporte.
La checklist avant la mise en production
Dix points à cocher avant d'ouvrir un agent au public ou à vos systèmes. Un : la liste de ses outils, chacun avec son droit exact, lecture ou écriture. Deux : aucune suppression directe, aucun envoi externe sans validation. Trois : des plafonds par tâche et par jour, en nombre d'actions et en dépense. Quatre : des sorties vérifiées avant exécution, format et règles métier. Cinq : aucun secret dans les consignes du modèle. Six : un arrêt d'urgence testé, qui laisse les systèmes dans un état sûr. Sept : un jeu de cas rejoué à chaque livraison. Huit : un journal de chaque appel d'outil. Neuf : une date de fraîcheur sur les données que l'agent cite. Dix : une liste écrite de ce qu'il s'interdit, comme avancer un chiffre absent de ses sources ou se dire humain. Le point sept suit notre méthode pour évaluer des agents au-delà du benchmark.
Une autorisation qui s'épuise
Pour les actions qui modifient un système, la permission permanente est le maillon faible : un agent détourné garde tous ses droits. Notre laboratoire AEGIS Control explore l'inverse. La proposition d'un agent n'y vaut jamais autorité : cinq portes la séparent de son effet, et chacune émet une trace signée. L'autorisation d'exécution est à usage unique, liée à l'état vérifié de la cible, et vit 15 secondes. La restauration est prévue avant l'action, pas improvisée après. Un assistant de prise de rendez-vous n'a pas besoin de ce niveau. Le principe vaut partout : un droit lié à un geste précis, qui expire, plutôt qu'un accès ouvert en permanence. C'est l'un des cinq principes de notre note sur les systèmes agentiques dignes de confiance.
Journaliser sans trahir
Un journal d'agent sert à reconstituer ce qui s'est passé, pas à archiver les conversations. Nous y écrivons la forme : l'outil appelé, le nombre de résultats, les filtres appliqués, la durée, les élargissements de recherche. Une recherche qui revient vide quatre fois sur dix se voit là, et nulle part ailleurs. Quand la page promet de ne rien conserver, nous n'y écrivons pas la question du visiteur : une télémétrie bavarde ferait de cette promesse un mensonge, et un fichier de plus à protéger. Pour les systèmes à haut risque, le règlement européen sur l'IA imposera aux déployeurs, à compter du 2 décembre 2027, de conserver les journaux au moins six mois (article 26). Décidez dès maintenant ce que vous journalisez, combien de temps, et qui peut le lire.
Les référentiels qui font foi
Quatre textes permettent de vérifier un dispositif sans croire personne sur parole. Le Top 10 de l'OWASP pour les applications de grands modèles de langage (édition 2025) place l'injection de prompt en tête (LLM01) et nomme l'autonomie excessive (LLM06), le traitement inapproprié des sorties (LLM05) et la consommation non bornée (LLM10) : les quatre premiers points de la checklist y répondent. L'OWASP a publié le 9 décembre 2025 un Top 10 propre aux applications agentiques. L'ANSSI a publié le 29 avril 2024 ses recommandations de sécurité pour un système d'IA générative, de la conception à la production. Et pour le haut risque, l'article 14 du règlement européen sur l'IA exigera de pouvoir interrompre le système par un bouton d'arrêt qui l'amène dans un état sûr.
La sécurité comme argument commercial
Ce dispositif n'est pas un frein, c'est ce qui permet de dire oui. Une direction qui voit des permissions documentées, des journaux d'audit et une reprise humaine sur les cas sensibles autorise des périmètres qu'elle refuserait à une boîte noire. La confiance se construit dans l'architecture, pas dans les promesses.
Aucun système n'est invulnérable. Mais un agent bien architecturé transforme un risque diffus en risque borné, mesuré et auditable, exactement ce que demandent vos clients, vos assureurs et le régulateur.
