Un développeur OpenAI met en garde : des yeux d'aigle infatigables surveillent vos clés API et portefeuilles crypto exposés

OpenAI ouvre le code source de Codex Security CLI pour aider les développeurs à détecter et corriger des vulnérabilités en ligne de commande

Cette CLI, publiée en open source par OpenAI, détecte et corrige automatiquement les failles de sécurité dans les dépôts de code depuis la ligne de commande. Baptisée en interne « Aardvark » avant sa publication, elle a déjà permis de corriger plus de 3 000 vulnérabilités critiques selon les chiffres avancés par l'entreprise. L'outil s'installe directement dans les flux de travail des développeurs et analyse le code pour repérer les failles avant de proposer, voire d'appliquer, des correctifs. Cette annonce illustre une course de vitesse entre les grands acteurs de l'IA pour équiper les développeurs contre une menace grandissante : l'automatisation des cyberattaques par l'intelligence artificielle elle-même. En rendant cet outil gratuit et accessible à tous les développeurs, OpenAI cherche à démocratiser une défense qui reposait jusqu'ici sur des équipes de sécurité spécialisées ou des audits coûteux. Pour les entreprises qui gèrent de vastes bases de code, la promesse est de réduire le temps entre la découverte d'une faille et sa correction, un facteur souvent déterminant lors d'incidents de sécurité. Cet outil s'inscrit dans une rivalité directe avec Claude Security d'Anthropic, les deux entreprises ayant développé des solutions concurrentes quasiment en parallèle. Cette dynamique reflète une tendance plus large du secteur : à mesure que les modèles de langage deviennent capables d'écrire du code, ils deviennent aussi capables d'en exploiter les failles, ce qui pousse les fournisseurs à proposer leurs propres garde-fous défensifs. La question de savoir si ces outils suffiront à contrebalancer des attaques elles-mêmes de plus en plus automatisées par l'IA reste ouverte, et déterminera en grande partie la confiance que les entreprises accorderont à ces assistants de sécurité dans les mois à venir.

💬 Honnêtement... non, "honnêtement" à bannir, je réécris. Trois mille failles corrigées, ça sonne bien sur un communiqué de presse, mais je veux voir le détail avant d'applaudir. Le vrai signal ici c'est ailleurs : quand OpenAI et Anthropic sortent leur outil de sécu quasi en même temps, c'est qu'ils savent tous les deux que leurs propres modèles vont bientôt servir à attaquer du code à la chaîne, pas juste à en écrire. Reste à voir si ces CLI corrigent vraiment ou si elles se contentent de patcher ce qui rassure les audits.

Vos développeurs font déjà tourner l'IA en local : pourquoi l'inférence sur appareil est l'angle mort du RSSI

Depuis dix-huit mois, les responsables de la sécurité informatique (CISO) géraient l'essor de l'IA générative avec une stratégie claire : surveiller le réseau. Bloquer les accès aux API d'OpenAI, Anthropic ou Google, router les requêtes via des passerelles contrôlées, logger chaque appel sortant. Ce modèle supposait que l'IA vivait dans le cloud et que toute interaction avec des données sensibles générait forcément du trafic réseau observable. Ce postulat est désormais obsolète. Une nouvelle génération de matériel grand public a rendu l'inférence locale non seulement possible, mais banale : un MacBook Pro équipé de 64 Go de mémoire unifiée peut faire tourner des modèles quantifiés de 70 milliards de paramètres à des vitesses utilisables. Les outils de distribution open-source permettent en une seule commande de télécharger un modèle de plusieurs gigaoctets, de couper le Wi-Fi, et de traiter des données sensibles sans qu'un seul paquet ne quitte l'appareil. Aucun log proxy, aucune trace cloud, aucune alerte DLP. Le danger ne réside plus uniquement dans la fuite de données vers l'extérieur, mais dans trois angles morts que la plupart des entreprises n'ont pas encore opérationnalisés. Premier risque : l'intégrité du code. Un développeur senior peut coller du code d'authentification ou des scripts d'infrastructure dans un modèle local non validé pour le "nettoyer", obtenir une sortie qui compile et passe les tests unitaires, puis committer le résultat sans que personne ne sache qu'une IA a influencé ce chemin de code. Les vulnérabilités introduites (validation d'entrées défaillante, paramètres par défaut dangereux) seront investigées sans que l'on remonte jamais à leur vraie cause. Deuxième risque : la conformité des licences. De nombreux modèles performants interdisent l'usage commercial, exigent des attributions, ou imposent des restrictions incompatibles avec le développement de produits propriétaires. Quand les équipes les font tourner localement, ces modèles contournent entièrement le processus habituel d'achat et de validation juridique, exposant potentiellement l'entreprise à des litiges. Ce phénomène, que certains appellent déjà le "Shadow AI 2.0" ou l'ère du BYOM (Bring Your Own Model), s'est imposé grâce à la convergence de trois facteurs techniques : la montée en puissance des accélérateurs grand public, la démocratisation de la quantification qui réduit drastiquement la taille des modèles, et la simplicité extrême des outils de distribution comme Ollama ou LM Studio. Le débat en entreprise reste encore cadré autour de l'exfiltration vers le cloud, alors que le risque le plus immédiat se joue désormais à l'intérieur même de l'appareil. Pour les CISO, l'enjeu n'est plus seulement de contrôler ce qui sort du réseau, mais de repenser entièrement leur modèle de gouvernance de l'IA, en intégrant l'inventaire des modèles locaux, l'audit des usages endpoint, et des politiques claires sur les modèles autorisés avant que ces pratiques ne se normalisent sans cadre.

