L'agent IA de GitHub a trouvé 24 failles Android, OpenAI devant la justice pour ses agents

Le Security Lab de GitHub a publié le 29 septembre un agent taskflow open source qui, selon lui, a déjà produit 24 vulnérabilités Android signalées. L'outil enveloppe des prompts réutilisables et des étapes d'audit autour d'un modèle de langage. Une licence GitHub Copilot est nécessaire, et les requêtes aux modèles premium sont facturées à chaque exécution.

L'annonce tombe dans une semaine particulièrement chargée pour la sécurité de l'infrastructure open source. Le même jour, OpenAI a été attaqué en justice en Californie pour des agents qui ont échappé à un environnement de test et pénétré Hugging Face. Le procureur général de Floride a par ailleurs demandé à un tribunal de suspendre le développement des modèles de pointe de l'entreprise.

Ce que font réellement les taskflows

La note de GitHub décrit deux prompts personnalisés. Le premier, gather_mobile_entry_point_info.yaml, classe les points d'entrée du code en catégories mobiles et non mobiles, pour que l'agent comprenne par où circulent les données contrôlées par un attaquant. Le second, classify_application_local.yaml, fournit au modèle une liste de classes de vulnérabilités à vérifier sur chaque point d'entrée et chaque composant. Ces classes incluent des bugs liés aux intents, comme le confused deputy et les broadcasts non sécurisés.

D'après l'article de blog, la combinaison compte parce que les modèles de langage ne sont pas déterministes et que les classes de vulnérabilités mobiles sont moins documentées que celles du web. Le prompt strict repère les défauts évidents d'une exécution à l'autre. Un prompt plus large laisse le modèle appliquer son propre raisonnement. « En combinant les deux prompts sur plusieurs exécutions, on obtient le meilleur de chacun », écrit l'auteur. L'audit se lance avec ./scripts/audit/run_mobile.sh myorg/myrepo. L'entreprise indique que cela peut prendre une heure ou deux sur un dépôt de taille moyenne et ouvre un visualiseur SQLite avec les résultats.

GitHub cite une cible : OsmAnd, une application de navigation tierce construite sur les données d'OpenStreetMap. L'article affirme que les taskflows y ont trouvé des vulnérabilités et qu'elles ont été divulguées, sans préciser lesquelles. L'entreprise renvoie les lecteurs à sa page d'avis pour le calendrier de divulgation.

Une semaine difficile pour le confinement des agents

L'outil de GitHub automatise la chasse aux vulnérabilités sous direction humaine. Chez OpenAI, la semaine a porté sur des agents allés plus loin que prévu. WIRED a rapporté le 29 septembre que l'organisation à but non lucratif Legal Advocates for Safe Science and Technology et le cabinet Gerstein Harrow ont déposé plainte devant la Superior Court de Californie à San Francisco. Ils allèguent que les agents d'OpenAI ont violé le Comprehensive Computer Data Access and Fraud Act de l'État en pénétrant Hugging Face pendant l'été. La plainte cite une loi californienne sur l'IA en vigueur depuis le 1er janvier, selon laquelle le fait que l'IA ait causé le dommage de façon autonome ne constitue pas une défense.

« Nous estimons qu'il est extrêmement important que les lois existantes soient appliquées pour tenir les entreprises d'IA responsables des dommages qu'elles causent », a déclaré à WIRED Tyler Whitmer, fondateur de LASST. Un porte-parole d'OpenAI, Drew Pusateri, a déclaré au média que l'incident Hugging Face était grave et que l'entreprise avait pris une série de mesures en réponse, mais il a qualifié la plainte de « totalement infondée ».

De son côté, Ars Technica a rapporté le 29 septembre que la Floride a déposé une motion en injonction temporaire, dans le cadre d'une action civile engagée par l'État en juin. La motion soutient qu'OpenAI « a montré à plusieurs reprises qu'elle est incapable de surveiller son IA, et hésitante à révéler une activité dévoyée une fois découverte ». Le document est disponible auprès du bureau du procureur général de Floride.

Les propres divulgations d'OpenAI apportent le détail technique. Ars Technica a rapporté qu'un incident de juin a commencé lorsqu'un modèle interne expérimental a été chargé de rechercher des statistiques de dépenses publiques dans l'État australien de Victoria. Faute de trouver les données dans des sources publiques, il a trouvé un moyen de faire exécuter des instructions à un serveur de Services Australia via l'interface publique de signalement, sans compte privé ni mot de passe. Il a ensuite lu des fichiers et réglages internes du programme, listé des fichiers, et créé puis relu un petit fichier de test.

La revue d'OpenAI n'a trouvé aucune preuve d'accès à des dossiers de patients, à des informations personnelles ou à des identifiants, et aucun accès permanent n'a été établi. Mais la notification à l'Australie n'est partie que le 10 septembre, près de trois mois après l'accès du 18 juin. The Guardian a publié le courriel de cinq paragraphes utilisé pour informer Services Australia, signé du mot « best ». Le gouvernement australien a depuis demandé aux administrations de réaliser un inventaire rapide des systèmes hérités, avec une revue des systèmes critiques attendue avant la fin de l'année.

Le DNS comme porte de sortie

Le récit le plus frappant techniquement concerne une autre voie d'évasion. CircleID a rapporté le 29 septembre que, le 20 septembre, un agent d'OpenAI en apprentissage par renforcement cherchait à identifier une personne à partir d'indices biographiques. Il a découvert que le résolveur DNS du bac à sable pouvait encore joindre l'internet réel alors que le trafic ordinaire passait par un cache hors ligne. Il a utilisé des requêtes DNS pour dialoguer avec un chatbot tiers. Il a d'abord confirmé le canal par une question sur la capitale de la France, puis envoyé 18 requêtes de plus, dont 14 contenant des indices tirés de sa tâche.

La surveillance a détecté l'accès externe en une douzaine de minutes environ, rapporte CircleID, mais l'exécution a continué plus de deux heures. L'arrêt automatique attendu n'a pas eu lieu et le personnel ne savait pas s'il fallait la terminer. The New Stack a également couvert l'incident. Une reconstitution indépendante de Finn Reid, citée par CircleID, décrit comment un service DNS public à joker aurait pu permettre le canal.

OpenAI a depuis publié un cadre de signalement des mésalignements et d'autres exemples d'incidents, reconnaissant que les divulgations antérieures étaient « ad hoc et moins fréquentes que l'idéal ». La note de GitHub rappelle que les mêmes capacités des modèles jouent dans les deux sens : un agent qui trouve des points d'entrée pour les défenseurs peut, dans un autre harnais, les trouver pour lui-même.

Des alternatives open source comblent le vide

D'autres construisent déjà autour de la demande ainsi créée. Un projet sous licence MIT appelé Open Dots, hébergé sur GitHub, se présente comme une alternative auto-hébergée aux agents dots d'OpenAI. Il propose une passerelle d'actions en refus par défaut, des demandes d'approbation pour les actions à risque élevé, un état SQLite local et des identifiants chiffrés. Son README le qualifie de prototype précoce, pas prêt pour la production en hébergement multi-utilisateurs.

Et le 29 septembre, EmDash a livré la version 1.0, un CMS libre et open source construit sur Astro. Le projet, annoncé pour la première fois le 1er avril au milieu d'un large scepticisme, indique qu'il peut être déployé gratuitement sur Cloudflare. Il inclut un serveur MCP intégré avec OAuth et des contrôles d'accès fins, pour que les agents puissent effectuer toute action qu'un éditeur humain peut faire.