L’impératif sans secret : pourquoi les modèles de sécurité traditionnels échouent lorsque les agents IA touchent le code

En avril 2023, Samsung a découvert que ses ingénieurs avaient divulgué des informations sensibles à ChatGPT. Mais cela était accidentel. Imaginez maintenant que ces référentiels de code contenaient des instructions intentionnellement intégrées, invisibles pour les humains mais traitées par l’IA, conçues pour extraire non seulement le code mais également toutes les clés API, les informations d’identification de base de données et les jetons de service que l’IA pouvait accéder. Ce n’est pas hypothétique. Les chercheurs en sécurité ont déjà démontré que ces attaques d'”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 construit la sécurité sur une hypothèse fondamentale : le code est du code, et les données sont des données. L’injection SQL nous a appris à paramétrer les requêtes. Le cross-site scripting nous a appris à échapper les sorties. Nous avons appris à construire des murs entre ce que les programmes font et ce que les utilisateurs saisissent.

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

Contrairement aux logiciels déterministes qui suivent des chemins prévisibles, les grands modèles de langage sont des boîtes noires probabilistes qui ne peuvent pas distinguer entre les instructions légitimes des développeurs et les entrées malveillantes. Lorsqu’un attaquant fournit une invite à un assistant de codage IA, il ne fournit pas seulement des données. Il reprogramme essentiellement l’application en temps réel. L’entrée est devenue le programme lui-même.

Ceci représente une rupture fondamentale avec tout ce que nous savons sur la sécurité des applications. Les pare-feu syntaxiques traditionnels, qui recherchent des modèles malveillants comme DROP TABLE ou des balises , échouent complètement contre les attaques de langage naturel. Les chercheurs ont démontré des techniques de “substitution sémantique” où remplacer “clés API” par “pommes” dans les invites permet aux attaquants de contourner les filtres entièrement. Comment pouvez-vous protéger l’intention lorsqu’elle est déguisée en conversation inoffensive ?

La réalité zéro-clic que personne ne discute

Voici ce que la plupart des équipes de sécurité ne comprennent pas : l’injection d’invite ne nécessite pas qu’un utilisateur tape quelque chose. Ce sont souvent des exploits zéro-clic. Un agent IA qui analyse simplement un référentiel de code pour une tâche de routine, qui examine une demande de tirage ou qui lit la documentation API, peut déclencher une attaque sans aucune interaction humaine.

Considérez ce scénario, basé sur des techniques que les chercheurs ont déjà prouvées : un acteur malveillant intègre des instructions invisibles dans les commentaires HTML au sein de la documentation d’une bibliothèque open-source populaire. Chaque assistant IA qui analyse ce code, que ce soit GitHub Copilot, Amazon CodeWhisperer ou n’importe quel assistant de codage d’entreprise, devient un potentialiseur de clés d’identification. Une bibliothèque compromise pourrait signifier des milliers d’environnements de développement exposés.

Le danger n’est pas le modèle de langage lui-même ; c’est l’agent que nous lui donnons. Le moment où nous avons intégré ces modèles avec des outils et des API, en les laissant récupérer des données, exécuter du code et accéder à des secrets, nous avons transformé des assistants utiles en vecteurs d’attaque parfaits. Le risque ne s’accroît pas avec l’intelligence du modèle ; il s’accroît avec sa connectivité.

Pourquoi l’approche actuelle est condamnée

L’industrie est actuellement obsédée par “l’alignement” des modèles et la construction de meilleurs pare-feu d’invites. OpenAI ajoute plus de garde-fous. Anthropic se concentre sur l’IA constitutionnelle. Tout le monde essaie de créer des modèles qui ne peuvent pas être trompés.

C’est une bataille perdue.

Si un IA est suffisamment intelligente pour être utile, il est suffisamment intelligent pour être trompé. Nous tombons dans ce que j’appelle le “piège de la désinfection” : en supposant que meilleure filtration des entrées nous sauvera. Mais les attaques peuvent être dissimulées sous forme de texte invisible dans les commentaires HTML, enfouis profondément dans la documentation ou codés de manière que nous n’avons pas encore imaginée. Vous ne pouvez pas désinfecter ce que vous ne pouvez pas comprendre contextuellement, et c’est exactement ce qui rend les modèles de langage puissants.

L’industrie doit accepter une vérité difficile : l’injection d’invite réussira. La question est ce qui se passera lorsqu’elle réussira.

Le changement architectural dont nous avons besoin

Nous sommes actuellement dans une “phase de correction”, ajoutant désespérément des filtres d’entrée et des règles de validation. Mais tout comme nous avons finalement appris que prévenir l’injection SQL nécessitait des requêtes paramétrées, et non une meilleure échappement de chaînes, nous avons besoin d’une solution architecturale pour la sécurité IA.

