Si tu as écrit du PHP assez longtemps, tu portes une cicatrice : le jour où tu as compris ce que fait unserialize() quand l'attaquant contrôle la chaîne. Chaînes POP, astuces phar, blobs de session qui se transformaient en shells — on a passé des années à apprendre qu'une valeur stockée reste une entrée utilisateur, peu importe le nombre de couches qu'elle a traversées avant d'arriver sur le disque. Si j'en parle, c'est parce que l'écosystème des agents IA est en train de repasser cet examen, question par question, et donne en grande partie les mêmes mauvaises réponses que nous. C'est ma thèse : l'histoire de la sécurité autour des frameworks d'agents en 2026 n'est pas une nouvelle discipline. C'est la nôtre, l'ancienne, et les développeurs PHP sont particulièrement bien armés pour l'appliquer.

L'occasion, c'est Black Hat 2026. Yarden Porat et Shahar Tal de Check Point Research ont passé un an à attaquer les frameworks sur lesquels tout le monde construit ses agents — LangChain, LangGraph, CrewAI, AutoGen, l'Agent Framework de Microsoft, l'ADK de Google — et en sont repartis avec onze vulnérabilités ; The Register a relayé l'affaire cette semaine. L'analyse rapportée de Tal mérite d'être citée précisément : tu dois partir du principe que les agents liront du contenu hostile, et le vrai échec, c'est quand ce contenu finit par piloter la machinerie de confiance — orchestration, mémoire, instructions système. Il a ajouté qu'un agent n'a même pas besoin d'avoir des outils dangereux activés pour être retourné contre toi ; ingérer le mauvais document peut suffire. Regarde bien ce que fait cet argument : il sort le bug du modèle et le place dans le code du framework. C'est-à-dire chez nous.

Prends la découverte sur l'Agent Framework de Microsoft. Les agents persistent des checkpoints — des instantanés de leur état pour qu'une tâche puisse reprendre après une panne. Check Point a montré qu'un payload pouvait voyager dans un message, se retrouver figé dans ce checkpoint, puis s'exécuter quand un autre utilisateur reprenait la session plus tard, parce que le framework considérait son propre état stocké comme intrinsèquement propre. Résultat : un accès distant au serveur, une prime de 10 000 $, un correctif, et pas de CVE puisque le framework n'était pas encore en disponibilité générale. Maintenant fais un rechercher-remplacer : appelle le checkpoint un blob de session sérialisé et c'est une trouvaille que n'importe quelle revue de sécurité PHP aurait entourée en rouge avant que le café ait refroidi. On a littéralement du folklore de conférences sur exactement cet échec.

L'entrée de l'ADK de Google dans la liste est un autre classique. Le kit embarque un assistant de code intégré destiné à l'équipe de développement — et dans un déploiement standard, il répond à tout l'internet ouvert, sans la moindre authentification. De là, un attaquant pouvait lui faire écrire un fichier qui s'exécute automatiquement, le lancer, puis pivoter vers les identifiants d'environnement et le compte de service que la machine utilise pour parler au reste de Google Cloud. Google a d'abord refusé de le traiter comme un bug, puis a payé 3 133,70 $ et livré un correctif partiel. Toutes les équipes PHP que je connais ont un item de checklist de déploiement qui existe uniquement parce que quelqu'un a un jour laissé une debug toolbar, un .env exposé ou un port Xdebug grand ouvert sur un hôte de production. La leçon n'était pas spécifique à PHP. Apparemment, elle n'a pas non plus été retenue hors de chez nous.

Et le lot de Black Hat n'est pas une anomalie. En juin, la même équipe de Check Point a publié une chaîne contre LangGraph — une bibliothèque à environ 46,5 millions de téléchargements mensuels — qui commence par une injection SQL dans get_state_history() et finit en exécution de code à distance. Une injection SQL. En 2026. Le bug que les requêtes préparées et une décennie d'évangélisation autour de PDO étaient censées avoir éradiqué. En mai, Microsoft lui-même a documenté deux failles critiques dans Semantic Kernel où un seul prompt suffisait à faire apparaître calc.exe sur la machine hôte. Côté MCP, une chaîne de trois vulnérabilités critiques dans le mcp-server-git officiel d'Anthropic permettait l'exécution de code à distance, et les scans de serveurs MCP publics continuent de révéler du path traversal et du tool poisoning — des descriptions d'outils manipulées pour que le modèle se comporte autrement que ne le voulait son opérateur.

Laisse-moi concéder l'objection la plus solide, parce qu'elle est réelle : les LLM ajoutent effectivement quelque chose de vraiment nouveau. Il n'existe pas de htmlspecialchars() pour le langage naturel. Tu ne peux pas paramétrer un prompt comme tu paramètres une requête, et l'injection de prompt est peut-être tout simplement insoluble au niveau du modèle. D'accord. Mais regarde où les dégâts ont réellement atterri dans chacun des cas ci-dessus : une requête assemblée par concaténation de chaînes, un blob stocké exécuté sur parole, un endpoint que personne n'a pris la peine d'authentifier, un processus tournant avec des identifiants dont il n'avait jamais eu besoin. Le modèle était le messager ; c'est du code déterministe qui a fait le mal. Et le code déterministe, c'est un territoire où on sait gagner. Tu ne peux pas assainir la prose d'un attaquant — tu peux absolument refuser de faire un exec() parce qu'une chaîne ressuscitée l'a demandé poliment.

Ça nous concerne concrètement, parce que les agents débarquent dans les boîtes PHP en ce moment même : des serveurs MCP écrits en PHP, des workers de queue Laravel qui appellent des API d'agents, des backends Symfony qui persistent l'état de conversation à côté des données clients. Alors applique les réflexes qu'on possède déjà. Tout ce qu'un agent stocke et relit plus tard, c'est du $_POST avec un délai — valide à la sortie du stockage, pas seulement à l'entrée. Fais tourner chaque outil que l'agent peut invoquer avec le moindre privilège que tu accorderais à un cron que tu n'as pas écrit toi-même. Authentifie les endpoints même quand ils sont « juste pour l'équipe ». Et si tu es sur Psalm, son analyse de taint a été conçue exactement pour cette forme de problème : tracer une entrée non fiable jusqu'à un sink dangereux à travers du code qui a l'air innocent au milieu.

Deux chercheurs, douze mois, onze vulnérabilités dans les frameworks d'agents les plus populaires de la planète — ce ratio te dit à quel point cette couche a été peu scrutée, et combien de fruits mûrs restent à portée de main. La communauté PHP a traversé sa propre décennie de durcissement et en est sortie avec des instincts qui valent la peine d'être exportés ; c'est le moment d'être les adultes dans la pièce, pas les sceptiques dans le coin. Alors voilà ce que je veux vraiment savoir de toi : où traces-tu la frontière de confiance dans tes propres intégrations d'agents ? Quand une sortie ou un état revient d'un agent que tu as déployé, est-ce que tu le valides comme un formulaire soumis par un inconnu — ou est-ce que, honnêtement, tu le traites encore comme de l'interne ?