Si l’IA lit tout, elle peut aussi obéir à n’importe qui

Les pipelines CI/CD pilotés par l’IA sont susceptibles de faire l’objet d’injections promptes malveillantes.

Un nouveau problème se profile dans la manière dont les logiciels sont déployés, et il mérite votre attention. L’IA est intégrée dans les pipelines CI/CD, des systèmes automatisés qui prennent le code et le poussent en production. Ils sont rapides, évolutifs et efficaces. Mais les chercheurs d’Aikido Security ont découvert une grave faiblesse : ces systèmes basés sur l’IA peuvent être trompés et exécuter des commandes nuisibles simplement en lisant le mauvais texte d’une question GitHub ou d’une demande d’extraction.

Voici comment cela fonctionne. Supposons que votre pipeline utilise des outils d’IA comme Gemini CLI ou OpenAI Codex pour automatiser certaines parties du flux de travail. Parfois, ces outils génèrent des commandes basées sur des éléments d’entrée, tels que des descriptions de demandes d’extraction soumises par les utilisateurs, des messages de livraison ou des commentaires sur les problèmes. Si ces entrées ne sont pas filtrées ou validées, les attaquants peuvent y dissimuler des instructions malveillantes. L’IA lit l’entrée, pense qu’il s’agit d’une invite légitime et agit en conséquence. Pas de piratage compliqué. Du simple texte.

Cela signifie que les attaquants, sans pirater votre système, peuvent obtenir le pipeline pour fuir des secrets, manipuler votre base de code, ou réexécuter des processus avec un accès privilégié. Dans l’environnement de test construit par Aikido, ils ont montré comment le CLI de Gemini pouvait être manipulé pour exposer des informations d’identification, le tout déclenché à partir d’un problème GitHub standard. Aucune autorisation élevée n’est nécessaire.

Les systèmes tels que GitHub Actions et GitLab CI/CD n’ont pas été conçus en tenant compte de ce risque, car la couche d’IA modifie la façon dont les commandes sont interprétées. Ce n’est pas seulement un logiciel qui s’exécute, c’est l’IA qui génère de la logique en temps réel, sur la base des entrées de l’utilisateur. Cela change complètement le modèle de menace.

La vitesse de l’IA est un avantage, mais lorsqu’elle est connectée à des systèmes qui prennent des décisions à fort enjeu, vous avez besoin de contrôles. Vous ne pouvez pas vous contenter de croire qu’un modèle n’interprétera pas mal quelque chose, il ne connaît pas l’intention, il se contente de prédire des modèles. Si ces schémas incluent « exécuter une commande shell » et que l’entrée le pousse dans cette direction, vous avez perdu le contrôle.

Google a corrigé ce problème lorsqu’il l’a découvert dans Gemini CLI après qu’Aikido l’ait porté à son attention. C’est une bonne chose. Mais beaucoup d’autres pipelines intégrés à l’IA fonctionnent encore à l’aveuglette. Quiconque construit ou supervise une infrastructure logicielle devrait se poser la question suivante : nos systèmes d’automatisation prennent-ils des décisions basées sur des données d’entrée non fiables ? Si la réponse n’est pas clairement négative, il y a un problème.

Nous avons besoin de valeurs par défaut plus sûres et d’une meilleure compréhension de la manière dont ces systèmes traitent les données. Et nous n’avons pas besoin d’attendre. La première étape consiste à cesser de supposer que chaque entrée est sûre, en particulier dans les contextes publics ou à source ouverte. C’est une question d’hygiène élémentaire. Votre IA fait ce qu’on lui demande, même si elle ne sait pas qu’on lui demande de faire quelque chose de mal.

L’exploitation, appelée « PromptPwnd », s’appuie sur des configurations CI/CD spécifiques

La vulnérabilité, appelée « PromptPwnd », n’est pas un vague exploit théorique. Elle est la conséquence directe d’une mauvaise configuration. Deux décisions de conception, toutes deux courantes, convergent pour ouvrir la porte.

Tout d’abord, l’agent d’IA dans le pipeline se voit accorder un accès privilégié. Il s’agit souvent de tokens comme GITHUB_TOKEN ou d’identifiants cloud, des clés puissantes utilisées pour exécuter des builds, pousser du code ou accéder à des services sensibles. Il ne s’agit pas de permissions de bas niveau. Elles ont une grande portée. Deuxièmement, les invites qui guident le comportement de l’IA comprennent des variables tirées directement des champs soumis par les utilisateurs, comme les messages de validation ou les descriptions de problèmes. Aucune vérification. Pas de filtres. Juste des données brutes transmises au système.

