When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

Dans le monde moderne de la création de logiciels, un nouveau genre d'assistant est apparu : l'agent de codage. Ce sont des programmes d'intelligence artificielle capables d'écrire du code, de corriger des bugs et de gérer des fichiers, tout comme le ferait un développeur humain. Pour garder ces assistants numériques en sécurité et sur la bonne voie, les développeurs leur écrivent des fichiers d'instructions. Considérez ces fichiers comme un ensemble de règles écrites, comme une recette ou un code de conduite, où un humain indique à l'agent ce qu'il est autorisé à faire et ce qu'il ne doit jamais faire. Un développeur pourrait écrire : « Ne jamais enregistrer de mots de passe en texte clair », ou « Demander avant de supprimer des données importantes ». Pendant des années, cette méthode de donner des instructions a été la norme pour guider ces outils intelligents. L'hypothèse était que si vous écrivez une règle clairement, l'agent la comprendra et la suivra, créant ainsi un environnement sûr pour le logiciel en cours de construction.

Cependant, une étude récente menée par la chercheuse Ting Yan révèle une lacune discrète mais significative dans ce système. La recherche se concentre sur un type spécifique de fichier d'instructions utilisé avec un agent de codage populaire appelé Claude Code. L'étude pose une question simple mais critique : lorsqu'un développeur écrit une règle de sécurité en anglais courant, le logiciel possède-t-il réellement un mécanisme intégré pour appliquer cette règle, ou la règle n'est-elle qu'une suggestion que l'intelligence artificielle doit essayer de comprendre ? Les conclusions suggèrent que, pour la grande majorité de ces règles écrites, la réponse est la seconde option. Le fichier agit comme une rue à sens unique où le développeur parle, mais le système ne confirme jamais si la règle est appliquée. Cela crée un faux sentiment de sécurité, où un développeur croit qu'une action dangereuse est bloquée, alors qu'en réalité, le système compte uniquement sur l'intelligence artificielle pour se souvenir de l'instruction et l'obéir, sans qu'aucun arrêt brutal ne soit en place.

Pour comprendre l'ampleur de ce problème, les chercheurs ont rassemblé près de cinq cents fichiers d'instructions publics provenant de développeurs du monde entier. Ils ont traité ces fichiers comme une collection de notes manuscrites, les parcourant ligne par ligne pour trouver des phrases qui ressemblaient à des règles de sécurité. Ils ont recherché des expressions telles que « ne doit pas », « jamais » ou « ne pas », qui signalent une restriction. À partir de ces fichiers, ils ont extrait des milliers de règles candidates. L'étape suivante consistait à agir comme un traducteur entre le langage humain de la règle et le langage technique du logiciel. Ils ont cherché à savoir si l'agent de codage spécifique, Claude Code, possédait déjà un interrupteur ou un paramètre intégré capable de bloquer automatiquement l'action décrite dans la règle. Par exemple, si une règle disait « ne pas exécuter cette commande spécifique », les chercheurs ont vérifié si le logiciel disposait d'un paramètre de permission pouvant simplement refuser cette commande avant même qu'elle ne se produise. Si le logiciel n'avait pas un tel interrupteur, la règle était laissée à l'interprétation de l'intelligence artificielle, ce qui signifie que l'agent devait décider de lui-même s'il devait suivre l'instruction.

Les résultats de cette comparaison ont été frappants. Lorsque les chercheurs ont appliqué une norme stricte — exigeant que le contrôle intégré couvre l'action exacte, la cible exacte et la condition exacte de la règle écrite — seule une infime fraction des règles possédait un mécanisme de sécurité correspondant. Plus précisément, ils ont découvert qu'environ quatre à six pour cent des règles de sécurité écrites par les développeurs étaient soutenues par un contrôle intégré capable de les appliquer sans travail supplémentaire. Même en utilisant une norme plus souple, permettant des correspondances partielles, le chiffre n'est monté qu'à environ seize pour cent. Cela signifie que pour environ quatre-vingt-quinze pour cent des règles de sécurité écrites dans ces fichiers, il n'y avait aucun filet de sécurité automatique. La règle n'existait que sous forme de texte, reposant entièrement sur l'intelligence artificielle pour l'interpréter correctement à chaque fois.

