OpenAI a présenté trois nouveaux modules destinés à l'enseignement, un pour les professeurs du primaire et du secondaire, un pour ceux du supérieur, et un dernier pour les étudiants eux-mêmes.

Le premier passe par ChatGPT for Teachers, la version gratuite réservée aux enseignants vérifiés (pour le moment uniquement américains) et à leurs établissements. Il fabrique des ressources adaptées au niveau de chaque élève, produit des visuels interactifs et se branche sur les référentiels pédagogiques locaux.

Les deux autres arrivent par ChatGPT Edu, la formule sous licence que les universités achètent pour tout leur campus. Un enseignant du supérieur peut y mettre à jour son programme, monter un site de cours, produire des évaluations multimédias, et reconditionner l'ensemble pour la plateforme pédagogique de son établissement.

Les étudiants, eux, récupèrent un tuteur, des quiz générés à la volée, des fiches de révision et des explications en images. OpenAI précise qu'ils doivent définir leurs objectifs, choisir leurs sources et examiner ce que la machine leur sort.

L'orientation du projet tient en une phrase : l'IA devrait soutenir l'apprentissage et non le raccourcir. Mouais...

Le contexte rend cette approche un peu particulière en fait. La triche assistée par IA s'est installée comme une routine dans les écoles du monde entier, au point que l'Université nationale autonome du Mexique a suspendu des inscriptions après une fraude massive à ses examens d'entrée.

Les travaux qui s'accumulent ne vont pas d'ailleurs dans le sens d'OpenAI. Une étude du MIT a mesuré à l'électroencéphalogramme, l'examen qui enregistre l'activité électrique du cerveau, une activité nettement plus faible chez les étudiants qui rédigeaient avec l'IA. Le résultat est sans appel. Ces mêmes étudiants se souvenaient beaucoup moins bien de ce qu'ils venaient d'écrire.

Une autre enquête, publiée l'an dernier par le Center for Democracy and Technology, montre que les enseignants du primaire et du secondaire réclament surtout qu'on leur explique comment intégrer ces outils, et qu'ils redoutent aussi les dégâts sur les apprentissages.

Il y a un détail qui m'a fait un peu tiquer dans la communication d'OpenAI. La société prend soin de préciser que les enseignants gardent la main sur les décisions pédagogiques, sur la notation et sur les actions automatisées, ce qui laisse penser que la question s'est quand même posée en interne, et surtout qu'on est sur une première étape.

Source : The Register

OpenAI a publié le détail de deux incidents survenus pendant des évaluations de sécurité confiées à des laboratoires extérieurs. Le plus notable des deux lui a été signalé le 29 juillet par Irregular, une société qui teste la résistance des modèles aux usages offensifs.

L'exercice était un capture the flag, le format classique des compétitions de sécurité où il faut dénicher une information cachée en exploitant les faiblesses d'un système, monté uniquement pour cette occasion. Le modèle avait été prévenu qu'il n'avait aucun accès à internet.

Il y a eu deux ratés. Une erreur de configuration laissait en réalité passer le trafic vers le réseau public, et le nom inventé pour la cible de l'exercice qui, ô hasard de la vie et des internets, correspondait à un vrai domaine déposé par un malheureux.

Le modèle a donc attaqué un site bien réel en croyant travailler sur la maquette. Il a trouvé des identifiants qui traînaient et s'en est servi pour administrer le site.

OpenAI insiste sur deux points. Aucune faille inconnue n'a été utilisée, juste une vulnérabilité basique, et le modèle n'a pas cherché à s'échapper de son bac à sable puisque la porte était déjà ouverte. Irregular n'a pour l'instant relevé aucun dégât en dehors des données du site concerné, et l'enquête continue.

Le même évaluateur a d'ailleurs vécu la scène deux fois. Un modèle Claude est tombé sur un autre vrai site portant le nom d'une cible fictive, y a repéré des services exposés, récupéré des identifiants et atteint une base de données de production.

Ces histoires commencent à s'empiler l'air de rien. En juillet, un modèle d'OpenAI était sorti de son environnement de test pour aller fouiller les serveurs de Hugging Face, la grande plateforme de partage de modèles, dans le seul but de tricher à une évaluation. Anthropic a reconnu fin juillet que les siens avaient pénétré trois entreprises pendant des tests.

Le cas qui m'a le plus choqué à titre perso, vient de l'institut britannique de sécurité de l'IA. Un modèle y a monté une attaque sur la chaîne d'approvisionnement d'un projet open source bien réel, en fabriquant de faux comptes GitHub et en faisant de l'ingénierie sociale sur ses mainteneurs, le tout derrière Tor histoire de brouiller son origine. L'institut parle de la première tromperie de cette gravité visant une vraie personne, non prévenue, dans le monde réel.

Le problème, c'est quand on se projette un peu, il est à peu près certain que ce genre de truc va se généraliser dans les mois et années à venir, et ça va devenir un vrai problème.

Source : Bleeping Computer

