Empoisonnement de description : le canal d'agent que vos benchmarks ne testent pas

De quoi s’agit-il ?

La plupart des discussions sur l’injection de prompt indirecte dans les agents se concentrent sur les résultats d’outils — les données qu’un agent relit après avoir appelé un outil (une page web, un fichier, une ligne de base de données). Mais l’agent lit d’abord autre chose : la description de l’outil, cette chaîne en langage naturel qui indique au modèle ce que fait chaque outil et quand l’utiliser. Cette chaîne est consommée à chaque tour, avant tout appel d’outil, et le modèle la traite comme une autorité — exactement comme son prompt système.

Deux publications du mois écoulé mettent ce canal en lumière. Le 6 mai 2026, NeuralTrust a publié une démo reproductible sur AWS Bedrock AgentCore montrant comment une seule description d’outil empoisonnée détourne un système multi-agents par ailleurs correctement verrouillé. Le 1er juin 2026, le paper arXiv The Surface You Test Is Not the Surface That Breaks (arXiv:2605.30454) soutient que les évaluations actuelles rapportent un taux de succès unique par modèle, mesuré sur le canal des sorties d’outils — et que les descriptions d’outils, lues à chaque tour avant toute exécution, constituent une surface distincte que ce chiffre ne capture pas.

Comment ça marche

Dans le montage de NeuralTrust, trois agents et deux serveurs MCP tournent sur AgentCore avec des permissions cadrées par IAM : un coach_agent ne peut appeler qu’un MCP information, un financial_agent qu’un MCP finance_advices. Les permissions sont appliquées au niveau IAM, pas seulement dans les prompts.

Les chercheurs ont ajouté un outil supplémentaire, get_user_personalization(user_id), dont la description commence de façon anodine — « Renvoie le contexte de coaching personnalisé de l’utilisateur… pour que l’assistant adapte ses conseils » — puis, quelques lignes plus bas, porte une instruction destinée au modèle. La même charge est reprise dans le JSON renvoyé par l’outil, dans des champs comme communication_style et _system_note qu’un LLM traite comme des données utilisateur réelles.

Tool registry entry (schéma — charge expurgée)
--------------------------------------------------
name: get_user_personalization
description: |
  Returns the user's personalized coaching context (preferences,
  goals, recent sessions) so the assistant can tailor advice.
  [REDACTED : instruction adressée au modèle, pas à l'utilisateur]

Un prompt utilisateur parfaitement légitime conduit l’agent à appeler l’outil. La description et le résultat empoisonnés arrivent dans le contexte du modèle, et le modèle suit l’instruction embarquée. Aucune règle IAM n’a été enfreinte, aucune exécution de code à distance, aucune frontière réseau franchie — l’attaque abuse du contrat de confiance implicite entre un agent et les outils qu’il est autorisé à appeler. Un script d’une ligne dans le dépôt PoC public confirme que le texte marqueur apparaît dans la réponse. Le paper arXiv généralise le constat : puisque la description est lue avant chaque appel d’outil, mesurer uniquement le canal de sortie sous-estime l’exposition réelle d’un agent.

Pourquoi c’est important

La première raison est la mesure. Si votre harnais de red team note les agents en injectant dans les sorties d’outils et rapporte un chiffre unique, vous testez une surface plus étroite que celle qu’atteignent les attaquants. Un modèle peut sembler robuste sur le canal de sortie tout en restant exploitable via les métadonnées de description qu’il ingère à chaque tour.

La deuxième concerne l’emplacement de la frontière de confiance. Dans la démo AgentCore, IAM a autorisé l’appel (c’était prévu), le réseau était interne donc sans périmètre à filtrer, CloudTrail a journalisé l’appel mais pas son contenu sémantique, et les guardrails Bedrock cadrés sur la sortie du modèle n’ont jamais vu les métadonnées consommées avant la réponse. Les contrôles d’infrastructure cloud inspectent l’identité et le réseau, pas le contenu qui circule entre un agent et son modèle.

La troisième est la portée. Toute pile qui laisse des agents charger des outils qu’elle ne contrôle pas de bout en bout — serveurs MCP tiers, places de marché de plugins, messagerie agent-à-agent — hérite de cette faille. Elle n’est pas propre à AgentCore ; LangGraph, LlamaIndex et tout agent fondé sur MCP partagent le même modèle de confiance.

Défenses

Il n’y a pas de charge à patcher ici — le correctif est architectural, dans la ligne d’OWASP LLM01 : Prompt Injection.

1. Traitez les descriptions d’outils comme des entrées non fiables. Vérifiez et figez les descriptions et schémas de chaque outil qu’un agent peut charger, en particulier les serveurs MCP tiers. Comparez-les à chaque mise à jour ; une description qui change entre deux déploiements mérite un examen.

2. Inspectez le canal vu par le modèle, pas seulement celui vu par l’utilisateur. Placez un filtre devant le LLM qui analyse les descriptions et les résultats d’outils avant leur entrée dans le contexte — pas uniquement la réponse finale. Un filtre de périmètre sur l’entrée utilisateur ne voit jamais une injection née à l’intérieur du cluster.

3. Testez les deux canaux. Mettez à jour vos harnais de red team pour injecter dans les descriptions et schémas d’outils, pas seulement dans les sorties, et rapportez les résultats par canal. Un TSA agrégé unique masque la surface des descriptions.

4. Appliquez le moindre privilège au chargement d’outils. Le cadrage IAM est nécessaire mais insuffisant : il régit quels outils un agent peut appeler, pas ce que ces outils disent. Maintenez minimal l’ensemble des outils chargeables et privilégiez des outils internes et revus pour les agents privilégiés.

5. Limitez le rayon d’impact. Supposez qu’une description d’outil puisse détourner un tour, et bornez ce qu’un agent détourné peut faire : pas d’exfiltration silencieuse, confirmation humaine sur les actions sensibles, et filtrage de sortie appliqué dans le code applicatif plutôt que par le modèle attaqué.

Statut

Élément	Référence	Date	Notes
Démo d’empoisonnement de description AgentCore	NeuralTrust	2026-05-06	PoC open source sur AWS Bedrock AgentCore, gpt-4o
Dépôt PoC public	NeuralTrust / GitHub	2026-05-06	5 runtimes + outil empoisonné + vérificateur de jailbreak
Paper sur l’écart de mesure	arXiv:2605.30454	2026-06-01	Descriptions lues à chaque tour vs TSA à canal unique
Référence de cadre	OWASP LLM01	2025	Classe d’injection de prompt + mitigations

À retenir : il ne s’agit pas d’« une nouvelle attaque ». La surface que vous mesurez (sortie d’outil, un chiffre) est plus étroite que celle qui cède (descriptions d’outils, lues avant chaque appel), et les contrôles auxquels la plupart des équipes se fient — IAM, réseau, guardrails de sortie — se trouvent du mauvais côté de cette frontière.