La réponse se trouve dans un principe qui semble simple mais nécessite de repenser la façon dont nous construisons les systèmes : les agents IA ne devraient jamais posséder les secrets qu’ils utilisent.

Ceci n’est pas à propos d’une meilleure gestion des informations d’identification ou de solutions de coffre-fort améliorées. Il s’agit de reconnaître les agents IA comme des identités uniques et vérifiables plutôt que des utilisateurs ayant besoin de mots de passe. Lorsqu’un agent IA a besoin d’accéder à une ressource protégée, il devrait :

1. S’authentifier en utilisant son identité vérifiable (et non un secret stocké)

2. Recevoir des informations d’identification juste-à-temps valides uniquement pour cette tâche spécifique

3. Voir ces informations d’identification expirer automatiquement dans les secondes ou les minutes

4. Ne jamais stocker ou même “voir” des secrets à long terme

Plusieurs approches émergent. Les rôles IAM d’AWS pour les comptes de service, L’identité de charge de travail de Google, Les secrets dynamiques de HashiCorp Vault et des solutions spécialement conçues comme la mise en place de confiance zéro d’Akeyless pointent toutes vers cet avenir sans secret. Les détails d’implémentation varient, mais le principe reste : si l’IA n’a pas de secrets à voler, l’injection d’invite devient une menace nettement plus petite.

L’environnement de développement de 2027

Dans trois ans, le fichier .env sera mort dans le développement assisté par l’IA. Les clés API à long terme situées dans les variables d’environnement seront considérées comme nous considérons actuellement les mots de passe en texte brut : un vestige embarrassant d’une époque plus naive.

Au lieu de cela, chaque agent IA fonctionnera sous une séparation stricte des privilèges. Accès en lecture seule par défaut. Liste blanche d’actions en standard. Environnements d’exécution sandboxés en tant qu’exigence de conformité. Nous cesserons d’essayer de contrôler ce que l’IA pense et nous concentrerons entièrement sur le contrôle de ce qu’elle peut faire.

Ceci n’est pas seulement une évolution technique ; c’est un changement fondamental dans les modèles de confiance. Nous passons de “faire confiance mais vérifier” à “ne jamais faire confiance, toujours vérifier et supposer une faille”. Le principe du moindre privilège, longtemps prêché mais rarement pratiqué, devient incontournable lorsque votre junior développeur est un IA qui traite des milliers d’entrées potentiellement malveillantes chaque jour.

Le choix que nous devons faire

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

Mais nous sommes à la croisée des chemins. Nous pouvons continuer sur la voie actuelle en ajoutant plus de garde-fous, en construisant de meilleurs filtres, en espérant que nous pouvons créer des agents IA qui ne peuvent pas être trompés. Ou nous pouvons reconnaître la nature fondamentale de la menace et reconstruire notre architecture de sécurité en conséquence.

L’incident Samsung a été un avertissement. La prochaine faille ne sera pas accidentelle, et elle ne sera pas contenue dans une seule entreprise. À mesure que les agents IA gagnent plus de capacités et accèdent à plus de systèmes, l’impact potentiel augmente de manière exponentielle.

La question pour chaque DSI, chaque dirigeant d’ingénierie et chaque développeur est simple : Quand l’injection d’invite réussira dans votre environnement (et elle le fera), que trouvera l’attaquant ? Découvrira-t-il un trésor de clés d’identification à long terme, ou trouvera-t-il un agent IA qui, malgré avoir été compromis, n’a pas de secrets à voler ?

Le choix que nous faisons maintenant déterminera si l’IA deviendra le plus grand accélérateur de développement de logiciels ou la plus grande vulnérabilité que nous ayons jamais créée. La technologie pour construire des systèmes IA sécurisés et sans secret existe aujourd’hui. La question est de savoir si nous la mettrons en œuvre avant que les attaquants nous y obligent.

OWASP a déjà identifié l’injection d’invite comme le #1 risque dans leur Top 10 pour les applications de modèles de langage. NIST est en train d’élaborer des directives sur les architectures de confiance zéro. Les cadres existent. La seule question est la vitesse d’implémentation par rapport à l’évolution des attaques.

Bio : Refael Angel est le co-fondateur et le CTO d’Akeyless, où il a développé la technologie de cryptage à confiance zéro brevetée de l’entreprise. Un ingénieur logiciel expérimenté avec une expertise approfondie en cryptographie et en sécurité cloud, Refael a précédemment servi en tant qu’ingénieur logiciel principal au centre de R&D d’Intuit en Israël, où il a construit des systèmes pour gérer les clés de cryptage dans les environnements cloud publics et conçu des services d’authentification de machine. Il détient un B.Sc. en informatique du Jerusalem College of Technology, qu’il a obtenu à l’âge de 19.