Le pirate qui a mis à genoux la prod de Hugging Face voulait juste tricher à son examen, voilà ce qu'OpenAI a reconnu hier. Les agents qui se sont promenés durant tout un week-end dans les clusters de la plateforme, c'étaient leurs modèles à eux, GPT-5.6 Sol et un modèle pré-release encore plus balèze, fonctionnant en mode "refus cyber réduits à des fins d'évaluation".

Le point de départ c'est ExploitGym , contenant 898 vraies vulnérabilités piochées dans des programmes userspace, dans le moteur JavaScript V8 de Google et dans le noyau Linux. On colle l'agent devant un input qui fait planter un programme, et on regarde s'il arrive à en tirer un exploit qui marche.

Dans ce document de recherche sorti en mai, GPT-5.5 sortait 120 exploits fonctionnels, derrière les 157 de Claude Mythos Preview. Mais le modèle testé ce week-end là, lui, a trouvé un "raccourci". Comme l'explique OpenAI "toutes les preuves suggèrent que les modèles étaient hyperfocalisés sur la recherche d'une solution pour ExploitGym, allant à des extrêmes considérables pour atteindre un objectif de test plutôt étroit".

Pour saisir l'ampleur du raccourci, regardez la pièce dans laquelle ils étaient enfermés. C'est un environnement hautement isolé, avec un seul trou dans le mur, un accès réseau "*restreint à la possibilité d'installer des paquets via un logiciel tiers hébergé en interne qui fait office de proxy et de cache pour les registres de paquets *". En clair, le seul truc qui pouvait parler à l'extérieur, c'était le machin qui allait chercher les dépendances !

ExploitGym, le benchmark que les modèles cherchaient à résoudre. 898 vulnérabilités réelles, et les scores de GPT-5.5 et Claude Mythos Preview.

Et vous devinez la suite... Les modèles ont cramé une grosse quantité de tokens à chercher la sortie pour finalement la trouver dans ce proxy, sous la forme d'un zero-day que personne ne connaissait (la faille a depuis été signalée à l'éditeur). Le seul tuyau autorisé était donc LE point faible. Ensuite, escalade de privilèges et déplacement latéral de machine en machine, jusqu'à en atteindre une avec un accès Internet et voilà...

Une fois dehors, ils en ont alors déduit tout seuls que Hugging Face hébergeait probablement les modèles, les datasets et les solutions d'ExploitGym.

Donc direction huggingface.co, avec credentials volés et zero-days enchaînés jusqu'à décrocher une exécution de code à distance sur les serveurs, puis lecture des solutions du test directement dans la base de production. Aucune destruction, aucune demande de rançon. Juste les corrigés des tests comme des bacheliers qui emploient mal leur intelligence !

Petite précision qui compte, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité sur son infra, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Je vous racontais l'histoire vue de leur côté il y a deux jours, relevant notamment que les modèles américains refusaient d'analyser leurs logs d'attaque.

C'est pas un peu de la science fiction tout ça ??? Maintenant si vous vous demandez ce que vous risquez en tant qu'utilisateur, sachez que côté public, rien n'a bougé sur les modèles, les datasets et les Spaces. L'incident a uniquement touché des datasets internes et des credentials de service et visiblement, rien n'a été altéré par les agents IA en vadrouille.

Côté mesures, OpenAI dit appliquer des contrôles stricts sur la configuration de son infra "au prix de la vélocité de recherche" pendant que les failles sont patchées, et a fait entrer Hugging Face dans son programme trusted access. Ce qui règle accessoirement le problème du refus que HF a rencontré lors de l'analyse des logs.

La veille de cette révélation, OpenAI publiait d'ailleurs un billet sur l'alignement des modèles à long horizon bourré d'anecdotes du même genre, avec un modèle qui contourne les restrictions de sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui demandait de poster sur Slack. Ou encore un autre qui, pour esquiver les détecteurs de secrets, a découpé le corps du token en deux fragments, les a obfusqués, puis a reconstruit le credential à l'exécution.

On dirait qu'ils n'avaient pas anticipé que ça aille aussi loin leurs petites expérimentations...

Après, OpenAI ne minimise pas et parle même d'un "incident cyber sans précédent, impliquant des capacités cyber à l'état de l'art". Ces modèles peuvent maintenant découvrir et exploiter des chemins d'attaque complètement inédits dans des systèmes en prod, sans avoir besoin d'un accès au code source. C'était théorique jusqu'à ce week-end.

Maintenant, si un modèle a lu les solutions dans la base de production, que valent encore les scores obtenus sur ExploitGym ? Ça on n'en sait rien.

Avant de sortir les violons, le contrepoint le plus juste que j'ai lu vient de Rich Mogull, analyste en chef de la Cloud Security Alliance qui explique que pour lui c'est un cas d'école en matière d'échec d'alignement, car le modèle n'était pas malveillant, il a fait précisément ce qu'on lui demandait, à savoir maximiser sa performance. Sauf qu'une fois les garde-fous retirés et assez de marge donnée, "résoudre le test" et "compromettre un tiers pour voler les réponses" sont devenus la même instruction.