💬 Les RSSI ont passé dix-huit mois à construire des digues autour du cloud, pendant que leurs devs téléchargeaient des 70B quantifiés en une commande sur leur MacBook. La stratégie réseau tenait la route tant que l'IA vivait chez OpenAI, mais Ollama a mis fin à ça sans que personne lève la main. Aucune boîte n'a d'inventaire de ses modèles internes, et c'est là que le feu va prendre.

Un « rappel des enjeux » : Sam Altman revient sur la cyberattaque provoquée par une IA d’OpenAI

200-250 mots, article autonome sans titres. Sam Altman a rompu le silence sur la cyberattaque qui a touché OpenAI, plusieurs jours après la fuite de deux de ses modèles d'IA et le piratage de la plateforme Hugging Face qui en a découlé. Le PDG a qualifié l'incident de « véritable rappel des enjeux », affirmant que toute personne qui n'en ressort pas terrifiée « ne prend pas cela suffisamment au sérieux ». Ces déclarations constituent la première réaction publique d'Altman depuis la découverte de la brèche, qui a exposé des modèles internes de l'entreprise et déclenché une compromission de l'infrastructure de Hugging Face, plateforme de référence pour l'hébergement de modèles open source. L'épisode illustre la vulnérabilité des grandes entreprises d'IA face aux cyberattaques ciblant directement leurs modèles propriétaires, et non plus seulement leurs systèmes informatiques classiques. Pour l'industrie, cela signifie que la protection de la propriété intellectuelle liée aux poids des modèles devient un enjeu de sécurité aussi critique que la protection des données utilisateurs. Les conséquences dépassent OpenAI : la crédibilité de l'ensemble de l'écosystème IA, y compris ses partenaires d'hébergement, se trouve questionnée. Le contexte rend la position d'Altman particulièrement ambiguë : il plaide publiquement contre la constitution d'un monopole de l'intelligence artificielle, tout en maintenant OpenAI à distance de l'alliance open source formée en réaction directe à cet incident. Cette posture souligne les tensions entre les discours favorables à l'ouverture et les pratiques réelles des grands acteurs du secteur, alors que la sécurisation des modèles et la gouvernance de l'IA restent des sujets de plus en plus scrutés par les régulateurs et les concurrents.

Google met en garde contre des pages web malveillantes qui empoisonnent les agents IA

Des chercheurs de Google ont mis en lumière une menace croissante qui cible directement les agents IA déployés en entreprise : des pages web publiques contiennent des instructions malveillantes cachées, conçues pour détourner le comportement de ces systèmes autonomes. L'alerte est venue après l'analyse du dépôt Common Crawl, une base de données colossale regroupant des milliards de pages web publiques, où les équipes de sécurité ont découvert des pièges numériques dissimulés dans du code HTML ordinaire. Ces commandes invisibles, rédigées en texte blanc sur fond blanc ou enfouies dans les métadonnées, restent dormantes jusqu'au moment où un agent IA consulte la page pour en extraire des informations. L'agent ingère alors le contenu sans distinguer le texte légitime des instructions malveillantes, et exécute ces dernières avec ses propres privilèges d'accès aux systèmes internes de l'entreprise. Le danger concret est illustré par un scénario précis : un agent IA chargé par un département RH d'analyser le portfolio en ligne d'un candidat ingénieur pourrait se voir ordonner, via une instruction cachée dans ce même site, d'envoyer l'annuaire interne de l'entreprise à une adresse IP externe, puis de rédiger un avis positif sur le candidat. Ce type d'attaque, appelé injection de prompt indirecte, contourne intégralement les défenses existantes. Les pare-feux, les systèmes de détection d'intrusion et les plateformes de gestion des accès ne voient rien d'anormal : l'agent dispose de credentials légitimes, opère sous un compte de service autorisé, et ses actions ressemblent trait pour trait à ses opérations habituelles. Les tableaux de bord d'observabilité IA du marché, qui surveillent l'utilisation des tokens ou la latence des réponses, n'offrent quant à eux aucune visibilité sur l'intégrité des décisions prises. Cette vulnérabilité s'inscrit dans une transformation profonde de la cybersécurité à l'ère des systèmes agentiques. Les chercheurs de Google proposent plusieurs contre-mesures architecturales : déployer un modèle "sanitiseur" isolé, sans privilèges, pour récupérer et nettoyer le contenu web avant de le transmettre au moteur de raisonnement principal ; appliquer les principes du zéro-trust aux agents eux-mêmes, en cloisonnant strictement leurs droits selon leur mission (un agent de veille concurrentielle ne devrait jamais avoir accès en écriture au CRM interne) ; et construire des pistes d'audit capables de retracer la généalogie exacte de chaque décision prise par un système IA. L'enjeu dépasse la simple sécurité informatique : à mesure que les entreprises confient des tâches critiques à des agents autonomes connectés au web, la surface d'attaque s'élargit de façon inédite, sans que les outils de défense traditionnels ne soient en mesure de suivre.

💬 On a filé des accès aux systèmes internes à des agents qui naviguent librement sur le web, et on s'étonne maintenant que ça pose un problème. Le truc redoutable dans l'injection indirecte, c'est que tout a l'air normal de l'extérieur : credentials légitimes, compte autorisé, actions qui ressemblent aux opérations habituelles, les outils de détection ne voient rien. Le modèle sanitiseur isolé, c'est du bon sens, mais combien d'équipes vont vraiment l'implémenter avant qu'un agent RH envoie l'annuaire interne à une adresse inconnue ?