La sécurité des agents est un problème systémique : de l'injection de prompts au contrôle à l'exécution

Une étude majeure de 2026 sur la sécurité des agents LLM aboutit à une conclusion que les équipes en entreprise doivent prendre au sérieux : dès lors qu'un modèle peut utiliser des outils, conserver un état et agir au nom d'un tiers, la sécurité ne se résume plus au simple filtrage des prompts. Il s'agit désormais d'un problème systémique qui englobe les flux d'informations, les délégations d'autorité et les états persistants.

1. Pourquoi la sécurité des agents diffère de la sûreté des LLM

L'étude part d'un constat architectural simple : un agent LLM ne se contente pas de générer du texte. Il peut planifier, appeler des outils, naviguer sur le web, exécuter du code, mettre à jour des états et se coordonner avec d'autres agents. Ces capacités transforment les sorties du modèle en entrées pour le flux de contrôle logiciel.

Cela modifie la nature des défaillances. Une instruction malveillante dissimulée dans une page web peut influencer un futur appel d'outil. Un résultat d'outil corrompu peut servir de contexte à une décision ultérieure. Une entrée mémoire compromise peut persister au-delà de la session initiale. Un identifiant délégué peut transformer un plan malveillant en une action réelle. Dans un système multi-agents, une information contaminée peut se propager bien au-delà de l'agent qui l'a rencontrée en premier.

L'étude structure donc la sécurité des agents autour de trois propriétés interdépendantes :

L'implication pratique est qu'une architecture d'agent sécurisée ne doit pas seulement se demander : « Avons-nous bloqué le prompt malveillant ? » Elle doit également poser les questions suivantes : quel contenu cela pourrait-il influencer, quelle autorité la trajectoire résultante pourrait-elle exercer, et quel état cette trajectoire pourrait-elle laisser derrière elle ?

2. La surface d'attaque s'étend sur tout le cycle de vie de l'agent

Ling et ses coauteurs utilisent un cadre orienté système basé sur le cycle de vie plutôt qu'une simple liste de noms d'attaques. Sur le plan opérationnel, il est utile de distinguer le chemin d'action principal — entrée, planification, décision, exécution d'outil et sortie — des surfaces transversales telles que la mémoire, la surveillance et la coordination multi-agents, car ces surfaces peuvent influencer ou observer plusieurs étapes de l'exécution.

Cette perspective axée sur le cycle de vie explique également pourquoi les défenses peuvent être « faiblement compositionnelles », comme le souligne l'étude. Un filtre de contenu peut bloquer une catégorie de texte malveillant sans rien faire contre des identifiants aux privilèges excessifs. Un bac à sable peut contenir l'exécution de code sans empêcher un appel API autorisé. Une étape de validation peut stopper un effet secondaire sans empêcher une écriture mémoire empoisonnée. Une trace peut rendre un incident observable sans pour autant le prévenir.

La sécurité découle donc de la composition des frontières, des privilèges, des contrôles étatiques et des preuves.

3. Mise en correspondance de l'étude avec TrueForge et TrueFoundry

La manière la plus pertinente de présenter le produit n'est pas de dire « TrueFoundry résout la sécurité des agents », mais plutôt de déterminer quelle partie du modèle de systèmes de l'étude chaque couche peut réellement régir.

‍

‍