Une vidéo de recette ne doit pas accéder à la carte bancaire

Une vidéo ne doit pas devenir un ordre de paiement

Je ne confierais pas à un agent une chaîne « il voit une recette, il achète les ingrédients » sans frontière stricte entre l’interprétation du contenu et l’exécution d’une transaction. Une vidéo, un article, une capture d’écran ou la réponse d’un outil externe sont des données non fiables : elles peuvent contenir une instruction que le modèle prendrait à tort pour la suite de sa tâche.

C’est pourquoi le scénario promotionnel évoqué, où l’on envoie une vidéo de recette à un agent qui paie ensuite par carte et organise la livraison, ressemble moins à une démonstration pratique qu’à une surface d’attaque prête à l’emploi. Le commentaire ne prouve pas à lui seul une compromission réelle ni l’existence de commandes sur un compte. Mais l’architecture décrite reste dangereuse, même sans cette preuve.

Les recommandations d’OpenAI sur la sécurité des agents et la spécification du modèle préconisent d’isoler les entrées non fiables, de les transmettre dans des champs structurés et de ne jamais les mélanger directement aux instructions du développeur. Une approbation humaine explicite est recommandée pour les actions d’outils, notamment celles qui impliquent des données financières. La system card de GPT-5 mentionne aussi des contrôles d’injection de prompts pour les appels d’outils et la navigation.

L’ampleur du problème apparaît également dans les benchmarks. StakeBench a couvert 3 168 exécutions attaquées d’agents web, sans qu’aucun objectif d’attaque ne soit bloqué de manière fiable. FinVault comprend 963 tests d’agents financiers intégrant injections de prompts, jailbreaks et exigences de conformité. En septembre 2026, il ne s’agit plus d’un cas limite exotique, mais d’une menace fondamentale pour les systèmes agentiques.

L’architecture devra limiter l’autonomie

La conclusion est simple : la sécurité ne peut pas être déléguée au modèle lui-même. Si le texte extrait d’une vidéo peut former directement les paramètres d’un achat, une seule injection réussie peut passer du contenu au circuit de paiement.

Je séparerais au minimum ce processus entre l’extraction de la liste, la validation selon un schéma fixe et une confirmation distincte de l’opération. L’outil doit disposer de droits restreints, les actions autorisées doivent être définies par énumérations, et le montant, l’adresse ainsi que le contenu de la commande ne doivent pas provenir discrètement du média. Toute modification du prompt ou du modèle exige de nouveaux tests adversariaux.

Cela réduit l’illusion d’une « autonomie totale », mais préserve l’essentiel : une vidéo peut proposer des données, sans obtenir le droit de dépenser avec une carte. Tant qu’un agent lit librement Internet et dépense sans confirmation, sa commodité reste une autre forme de vulnérabilité.

Nous avons déjà expliqué comment l’injection de prompts peut perturber l’automatisation par IA et pousser les agents vers des comportements dangereux. Cette même faiblesse devient particulièrement coûteuse lorsqu’un agent peut suivre des instructions vidéo et effectuer des achats.