Show HN : Continue? Y/N : un jeu de 60 secondes sur la fatigue liée aux autorisations des agents IA

• Continue? Y/N est une expérimentation qui transforme la fatigue liée aux autorisations des LLM en un jeu de 60 secondes, et teste à quel point on lit attentivement les commandes de l’IA
• Il ne reste plus qu’1 minute avant la prochaine réunion, et Claude Code demande l’approbation de commandes pour terminer un refactoring
• L’utilisateur doit en traiter un maximum dans le temps imparti, en lisant chaque commande puis en approuvant avec 1 ou en la refusant avec 2
• La difficulté centrale consiste à rester concentré même dans un flux épuisant de demandes d’approbation répétées, au point d’en avoir les yeux qui se brouillent
• La règle est d’en traiter le plus possible en 60 secondes, tout en lisant soigneusement chaque commande pour décider de l’approuver ou non

[GN⁺]

Avis sur Hacker News

• Vraiment amusant

  En ce moment, on peut « tricher » en refusant toutes les requêtes le plus vite possible. On reçoit alors le badge security-conscious engineer, et on obtient aussi le score maximal au nombre de requêtes traitées. Une alerte « overblock » s’affiche bien, mais elle est cachée en bas, et l’écran donne quand même l’impression qu’on a gagné

  J’ai aussi essayé l’approche hustle4lyfe, en approuvant un maximum de requêtes le plus vite possible comme un ingénieur qui « move fast and break things », mais ça finit par être plus lent à cause des pop-ups malicious command. Mesquin

  • Bien vu, et cette stratégie a maintenant été nerfée, avec un titre séparé en plus
  • Exactement comme dans la vraie vie. Si on refuse tout et qu’on empêche quoi que ce soit de se faire, c’est sûr :)

• Jeu amusant, mais il montre aussi un manque d’hygiène de sécurité du côté des créateurs. Il disait que cat ~/.zshrc était risqué parce que cela partagerait des tokens et des secrets, mais moi je ne mets jamais de secrets dans mon fichier de configuration du shell

  • Beaucoup de gens le font. Cela dit, ces valeurs seraient alors dans les variables d’environnement, et Claude y aurait probablement déjà accès
  • Je ne le fais pas personnellement, mais je peux tout à fait croire que beaucoup de gens le fassent
  • Mettre des secrets dans un LLM n’est pas intrinsèquement dangereux en soi, c’est juste l’un des trois ingrédients fatals
  • Le simple fait d’avoir dès le départ des « tokens et secrets » relève déjà d’une mauvaise hygiène de sécurité
  • Et alors, tu les mettrais où ?

• Je trouve étrange de considérer la lecture de zshrc comme risquée. Je mets volontiers le mien dans mon dépôt dotfiles public ; qui irait mettre des clés API là-dedans ? À l’inverse, on dirait que ce genre d’outils IA n’arrête pas d’y ajouter le PATH, donc j’ai l’impression qu’il y a dans le secteur de l’IA un malentendu fondamental sur les bonnes pratiques shell

  En plus, faire un kill à partir de la sortie de lsof n’est pas sûr. Par exemple, si Firefox a une page web ouverte, ou si l’agent lui-même contient un sous-shell client, alors Firefox et l’agent sautent tous les deux

  • Oui. Le jeu semble supposer que si Claude a dit que c’était sûr, alors exécuter kill l’est aussi. Mais le point essentiel, c’est qu’il ne faut pas faire confiance à Claude

• Sympa. J’ai juste une petite réserve

  npm config set registry [https://npm.internal](<https://npm.internal>;)

  Le jeu disait que c’était une commande pour pointer npm vers un miroir de registre interne de l’entreprise, puisque la documentation d’onboarding l’exige, et l’a jugée sûre. J’ai hésité, puis j’ai fini par la refuser

  Si ce README concerne un dépôt public ou un fork, et que ce https://npm.internal est en réalité https://npm.internal.somethinganexternaldnscanresolve.tld, ça peut très vite tourner au désastre

  Dans 99 % des cas, un miroir comme Artifactory / Nexus sera déjà configuré par la politique de l’entreprise. Si un README te dit d’utiliser une autre URL de gestionnaire de paquets, c’est un énorme signal d’alarme, et il ne reste que quelques secondes avant l’incident

  • Bonne remarque. .internal est un domaine de premier niveau réservé et ne devrait pas être résolu publiquement, mais tu as raison : il faut être prudent quand on modifie des valeurs qui doivent être configurées séparément pendant qu’on laisse Claude refactoriser le projet. Je vais déplacer ça vers la catégorie modification permanente

• Petit jeu amusant, mais j’ai l’impression que les questions sautent trop de contexte pour bien représenter une situation réelle. Il vaudrait mieux les regrouper en « packs » pour leur donner une structure plus réaliste

  Par exemple, voir passer beaucoup de demandes d’autorisation pour modifier un fichier something.js, puis tomber sur npm publish, c’est bien plus naturel et bien plus dangereux. Si ça surgit soudainement alors qu’on appuie sur Y en continu, on se fait avoir beaucoup plus facilement

• Environ les trois quarts des choix « mauvais » sont des choses dont je me soucierais peu même en cas de fuite, et pour lesquelles mon employeur ne me sanctionnerait probablement pas, même si cela menait à un incident de production

• La validation des permissions tue énormément la productivité. Si on veut faire tourner Claude, il me semble plus efficace de l’exécuter dans un sandbox jetable, ou sous forme de conteneur Docker n’ayant que les permissions qu’on accepte sur sa machine perso

  [1] - https://exe.dev/ est un nouveau fournisseur cloud qui propose une expérience utilisateur d’agent plutôt utile

  [2] - J’ai créé https://github.com/stanislavkozlovski/dclaude/ pour cet usage. Ce n’est pas parfait, mais quand j’ai rarement besoin de faire tourner un agent de code en local, ça fait le travail

  • Un sandbox jetable n’empêche pas l’exfiltration de secrets. Si tu ne considères pas le code comme secret, tu peux créer un sandbox totalement sans secrets, mais dans ce cas les types de tâches confiables à un agent deviennent très limités

• À l’écran de score final, j’aimerais aussi voir l’explication du LLM pour les commandes qu’il ne fallait pas approuver. Si j’ai approuvé la commande rm -rf Projects, c’est parce que j’ai cru que le LLM expliquait correctement qu’elle supprimerait tout dans le dossier Projects

  J’ai clairement mal lu en répondant trop vite aux prompts, et je savais pourtant ce que faisait la commande, donc j’ai sans doute halluciné le fait que l’IA l’ait expliqué. Mais j’aimerais quand même voir ce que j’ai mal lu

  Après avoir joué à ce jeu, je suis vraiment content de ne pas être agentmaxx

• J’ai choisi « approve » pour ls -la ~/Documents et c’était considéré comme faux, mais je ne vois pas en quoi le simple fait de lister le dossier Documents pose un problème de sécurité. Ce ne sont que des noms de fichiers. Si on allait jusqu’à lire leur contenu, là peut-être...