L'impératif sans secret : pourquoi les modèles de sécurité traditionnels sont mis à mal lorsque des agents d'IA interagissent avec le code

En avril 2023, Samsung a découvert que ses ingénieurs avaient divulgué des informations sensibles à ChatGPT.Mais c'était un accident. Imaginez maintenant si ces dépôts de code avaient contenu des instructions délibérément implantées, invisibles pour les humains mais traitées par une IA, conçues pour extraire non seulement du code, mais aussi chaque clé API, identifiant de base de données et jeton de service auquel l'IA pouvait accéder. Ce n'est pas une hypothèse. Des chercheurs en sécurité l'ont déjà démontré Ces attaques par « instructions invisibles » fonctionnent. La question n'est pas de savoir si cela se produira, mais quand.

La frontière qui n'existe plus

Pendant des décennies, nous avons bâti notre sécurité sur un postulat fondamental : le code est du code, et les données sont des données. Les injections SQL nous ont appris à paramétrer les requêtes. Les attaques XSS (Cross-Site Scripting) nous ont appris à échapper les sorties. Nous avons appris à ériger des barrières entre ce que font les programmes et ce que les utilisateurs saisissent.

Avec les agents d'IA, cette frontière a disparu.

Contrairement aux logiciels déterministes qui suivent des chemins prévisibles, les modèles de langage étendus sont des boîtes noires probabilistes incapables de distinguer les instructions légitimes des développeurs des entrées malveillantes. Lorsqu'un attaquant soumet une requête à un assistant de programmation IA, il ne se contente pas de fournir des données ; il reprogramme l'application en temps réel. L'entrée devient alors le programme lui-même.

Cela représente une rupture fondamentale avec tout ce que nous savons en matière de sécurité des applications. Les pare-feu traditionnels basés sur la syntaxe, qui recherchent des schémas malveillants comme DROP TABLE ou tags, fail completely against natural language attacks. Researchers have demonstrated “semantic substitution” techniques where replacing “API keys” with “apples” in prompts allows attackers to bypass filters entirely. How do you firewall intent when it’s disguised as harmless conversation?

La réalité du zéro clic dont personne ne parle

Voici ce que la plupart des équipes de sécurité ignorent : l’injection de messages explicites ne nécessite aucune intervention de l’utilisateur. Il s’agit souvent d’exploits qui s’exécutent sans clic. Un agent d’IA, se contentant d’analyser un dépôt de code pour une tâche routinière, d’examiner une demande de fusion ou de consulter la documentation d’une API, peut déclencher une attaque sans aucune interaction humaine.

Considérons ce scénario, basé sur des techniques que les chercheurs ont déjà prouvéesUn acteur malveillant a intégré des instructions invisibles dans les commentaires HTML de la documentation d'une bibliothèque open source populaire. Tout assistant d'IA analysant ce code, qu'il s'agisse de GitHub Copilot, d'Amazon CodeWhisperer ou de tout autre outil d'aide au développement d'entreprise, devient un collecteur potentiel d'identifiants. Une seule bibliothèque compromise peut exposer des milliers d'environnements de développement.

Le danger ne réside pas dans le modèle LLM lui-même, mais dans le pouvoir que nous lui conférons. Dès l'instant où nous avons intégré ces modèles à des outils et des API, leur permettant d'extraire des données, d'exécuter du code et d'accéder à des secrets, nous avons transformé des assistants utiles en vecteurs d'attaque parfaits. Le risque ne dépend pas de l'intelligence du modèle, mais de sa connectivité.

Pourquoi l'approche actuelle est vouée à l'échec

L'industrie est actuellement obsédée par l'« alignement » des modèles et la mise en place de pare-feu plus performants. OpenAI renforce ces garde-fous. Anthropic se concentre sur l'IA constitutionnelle. Tous cherchent à créer des modèles infaillibles.

C'est une bataille perdue d'avance.

Si une IA est suffisamment intelligente pour être utile, elle l'est aussi pour être trompée. Nous tombons dans ce que j'appelle le « piège de la désinfection » : croire qu'un meilleur filtrage des entrées nous sauvera. Or, les attaques peuvent se dissimuler sous forme de texte invisible dans les commentaires HTML, être enfouies profondément dans la documentation ou encore être encodées de manières que nous n'avons pas encore imaginées. On ne peut pas désinfecter ce que l'on ne comprend pas contextuellement, et c'est précisément le contexte qui fait la puissance des LLM.

L'industrie doit se rendre à l'évidence : l'injection rapide sera un succès. La question est de savoir ce qui se passera ensuite.

Le changement architectural dont nous avons besoin

Nous sommes actuellement en pleine phase de correctifs, ajoutant frénétiquement des filtres d'entrée et des règles de validation. Mais tout comme nous avons fini par comprendre que la prévention des injections SQL nécessitait des requêtes paramétrées et non un meilleur échappement des chaînes, nous avons besoin d'une solution architecturale pour la sécurité de l'IA.

