~4 minutes
Le mode YOLO (“You Only Live Once”) d’un agent IA désactive la validation humaine avant chaque action : plus de “voulez-vous vraiment exécuter cette commande ?”, l’agent enchaîne tout seul. Pratique pour itérer vite en dev, redoutable dès qu’il tourne contre un système qui compte. Voici ce que c’est, pourquoi ça part mal, et comment le pratiquer sans finir en brèche.
Je vois de plus en plus d’agents (Hermes, Claude Code, Cursor, des Agents-trucs maisons) proposer un mode qui saute la confirmation humaine avant chaque commande. Le nom varie, “YOLO mode”, “auto-approve”, “–dangerously-skip-permissions”, mais le principe est identique : l’agent décide et exécute, sans attendre votre feu vert. Je le rappelle ici parce que on vient encore d’avoir un attaquant qui a utilisé un agent en mode YOLO de manière tres marrante, et que la documentation officielle de l’outil prévenait pourtant clairement : “only use this in trusted, sandboxed environments”.
Note du PandaRedacteur : Le mode YOLO n’est pas un bug de sécurité. C’est une fonctionnalité(ca me rappelle qqn ca…), avec un avertissement dessus. Le problème n’est jamais l’existence du mode, mais l’endroit où on l’active.
Ce que fait réellement le mode YOLO
Concrètement, un agent en mode YOLO garde toutes ses capacités (accès fichiers, exécution de commandes, appels réseau, écriture) mais retire la boucle de confirmation qui s’intercale normalement entre “je propose cette action” et “je l’exécute”. C’est cette boucle qui, en fonctionnement normal, laisse un humain repérer une commande destructrice, un chemin de fichier suspect, ou une action qui sort du périmètre attendu.
Sans elle, l’agent avance à la vitesse de son propre raisonnement, pas à celle de votre lecture. Et un agent qui hallucine une commande rm -rf sur le mauvais répertoire, ou qui suit une instruction injectée dans un fichier qu’il vient de lire, l’exécute aussi vite qu’une commande légitime. Rien ne distingue les deux à ses yeux.
flowchart LR
A["Agent propose une action"] --> B{"Mode YOLO actif ?"}
B -->|Non| C["Validation humaine"]
C --> D["Exécution"]
B -->|Oui| D
Pourquoi c’est risqué en dehors d’un bac à sable
On peut évoquer ces raisons au mimnimun :
-
L’agent ne fait pas la différence entre une instruction de son opérateur et une instruction glissée dans les données qu’il traite (un fichier, une page web, une réponse d’API). C’est le cœur du prompt injection, et le mode YOLO retire le dernier filet de sécurité contre ce vecteur.
-
Un agent en YOLO agit à un rythme et un volume qu’aucune détection calibrée sur un comportement humain n’anticipe correctement. C’est exactement ce qui a permis à l’attaquant thaïlandais, de faire tourner LinPEAS et de scanner des CVE noyau sans déclencher d’alerte avant qu’il ne soit trop tard.
Et sans confirmation, il n’y a plus de point d’arrêt naturel entre une erreur de raisonnement de l’agent et sa conséquence réelle sur le système. L’erreur devient l’action.
Pratiquer le YOLO sans se faire piéger
Si vous avez une vraie raison d’utiliser un mode sans confirmation (itération rapide en développement, démonstration contrôlée, benchmark), voici ce qu’il faut vérifier avant d’accepter de l’activer :
- Isolation réseau réelle
- Aucun credential à portée large
- Système de fichiers jetable
- Journalisation complète de chaque action
- Alerte sur le volume et la cadence d’actions
- Durée de vie limitée du mode
- Jamais contre un système de production
Note du PandaRedacteur : si votre bac à sable “de confiance” a une route vers votre VPC de prod, ce n’est pas un bac à sable, c’est un tapis rouge.