Tu as tout fait comme il faut. Tu as audité tes serveurs MCP (Model Context Protocol — un standard universel de branchement pour les outils IA, comme l'USB mais pour les données), verrouillé les permissions, épinglé les versions de schéma pour que ton agent IA — un programme qui utilise des outils de manière autonome — n'appelle que ce que tu autorises. Ton infrastructure d'agents a l'air blindée pour la prod. Tu dors tranquille.

Tu ne devrais pas.

Parce que chaque outil appelé par ton agent renvoie une réponse. Et en ce 25 avril 2026, quasi personne dans l'industrie ne valide ce qu'il y a dans cette réponse avant qu'elle n'atterrisse dans la fenêtre de contexte de l'agent — la mémoire de travail où le modèle IA est incapable de distinguer des instructions légitimes de la merde qu'un outil vient de lui recracher.

Trois plateformes, même angle mort

Depuis début avril, les trois plus gros acteurs de l'IA ont livré des fonctionnalités de sécurité pour agents — et tous protègent la mauvaise porte.

Le 8 avril, Anthropic a lancé Managed Agents avec des permissions scopées et du stockage de credentials. Ça contrôle quels outils l'agent peut appeler. Ce que ces outils répondent ? Pas leur problème.

Le 16 avril, OpenAI a mis à jour son Agents SDK avec du tracing automatique — un système de logs qui enregistre chaque appel d'outil, handoff et événement guardrail. Ça observe les réponses. Ça ne les assainit pas. C'est comme installer une caméra de surveillance qui regarde quelqu'un entrer avec un couteau et le note consciencieusement sur un cahier.

Le 22 avril, Google a livré Agent Gateway à Cloud Next avec Model Armor, qui assainit effectivement les appels d'outils et les réponses — en filtrant les injections de prompts, les URLs malveillantes et les fuites de données. Google, il faut le reconnaître, est la seule grande plateforme qui protège explicitement le côté réponse. C'est en preview.

Pourquoi c'est grave : la porte est grande ouverte

La spécification MCP définit inputSchema — un format strict pour ce que tu envoies à un outil. Il n'y a pas d'outputSchema. Les réponses des outils sont du texte ou du JSON arbitraire qui coule sans filtre dans le raisonnement du modèle. La spec n'a littéralement pas de champ pour « valider ce qui revient ».

Cela crée trois vecteurs d'attaque qui devraient t'empêcher de dormir :

Injection de prompt indirecte — un outil retourne du contenu avec des instructions cachées. Le rapport PipeLab State of MCP Security 2026 (publié en avril 2026) documente un cas réel : un attaquant a forgé une issue GitHub malveillante pour que, quand un serveur MCP la récupérait, la réponse ordonne à l'agent d'exfiltrer le contenu de dépôts privés. « Les descriptions d'outils étaient propres. Le poison était dans les données retournées par l'outil. »

Context flooding — un outil renvoie tellement de données qu'il noie la mémoire de travail de l'agent, poussant les instructions critiques hors de la fenêtre de contexte.

Chaînes d'exfiltration de données — une réponse empoisonnée ordonne à l'agent de transférer du contexte sensible vers un autre outil. Le papier de recherche Log-To-Leak (publié en mars 2026) l'a démontré sur GPT-5, Claude Sonnet 4 et d'autres — avec un taux de réussite de 100% sur GPT-5 connecté à un serveur MCP PayPal, et 94,6% de précision dans la fuite de données.

Pendant ce temps, le 16 avril, OX Security a divulgué 11 CVEs affectant environ 200 000 instances de serveurs MCP. La réponse officielle d'Anthropic : l'assainissement est « la responsabilité du développeur ». Même le OWASP MCP Top 10 (publié en avril 2026) — la première tentative de l'industrie pour un cadre de sécurité MCP — n'a pas de catégorie dédiée aux réponses d'outils non validées. La faille est tellement normalisée que les gens qui rédigent les standards de sécurité ne l'ont même pas nommée.

Le prix de la correction

Ajouter la validation des réponses casse la simplicité qui a fait le succès de MCP. Les outils auraient besoin d'output schemas. Les agents auraient besoin d'une couche d'assainissement — quelque chose comme l'Agent Governance Toolkit de Microsoft (open-sourcé le 2 avril), qui inclut une gateway de sécurité MCP avec inspection des réponses. Chaque appel gagne en surcharge de parsing. L'expérience « tu branches et ça marche » meurt.

Mais l'alternative est pire.

Ce que ça veut dire pour toi

Tant que la validation côté réponse n'est pas déployée partout, chaque serveur MCP que tu connectes est un tuyau sans filtre vers le cerveau de ton agent. Tout le budget sécu que tu as claqué sur les contrôles d'entrée protège le mauvais bout de l'appel. Si tu fais tourner des agents en production aujourd'hui, il te faut soit le Model Armor de Google (preview), soit l'AGT de Microsoft, soit ton propre middleware d'assainissement des réponses. « Faire confiance à l'outil » n'est pas une politique de sécurité.

Tu as verrouillé la porte d'entrée. La porte de derrière n'a pas de serrure. Elle n'a même pas de porte.

Le prochain incident majeur de sécurité des agents ne viendra pas d'un mauvais appel d'outil. Il viendra de la réponse de l'outil.