La réponse réside dans un principe qui paraît simple mais qui nécessite de repenser la manière dont nous construisons nos systèmes : les agents d’IA ne devraient jamais posséder les secrets qu’ils utilisent.

Il ne s'agit pas d'une meilleure gestion des identifiants ni de solutions de coffre-fort numériques améliorées. Il s'agit de considérer les agents d'IA comme des entités uniques et vérifiables, et non comme des utilisateurs nécessitant un mot de passe. Lorsqu'un agent d'IA doit accéder à une ressource protégée, il doit :

1. Authentification par son identité vérifiable (et non par un secret stocké).

2. Recevez des identifiants juste à temps, valides uniquement pour cette tâche spécifique.

3. Faites expirer automatiquement ces identifiants en quelques secondes ou minutes.

4. Ne jamais stocker ni même « voir » des secrets qui perdurent depuis longtemps

Plusieurs approches émergent. Rôles AWS IAM pour les comptes de service, L'identité de la charge de travail de Google, Les secrets dynamiques de HashiCorp VaultLes solutions dédiées comme Zero Trust Provisioning d'Akeyless convergent toutes vers cet avenir sans secrets. Les modalités d'implémentation varient, mais le principe demeure : si l'IA n'a aucun secret à dérober, l'injection de vulnérabilités représente une menace considérablement réduite.

L'environnement de développement de 2027

D'ici trois ans, le fichier .env disparaîtra du développement assisté par l'IA. Les clés API persistantes stockées dans les variables d'environnement seront considérées comme les mots de passe en clair aujourd'hui : une relique embarrassante d'une époque plus naïve.

Désormais, chaque agent d'IA fonctionnera avec une stricte séparation des privilèges. Accès en lecture seule par défaut. Liste blanche d'actions standard. Environnements d'exécution isolés (sandbox) comme exigence de conformité. Nous cesserons de tenter de contrôler la pensée de l'IA et nous concentrerons entièrement sur le contrôle de ses capacités.

Il ne s'agit pas simplement d'une évolution technique ; c'est un changement fondamental dans les modèles de confiance. Nous passons du principe « faire confiance, mais vérifier » au principe « ne jamais faire confiance, toujours vérifier et partir du principe qu'il y a compromission ». Le principe du moindre privilège, longtemps prôné mais rarement appliqué, devient non négociable lorsque votre développeur junior est une IA qui traite quotidiennement des milliers d'entrées potentiellement malveillantes.

Le choix auquel nous sommes confrontés

L'intégration de l'IA dans le développement logiciel est inévitable et largement bénéfique. GitHub indique que les développeurs utilisant Copilot exécutent leurs tâches 55 % plus rapidement.Les gains de productivité sont réels, et aucune organisation souhaitant rester compétitive ne peut les ignorer.

Nous sommes à la croisée des chemins. Nous pouvons persévérer dans la voie actuelle en multipliant les garde-fous, en développant de meilleurs filtres, dans l'espoir de créer des agents d'IA infaillibles. Ou bien, nous pouvons reconnaître la nature fondamentale de la menace et repenser notre architecture de sécurité en conséquence.

L'incident Samsung a servi d'avertissement. La prochaine faille de sécurité ne sera pas accidentelle et ne se limitera pas à une seule entreprise. À mesure que les agents d'IA acquièrent davantage de capacités et accèdent à un plus grand nombre de systèmes, l'impact potentiel croît de façon exponentielle.

La question que se posent tous les RSSI, tous les responsables techniques et tous les développeurs est simple : lorsqu’une injection de vulnérabilités réussit dans votre environnement (et elle réussira), que trouvera l’attaquant ? Découvrira-t-il une mine d’informations d’identification à longue durée de vie, ou un agent d’IA qui, bien que compromis, ne possède aucun secret à voler ?

Le choix que nous faisons aujourd'hui déterminera si l'IA deviendra le plus grand accélérateur du développement logiciel ou la plus grande vulnérabilité que nous ayons jamais créée. La technologie permettant de concevoir des systèmes d'IA sécurisés et transparents existe déjà. La question est de savoir si nous l'adopterons avant que des attaquants ne nous y contraignent.

L'OWASP a déjà identifié l'injection rapide comme le principal risque. dans leur Top 10 pour les demandes de LLM. Le NIST élabore des lignes directrices Sur les architectures zéro confiance, les frameworks existent. La seule question est celle de la rapidité de mise en œuvre face à l'évolution des attaques.

Biographie : Refael Angel est le cofondateur et directeur technique de Sans cléAu sein de l'entreprise, il a développé la technologie de chiffrement Zero Trust brevetée. Ingénieur logiciel chevronné, expert en cryptographie et sécurité du cloud, Refael a auparavant occupé le poste d'ingénieur logiciel senior au centre de R&D d'Intuit en Israël. Il y a conçu des systèmes de gestion des clés de chiffrement dans des environnements de cloud public et des services d'authentification des machines. Il est titulaire d'une licence en informatique du Jerusalem College of Technology, obtenue à l'âge de 19 ans.