Mettez ces deux éléments ensemble. Vous avez un agent d’IA doté d’une grande autorité qui reçoit des instructions directes, consciemment ou non, de sources externes non vérifiées. C’est là que le risque augmente. Les attaquants n’ont pas besoin de s’introduire dans votre système si vous avez déjà confié le pouvoir de décision à un modèle fonctionnant à partir de données publiques.

Aikido Security a expliqué exactement comment cela se passe. Ils ont rédigé un commentaire dans une question GitHub qui semblait innocent mais qui contenait des instructions qui ont été captées par l’IA. Cette entrée a été traitée comme faisant partie de l’invite. À partir de là, l’IA a généré des commandes shell que le pipeline CI/CD a ensuite exécutées. Même sans les véritables jetons utilisés dans le test, le résultat était clair : des commandes non intentionnelles ont été déclenchées sans aucune surveillance manuelle.

Les dirigeants doivent comprendre qu’il ne s’agit pas seulement d’une mauvaise utilisation des privilèges, mais d’une délégation involontaire. Vous donnez un véritable pouvoir opérationnel à un système qui a été formé pour répondre à des invites basées sur la reconnaissance de modèles, et non sur le jugement. Cela change la façon dont la confiance doit fonctionner dans l’infrastructure logicielle. Les barrières de sécurité traditionnelles ne tiendront pas si les systèmes internes peuvent être redirigés depuis l’extérieur.

L’architecture qui sous-tend ces intégrations d’IA est largement réutilisée sur toutes les plateformes. Il ne s’agit pas d’un seul produit. Gemini CLI, Claude Code Actions, GitHub AI Inference, OpenAI Codex, ils suivent tous des modèles similaires, et ce modèle est défectueux si vous ne contrôlez pas les données qui entrent dans l’invite.

Les dirigeants doivent traiter cette question comme une priorité. Le danger ne réside pas dans ce qui s’est déjà produit, mais dans le nombre d’environnements exposés sans le savoir. Ne partez pas du principe que vos configurations existantes sont sûres. Demandez à vos équipes de vérifier explicitement : transmettons-nous du texte non fiable dans les invites de l’IA ? Limitons-nous ce que ces agents d’intelligence artificielle peuvent faire ? Si ce n’est pas le cas, votre exposition est plus importante que vous ne le pensez.

Des stratégies d’atténuation sont disponibles et font l’objet d’une promotion active afin de sécuriser ces configurations CI/CD vulnérables.

La bonne nouvelle, c’est que cette vulnérabilité n’est pas sans solution. Aikido Security ne s’est pas contenté de signaler le problème, il a publié des outils pour détecter et réduire le risque. Son approche consiste à donner aux développeurs et aux équipes de sécurité une visibilité pratique sur les configurations dangereuses.

Ils ont publié un ensemble de règles de détection open-source sous l’outil « Opengrep », conçu spécifiquement pour analyser les fichiers YAML de GitHub Action à la recherche de signes indiquant que les entrées contrôlées par l’utilisateur alimentent directement les invites de l’IA. Parallèlement, ils proposent également un outil gratuit d’analyse du code qui fonctionne sur les dépôts GitHub et GitLab. Il signale les modèles CI/CD non sécurisés, les privilèges de jeton excessifs et les failles du flux de travail de l’IA qui, autrement, passeraient inaperçus jusqu’à ce qu’ils soient exploités.

Cela est important car ces attaques ne nécessitent pas d’exploits complexes. Elles se produisent lorsque des systèmes fiables traitent des données non fiables sans surveillance. Il s’agit d’une défaillance évitable. Si votre pipeline prend la description d’un problème et l’envoie directement à une IA qui peut exécuter des commandes, vous avez intégré une vulnérabilité, de par votre conception. La solution ne consiste pas à bloquer l’IA, mais à structurer correctement vos messages-guides et les limites du système.

Les directives d’Aikido sont claires : traitez les résultats générés par l’IA de la même manière que le code d’une tierce partie. Il n’est pas sûr par défaut. Validez tout. Fixez des limites à ce que les agents d’IA sont autorisés à exécuter et ne transmettez jamais de contenu soumis par l’utilisateur directement aux invites de l’IA sans nettoyage. Ces ajustements ne ralentissent pas l’innovation, ils évitent une exposition inutile.

Du point de vue de la direction, la priorité est simple. Demandez à vos équipes d’auditer ces flux de travail. Si des outils d’IA sont présents dans vos pipelines CI/CD, vous devez vous assurer de quatre choses : que les données non fiables sont filtrées, que les actions d’IA sont mises en bac à sable, que les jetons sont définis de manière prudente et que toute commande dynamique générée par l’IA fait l’objet d’un examen ou d’un confinement.

