L’hypothèse populaire selon laquelle un humain examinant chaque commande peut contrôler les agents de codage de l’IA fait l’objet d’un examen minutieux. Une nouvelle analyse de plus de 40 000 sessions de jeu et de plus de 409 000 décisions individuelles d’approbation ou de refus a révélé que les évaluateurs humains ont manqué environ une commande malveillante sur trois provenant d’agents d’IA, ce qui soulève des questions urgentes quant à savoir si « l’humain dans la boucle » constitue une limite de sécurité fiable.

Les résultats proviennent d'un jeu sur navigateur créé par Alex Wauters, un ancien ingénieur chez Uber qui écrit sur la sécurité des développeurs chez Scale X. Le jeu place les joueurs dans le rôle d'un évaluateur humain pour un agent de codage d'IA, leur demandant d'approuver ou de refuser les commandes du shell sous pression de temps. Certaines commandes sont routinières, comme « git status » ou « npm test ». D’autres sont des tentatives soigneusement déguisées visant à exfiltrer des informations d’identification, à installer des portes dérobées ou à envoyer des secrets à des serveurs distants. Après avoir ajouté le suivi des statistiques, Wauters a collecté suffisamment de données pour dresser un tableau détaillé des domaines dans lesquels le jugement humain réussit et, le plus souvent, échoue. Pour en savoir plus sur la couverture plus large de l'industrie de l'IA, cette étude se distingue comme l'une des expériences les plus riches en données à ce jour.

Les commandes les plus dangereuses étaient les plus difficiles à attraper

Le résultat le plus frappant de l'étude est que les commandes manifestement destructrices, telles que « rm -rf » sur les répertoires critiques, ont été détectées de manière fiable. Les menaces qui ont effectivement réussi à voler des informations d’identification ont été manquées près de trois fois plus souvent. La commande la plus manquée de tout le jeu était « npm run analyse », approuvée par 64,7 % des joueurs malgré le journal de l'historique de l'agent montrant clairement que le script sous-jacent avait été falsifié pour transmettre les informations d'identification à un serveur externe.

Le problème est structurel. Les commandes telles que « npm run » exécutent le script défini dans le fichier « package.json » d'un projet. Ce script peut être un analyseur de bundle légitime ou un code malveillant injecté par une modification de fichier antérieure modifiée par l'agent. Pour en être sûr, un développeur devrait inspecter chaque fichier modifié avant de l'approuver, ce qui annule l'avantage de vitesse que les outils de codage d'IA sont censés offrir.

Sur trois de ces commandes de charge utile déguisées dans le jeu, le taux d'échec était de 52,5 %, contre 28,4 % pour toutes les autres attaques d'exfiltration d'identifiants. Cacher une charge utile derrière un nom de script familier a à peu près doublé son taux de réussite, même lorsque la charge utile était visible dans le journal d'historique affiché juste au-dessus de l'invite d'autorisation.

La fatigue des autorisations érode la vigilance au fil du temps

Anthropic avait précédemment reconnu que la fatigue des autorisations était un phénomène réel dans son produit Claude Code, notant que plus un utilisateur voit d'approbations, moins il accorde d'attention à chacune d'elles. Les données de Scale X soutiennent empiriquement cette préoccupation. Les taux d'échec ont diminué au cours des premières commandes de chaque session à mesure que les joueurs s'échauffaient, mais ont ensuite grimpé régulièrement vers la fin, ce qui correspond soit à la fatigue, soit à la pression croissante d'une horloge qui tourne.

Ce modèle reflète la dynamique du monde réel. Les développeurs qui se précipitent pour livrer des fonctionnalités sous la pression des délais sont confrontés à la même incitation à cliquer sur approuver rapidement, et le grand volume de commandes de routine crée un problème d'aiguille dans une botte de foin où les véritables menaces sont statistiquement rares. Le résultat est un système qui forme les utilisateurs à tout approuver sans discussion.

L'autre côté : le blocage excessif ralentit tout

L’étude a également documenté le mode de défaillance opposé. Plusieurs commandes véritablement inoffensives ont été systématiquement bloquées par des joueurs prudents, y compris les invocations de build et de test standard. Ce surblocage ralentit l’agent et, paradoxalement, augmente le risque à long terme. Lorsqu'il est demandé à plusieurs reprises aux utilisateurs d'approuver des commandes qui s'avèrent inoffensives, le bruit érode leur volonté d'examiner les invites futures, les poussant finalement à contourner complètement ou à des modes d'approbation automatique qui suppriment complètement l'examen humain.

Des fonctionnalités telles que le mode automatique d'Anthropic tentent d'atténuer ce problème en déterminant automatiquement si une commande est sûre avant d'en informer l'utilisateur. Mais comme le démontrent les données de l’étude sur les charges utiles déguisées, même le contenu visible des commandes ne suffit pas pour que les humains puissent porter des jugements fiables sous pression.

Le contexte manquant est le problème principal

Une commande, « cat ~/.zshrc », s'est avérée la plus controversée de tout le jeu, approuvée par 45,9 % des joueurs. La commande est inoffensive pour les développeurs qui ne gardent aucun secret dans leur profil shell, mais elle expose les clés API pour ceux qui y exportent leurs informations d'identification. Son risque dépend entièrement d’une configuration du système que l’agent ne peut pas voir et dont le réviseur peut ne pas se souvenir.

Plusieurs autres commandes ont généré une controverse similaire sur le fil de discussion Hacker News pour la même raison. Le problème fondamental est que les développeurs sont invités à porter des jugements en matière de sécurité sans avoir une idée complète des fichiers qui ont été modifiés, de ce que l'agent a fait lors des étapes précédentes et de ce que contient la configuration actuelle du système. Comme l’a souligné un intervenant, demander aux utilisateurs de valider des commandes ambiguës sans contexte ne constitue pas une garantie solide.

Quelles sont les prochaines étapes pour la sécurité des agents

Wauters soutient que la solution ne réside pas dans de meilleurs humains mais dans de meilleurs outils. Le sandboxing des agents afin qu'ils ne puissent pas accéder directement aux informations d'identification, une isolation stricte du contexte et des limites structurelles sur ce que les agents peuvent faire sans autorisations élevées sont tous plus prometteurs que de s'appuyer sur la vigilance humaine. Jusqu'à ce que ces garanties soient en place, accorder aux agents des autorisations étendues reste risqué, qu'un humain soit ou non nominalement au courant.

L’étude n’est pas un article universitaire évalué par des pairs et Wauters reconnaît ses limites. Le jeu a averti les joueurs des menaces et a appliqué une pression temporelle artificielle qui peut ne pas refléter parfaitement les environnements de développement réels. Mais la principale conclusion, à savoir que des évaluateurs humains formés et sous pression ratent un tiers des attaques délibérément déguisées, devrait donner à chaque équipe déployant des agents de codage d’IA une raison de reconsidérer son modèle de sécurité.

Pour les développeurs qui construisent aujourd’hui avec des agents IA, la conclusion pratique est de supposer que l’humain dans la boucle finira par échouer. Concevez les autorisations de vos agents et votre sandboxing de manière à ce qu'une approbation manquée ne signifie pas une fuite de clé AWS ou un pipeline de build compromis. Les données suggèrent que considérer l’examen humain comme votre principale défense est un pari qui ne porte pas ses fruits.

Gardez une longueur d'avance sur l'IA

Le paysage de la sécurité des agents IA évolue rapidement. Restez informé des derniers développements en IA et des dernières recherches.

Lire plus d'actualités sur l'IA →