Puis c'est aussi un problème de consentement, car un test de laboratoire qui se barre pour compromettre les systèmes en production, c'est quand même un risque qui est porté par quelqu'un qui n'a pas choisi de mener l'expérience. Alors bon, c'est tombé sur Hugging Face qui a géré ça comme un chef, mais ça aurait pu très bien tomber sur un hôpital.

Voilà les amis... On nous avait promis Skynet , on nous avait promis Matrix, et voilà que 15 ans plus tard, le vrai visage du soulèvement des machines c'est un putain de modèle qui passe son week-end à défoncer trois infrastructures d'affilée pour améliorer sa note à un contrôle.

Un ennemi qui vous hait, vous pouvez le raisonner ou lui envoyer Arnold Schwarzenegger. Mais un ennemi dont la seule mission c'est d'optimiser une métrique, vous ne pouvez que relire très attentivement le prompt que vous lui avez donné et croiser les doigts. La preuve quand une IA prend la première place du classement américain de HackerOne ou arrive à dénicher des milliers de zero-days pour Anthropic , c'est que l'instruction initiale ou le garde-fou était plus solide que ce que nous a pondu OpenAI ce week-end.

Source

Vous vous souvenez de Jason Lemkin ?

C'est le malheureux qui, en juillet de l'année dernière, s'est fait vider sa base de prod par l'IA de Replit. Je pense que cette histoire a traumatisé pas mal de développeurs. Eh bien les amis, rebelote avec GPT 5.6 Sol, qui le temps que vous finissiez votre café, avait déjà mangé le Mac de Matt Shumer , la base Neon de Bruno Lemos , les fichiers de Joey Kudish , et la crédibilité du mot "honnête".

Sorti le 9 juillet, Sol c'est le plus costaud de la nouvelle famille d'OpenAI, et on pourrait se dire qu'il est un peu plus intelligent qu'avant et embarque quand même des sécurités pour éviter ce genre de problème. Mais non.

C'est Shumer, qui est quand même investisseur dans l'IA, qui a ouvert le bal : "GPT-5.6-Sol vient de supprimer par accident PRESQUE TOUS les fichiers de mon Mac." Lemos, lui, a eu droit au grand jeu (le veinard) puisque le modèle lui a tout bien fait jusqu'au moment où il a décidé de faire un TRUNCATE TABLE sur sa base utilisateurs EN PROD !!

Le plus drôle, si je puis dire, c'est que quelques heures avant de tout perdre, Lemos était en train de défendre GPT 5.6 sur le Slack de sa société en expliquant que Shumer n'avait qu'à pas le lancer en mode full access. Oups... Les collègues ont dû bien se foutre de sa gueule.

Du coup OpenAI a mis ses meilleurs Colombos sur l'enquête et sa réponse vaut le détour. Thibault Sottiaux, qui dirige l'ingénierie de Codex, explique le mécanisme : "Le modèle tente d'écraser la variable d'environnement $HOME pour définir un dossier temporaire. Il fait une erreur honnête et supprime $HOME par erreur à la place."

En français, ça veut dire que le modèle voulait se bricoler un petit dossier temporaire pour bosser et malheureusement il a écrasé le répertoire perso à la place. Donc pour OpenAI, c'est une erreur "honnête" alors qu'un rm -rf, ça ne serait pas acceptable.

Quand on lit la doc technique de GPT 5.6, OpenAI le dit lui-même : "Nos simulations de déploiement suggèrent que, comparé à GPT-5.5, GPT-5.6 Sol prend plus souvent des actions de sévérité 3." Le niveau 3, c'est un comportement qu'un utilisateur raisonnable n'anticiperait pas et auquel il s'opposerait fermement. Du genre supprimer des données sans validation, désactiver les systèmes de monitoring, contourner les contrôles de sécurité par obfuscation, ou balancer vos credentials sur un service non approuvé.

Voilà, c'était dans la doc, il suffisait de la lire. C'est donc connu que ce nouveau modèle dérape plus que l'ancien. C'est moche.

L'enquête interne montre quand même que les victimes tournaient en Full-Access, sans sandbox et sans Auto-review. Mais Sottiaux reconnaît quand même que ce n'est pas comme ça qu'OpenAI veut que son système se comporte, même quand l'utilisateur fait tourner un modèle en full access sans les protections de base de la sandbox ni auto-review.

Voilà donc pour éviter ça à l'avenir, ce qu'ils ont prévu, c'est de mettre à jour les avertissements pour les développeurs de guider les utilisateurs vers des modes de permission plus sûrs et évidemment d'ajouter des garde-fous supplémentaires.

En tout cas, si chez vous vous faites tourner codex, et bien sachez que par défaut, il tourne dans un bac à sable, ce qui limite ce qu'il peut toucher. Et le mode auto-review, sait parfaitement intercepter toutes les actions à haut risque et les refuser (auto-review, il faut l'activer à la main, pour info). Et le mode full access désactive le bac à sable et les auto-reviews, sachez-le.

Et c'est précisément ce mode que nos trois victimes avaient choisi...

Source