L'étude a également examiné pourquoi tant de règles manquaient de correspondance. Les chercheurs ont constaté que les règles demandaient souvent des choses que les outils intégrés du logiciel ne pouvaient tout simplement pas voir ou faire. Une règle pourrait dire : « Ne jamais enregistrer de secrets dans le code », mais les paramètres de permission du logiciel peuvent bloquer un chemin de fichier ou une commande, pas le contenu réel à l'intérieur d'un fichier. Pour appliquer une règle sur les secrets, le logiciel devrait lire le fichier et comprendre ce qu'il contient, ce qu'il ne peut pas faire avec ses paramètres standards. De même, une règle pourrait exiger la vérification de l'état d'un système ou l'approbation d'une personne spécifique, des détails auxquels les contrôles intégrés ne pourraient pas accéder. Dans ces cas, la règle n'était pas une commande que le logiciel pouvait exécuter ; c'était une requête demandant à l'intelligence artificielle d'utiliser son jugement. Les chercheurs ont noté que cette distinction est invisible pour le développeur. Le fichier d'instructions ressemble à la même chose, qu'une règle soit appliquée par un verrou système rigide ou par la mémoire molle et faillible d'une intelligence artificielle.

Ce manque de retour crée ce que les chercheurs appellent un canal « d'écriture seule ». Dans la plupart des développements de logiciels, lorsqu'un développeur écrit une règle, il reçoit un retour immédiat. S'il écrit un code qui enfreint une règle, l'ordinateur peut refuser de l'exécuter, ou un test peut échouer, lui indiquant immédiatement qu'un problème est survenu. Avec ces fichiers d'instructions, il n'y a pas de tel signal. Un développeur peut écrire une règle, passer à la suite, et ne jamais savoir si l'agent la suit réellement. L'étude souligne que cela est particulièrement risqué pour les développeurs novices en sécurité. Ils pourraient écrire une règle pensant avoir sécurisé leur système, sans réaliser que le système n'a aucun moyen d'appliquer réellement cette restriction spécifique. L'intelligence artificielle peut suivre la règle la plupart du temps, mais elle peut aussi faire des erreurs, s'embrouiller ou être trompée par d'autres entrées, laissant le système vulnérable.

Les chercheurs n'ont pas trouvé que le logiciel était défectueux ou que les développeurs faisaient quelque chose de mal. Au lieu de cela, ils ont identifié un défaut de conception dans la manière dont ces outils communiquent avec leurs utilisateurs. Les outils permettent aux utilisateurs d'écrire des règles en langage naturel, ce qui est facile et intuitif, mais ils ne disent pas à l'utilisateur lesquelles de ces règles sont réellement appliquées par le système et lesquelles ne sont que des suggestions. L'étude suggère que pour que ces outils soient véritablement sûrs, ils doivent fermer cette boucle. Ils doivent donner aux développeurs un moyen de voir quelles règles sont soutenues par des contrôles rigides et lesquelles ne le sont pas. Idéalement, le logiciel devrait avertir un développeur si celui-ci écrit une règle que le système ne peut pas appliquer, ou il devrait l'aider à transformer cette règle en un paramètre que le système peut réellement utiliser. Tant que cette boucle de rétroaction n'est pas fermée, la sécurité de ces systèmes dépendra fortement de l'espoir que l'intelligence artificielle se souvienne et obéisse parfaitement à chaque instruction, un espoir que les données montrent est souvent mal placé.

L'étude conclut en soulignant que ce problème est soluble, mais qu'il nécessite un changement dans la manière dont ces outils sont construits. L'écart entre ce qu'un développeur écrit et ce que le système applique n'est pas un mystère ; c'est un fait mesurable. En le mesurant, les chercheurs ont montré que la manière actuelle de sécuriser ces agents est incomplète. La solution réside dans le fait de rendre l'invisible visible, en s'assurant que lorsqu'un développeur écrit une règle, il sait exactement quel type de protection elle apporte. Cela transformerait le fichier d'instructions d'une note à sens unique en une conversation à double sens, où le système confirme que les règles ne sont pas seulement écrites, mais qu'elles fonctionnent réellement.