Pour Amazon Web Services (AWS) et le SANS Institute, il faut partir d’un principe simple : chez les agents logiciels, le prompt système n’est pas un mécanisme de défense. Ces consignes internes servent à cadrer le comportement d’un agent. Elles ne suffisent pas à le sécuriser.
Le fond du problème tient en peu de mots. D’après AWS et le SANS Institute, dès qu’une entrée malveillante est injectée dans le contexte d’un agent, celui-ci peut être amené à ignorer ses instructions, à les contourner ou à les réinterpréter. Dit autrement, si votre sécurité tient à un « n’exécute pas telle action » glissé dans un prompt, elle tient à du texte. Et seulement à du texte.
Leur message est donc limpide : les garde-fous qui comptent vraiment doivent être placés à l’endroit où l’agent va chercher des données, puis à l’endroit où il déclenche des actions. Les contrôles techniques, eux, doivent vivre dans les connecteurs, les API, les bases de données et les outils eux-mêmes, pour borner concrètement ce que l’agent peut lire, appeler, modifier ou envoyer.
L’intérêt de cette approche, celle que défendent AWS et le SANS Institute, est d’éviter de parier sur la « bonne intention » affichée par l’agent. Même si son prompt lui interdit l’accès à certains fichiers ou le lancement de certaines commandes, au moment de l’exécution, rien ne l’assure.
L’Open Worldwide Application Security Project (OWASP) place d’ailleurs l’injection de prompt tout en haut de la liste des menaces visant les applications construites sur des modèles de langage. La raison, selon l’OWASP, est bien identifiée : ces systèmes peinent encore à faire clairement la différence entre une instruction de confiance et un contenu fourni par un attaquant.
Le cadre recommandé par AWS et le SANS Institute reprend très nettement la logique du « zero trust » : on bloque tout par défaut, puis on n’ouvre qu’un périmètre d’accès très précis. Dans les faits, un agent ne devrait recevoir que les permissions strictement nécessaires à la tâche qu’on lui confie, sur des sources de données et des outils approuvés explicitement.
AWS et le SANS Institute poussent le raisonnement plus loin. Quand un agent agit au nom d’un utilisateur, il devrait avoir exactement les mêmes droits que cet utilisateur, ou moins. Jamais plus. C’est une façon directe de réduire le risque lié aux privilèges excessifs, surtout quand un agent peut enchaîner plusieurs actions sans validation humaine.
Cet avertissement arrive au moment où le déploiement d’agents s’accélère fortement dans les organisations. D’après un rapport publié en 2026, les flottes d’agents en production ont doublé en quatre mois. Et 38 % des entreprises en exploitent désormais plus de 100.
Le problème, c’est que la supervision et la gouvernance ne progressent pas au même rythme. Dans ce même rapport de 2026, plus de 80 % des organisations se disent confiantes dans leur capacité à empêcher les accès non autorisés aux données. Pourtant, près de 9 sur 10 déclarent avoir subi au moins un incident de sécurité lié à un agent au cours des douze derniers mois.
La pression augmente aussi du côté des standards. L’OWASP a mis à jour ses recommandations pour les modèles de langage et publié un Agent Control Standard. De son côté, le National Institute of Standards and Technology (NIST) a lancé en 2026 une initiative consacrée aux normes applicables aux agents.
Cette accélération arrive après plusieurs travaux ayant mis en évidence de nouvelles attaques capables de détourner des tâches avec un taux de réussite de 81 %. Elle arrive aussi après plusieurs compromissions très médiatisées ayant touché plusieurs entreprises. Prudence, donc : pour AWS et le SANS Institute, un prompt système peut guider un agent, mais il ne faut jamais le prendre pour un contrôle de sécurité.
Suivez-moi sur Twitter : @pierrevitre