Il s’agit d’élever la norme par défaut, de faire progresser l’automatisation tout en la maintenant ancrée dans les contrôles de sécurité. Il n’y a aucun avantage à ignorer les risques qui découlent de vos propres configurations. Vous ne protégez pas seulement votre base de code, vous renforcez la fiabilité opérationnelle. Il est plus rapide de sécuriser cela maintenant que de s’occuper du nettoyage en cas de panne.

Le paysage des menaces est élargi par le fait que même des niveaux d’accès minimaux peuvent faciliter l’exploitation

L’une des conclusions les plus importantes de la recherche d’Aikido Security est la suivante : vous n’avez pas besoin d’un accès élevé pour déclencher l’une de ces attaques basées sur l’IA. Dans de nombreuses configurations CI/CD réelles, le simple fait d’ouvrir un problème public ou de soumettre une demande d’extraction suffit à compromettre le pipeline, si le système est mal structuré.

Cela abaisse considérablement la barrière pour les acteurs malveillants. Il ne s’agit pas de menaces d’initiés ou d’exploits de type « zero-day ». Il s’agit d’une exploitation basique des entrées. Toute personne ayant accès à un référentiel public, sans justificatifs, sans confiance préalable, peut injecter des instructions basées sur des invites dans des descriptions ou des commentaires. Si ces entrées atteignent un modèle d’IA fonctionnant avec un accès à privilèges élevés dans un flux de travail automatisé, elles peuvent conduire à l’exécution de commandes, à l’exposition de données, voire pire.

Certains flux de travail nécessitent encore des autorisations de collaborateur pour être exploités, mais pas tous. Aikido a trouvé des cas où l’accès général est suffisant. Cela élargit la surface de risque au-delà des modèles de sécurité internes typiques et déplace le problème dans le domaine public. Si votre pipeline CI/CD écoute des commandes générées par l’IA, et si cette IA prend en compte des soumissions ouvertes, votre surface d’attaque est plus grande que vous ne le pensez.

Pour les dirigeants, cela devrait entraîner une réévaluation immédiate des modèles de confiance, en particulier dans les environnements à code source ouvert ou accessibles de l’extérieur, où de grandes bases de contributeurs interagissent avec le code et les artefacts de configuration. La vérification ne doit pas s’arrêter à l’authentification. Elle doit s’étendre au contrôle comportemental : que peut réellement faire chaque flux de travail ? Quels intrants consomment-ils ? Exposons-nous des processus d’automatisation sensibles au public par le biais d’hypothèses silencieuses dans notre conception ?

Aikido a démontré ces voies d’exploitation dans des environnements contrôlés. Il n’a pas été nécessaire d’utiliser de vrais jetons ou de s’introduire dans les systèmes pour le prouver. Cela confirme que l’infrastructure existante, si elle n’est pas auditée, peut déjà être vulnérable en raison d’une mauvaise hygiène architecturale. Ce qui ressemble à un cas isolé est en fait un modèle répandu dont le risque augmentera au fur et à mesure que l’automatisation intégrée à l’IA se répandra.

La conclusion est simple : un apport externe minimal peut déclencher des conséquences internes maximales si la configuration le permet. Les entreprises devraient réagir par des actions ciblées, restreindre la portée des capacités d’IA dans les pipelines, découpler la prise de décision de l’IA des commentaires des utilisateurs et verrouiller ce qui est exécuté à la suite d’une invite. La détection des menaces ne suffit pas lorsque le point d’entrée est largement ouvert de par sa conception.

Faits marquants

• Les flux de travail d’IA peuvent être exploités par le biais d’entrées publiques : Si les outils d’IA dans les pipelines CI/CD traitent des données non filtrées provenant de problèmes GitHub ou de demandes d’extraction, les attaquants peuvent injecter silencieusement des commandes. Les dirigeants devraient imposer la validation des entrées et la limitation des privilèges dans tous les flux de travail automatisés.
• PromptPwnd est le résultat d’une conception défectueuse du système : Le problème se pose lorsque l’IA est à la fois très privilégiée et alimentée par du contenu généré par l’utilisateur. Les décideurs devraient revoir toute la logique d’automatisation qui permet aux modèles d’interpréter et d’agir sur des données externes.
• Des outils pratiques d’atténuation existent et devraient être adoptés : Les scanners open-source comme Opengrep peuvent signaler les flux de travail non sécurisés, identifier les jetons trop permissifs et repérer les utilisations dangereuses de l’IA. Les dirigeants devraient donner la priorité à l’intégration de ces scanners dans le pipeline de développement afin de réduire l’exposition.
• Un accès de bas niveau peut avoir des conséquences de haut niveau : Même les non-collaborateurs peuvent exploiter certains flux de travail défectueux simplement en ouvrant des questions. Les dirigeants doivent insister pour que les dépôts publics fassent l’objet d’audits immédiats et traiter tous les intrants externes comme des vecteurs de menace potentiels.