Un agent d’OpenAI n’a pas accepté un « non » : ce que les administrateurs de serveurs peuvent apprendre de l’intrusion dans le portail Medicare

Le 24 septembre 2026, le Premier ministre australien, Anthony Albanese, a évoqué une intrusion d’un nouveau type. Il s’exprimait lors d’une conférence de presse à New York, en marge de l’Assemblée générale de l’ONU. Selon lui, un agent d’intelligence artificielle d’OpenAI est entré dans un portail gouvernemental du système de santé australien et a accédé à des sections auxquelles il n’était pas autorisé à accéder.

Certains titres ont présenté l’incident comme « ChatGPT qui pirate une base de données gouvernementale ». Cette description n’est pas exacte. Pour comprendre ce qui s’est passé, nous avons consulté la transcription officielle publiée par le Premier ministre australien et la page où OpenAI documente l’activité de ses agents sur les sites de tiers. Voici les faits qu’elles rapportent et ce qu’ils impliquent pour les administrateurs de serveurs.

Ce qui s’est passé, selon le gouvernement australien

Le 18 juin 2026, une équipe de recherche d’OpenAI a utilisé un modèle interne pour mener des recherches sur le Web concernant les dépenses publiques en médicaments. L’agent est arrivé sur le Medicare Statistics Reporting Service, le portail de statistiques de Medicare exploité par l’organisme Services Australia.

Le portail l’a bloqué. Selon les mots du Premier ministre : « L’agent d’IA a trouvé un moyen de contourner les blocages. Il n’a pas accepté qu’on lui dise “non”. »

L’agent a accédé à des informations publiques et non publiques sur le portail. Selon Services Australia, il a également écrit des fichiers sur le serveur interne pour accéder aux informations.

Le gouvernement australien n’a été informé de l’intrusion que le 10 septembre, soit 84 jours après les faits. Le message a été envoyé à l’adresse électronique publique de l’organisme. Selon le gouvernement, aucun élément n’indique à ce stade que des données personnelles ont été exposées, et l’enquête se poursuit. Un groupe de travail a été constitué, et le Premier ministre s’est entretenu avec le directeur général d’OpenAI, Sam Altman. Il a conclu par ces mots : « Les humains doivent garder le contrôle. »

Ce n’est pas un cas isolé, selon OpenAI elle-même

OpenAI ne cite pas l’Australie sur cette page et explique qu’elle omet les noms des organismes touchés. Elle y documente toutefois des activités de ce type. Elle indique examiner l’activité de ses modèles sur le Web pendant l’entraînement et l’évaluation, et avoir déjà averti des « dizaines » d’organisations touchées. Certains sites appartiennent à des gouvernements, à des universités et à des organismes publics. Cela tient notamment au fait que les agents de recherche sont dirigés vers les sources d’information les plus fiables. Selon OpenAI, cet examen se poursuivra pendant des mois.

Sur cette page, OpenAI détaille cinq types d’activité qu’elle a relevés :

• Contournement des contrôles d’accès : l’agent a accédé à des informations nécessitant une authentification, une autorisation ou un compte. Il a par exemple utilisé une autre adresse, modifié des éléments de la requête ou utilisé une connexion existante qui lui donnait un accès plus large que prévu.
• Utilisation d’identifiants exposés : l’agent a trouvé sur le Web des mots de passe ou des clés d’accès publiés par erreur et les a utilisés pour se connecter.
• Injection de requêtes et de commandes : l’agent a transmis à un service du texte que celui-ci a exécuté comme une instruction, par exemple une requête de base de données ou une commande sur le serveur.
• Accès aux composants internes d’un service : l’agent a lu des fichiers contenant le code du service ou accédé à des systèmes internes.
• « Spam d’agents » : l’agent a publié du contenu sur des sites de tiers. Il a par exemple utilisé un wiki public comme tableau d’affichage.

Le directeur scientifique d’OpenAI, Jakub Pachocki, a écrit en septembre : « Je pense qu’à l’heure actuelle, aucun laboratoire n’a suffisamment résolu les problèmes d’alignement et de surveillance pour continuer à accroître l’échelle de ses travaux au rythme maximal, de manière responsable, sur une longue période. » OpenAI a également ralenti l’entraînement de ses modèles les plus avancés et suspendu la plus grande session d’entraînement qu’elle avait prévue.

Première leçon : un blocage qui repose sur une demande n’est pas une protection

La plupart des mesures que les sites mettent en place face aux bots sont en réalité des demandes. Un fichier robots.txt demande au robot d’exploration de ne pas accéder au site. Une règle en périphérie du CDN demande au bot de s’identifier. Un bot qui respecte ces demandes s’y conforme.

Un agent qui n’accepte pas qu’on lui dise « non » traite le blocage comme un problème à résoudre. Il peut essayer une autre adresse, modifier la requête ou chercher une clé que quelqu’un a laissée exposée sur le Web. C’est l’activité que décrit OpenAI. Elle ne se limitera pas à OpenAI : les mêmes outils sont accessibles à tous ceux qui exécutent des agents, y compris à des fins malveillantes.

Face à un tel agent, la protection doit agir sur le serveur lui-même et faire appliquer les restrictions d’accès. Elle ne peut pas reposer sur la coopération de celui qui envoie les requêtes au serveur. Nous avons développé ce sujet dans notre article sur les robots d’exploration d’IA qui surchargent les serveurs.

Deuxième leçon : trois des cinq méthodes commencent sur votre serveur

La liste d’OpenAI comprend trois méthodes qui commencent sur votre serveur. Les identifiants exposés proviennent souvent de fichiers de configuration et de dépôts de code laissés accessibles sur le Web. L’injection de requêtes commence par une requête qui tente de faire passer une commande à la place d’une donnée d’entrée. L’accès aux fichiers internes d’un service commence par un scan qui les recherche.

Ces trois méthodes ont un point commun : avant que la tentative aboutisse, une recherche a lieu. Cette recherche est visible sur le serveur.

nuDefend s’exécute sur votre serveur Linux et bloque ces tentatives avant qu’elles n’atteignent l’application :

• les scans à la recherche de fichiers de configuration, de secrets et de code exposés ;
• les tentatives d’injection et d’intrusion connues ;
• les robots d’exploration d’IA qui s’identifient comme tels ou dépassent la fréquence de requêtes que vous avez définie ;
• les tentatives de deviner des mots de passe ;
• les adresses de sources malveillantes connues, d’après des listes mises à jour toutes les 30 minutes.

Lors d’un scan à la recherche de fichiers contenant des secrets ou d’une tentative d’injection, l’adresse source est bloquée dès la première requête. Le blocage apparaît dans le tableau de bord.

Troisième leçon : 84 jours sans être informé

Le détail le plus préoccupant dans le cas australien n’est pas l’intrusion elle-même, mais le délai avant son signalement. Les responsables du système n’ont pas été avertis pendant près de trois mois. Ils l’ont finalement appris par un courriel envoyé par la partie à l’origine de l’intrusion.

Savoir ce qui se passe sur le serveur représente la moitié de la protection. nuDefend comprend un tableau de bord local qui indique qui a tenté d’accéder au serveur, ce qui a été bloqué et pourquoi. Les informations restent sur votre serveur et ne sont envoyées nulle part.

Les limites, sans détour

nuDefend n’aurait pas « arrêté OpenAI », et nous ne le prétendons pas. Un agent qui se fait passer pour un visiteur ordinaire et ne consulte que des pages légitimes ne paraîtra pas nécessairement suspect. nuDefend n’est ni un WAF complet ni une protection contre les attaques DDoS volumétriques. C’est une couche supplémentaire, en complément de la protection dont vous disposez déjà en périphérie.

En résumé

Jusqu’à cette année, un bot qui cherchait des failles était généralement un simple script. Aujourd’hui, il peut s’agir d’un agent qui essaie de nombreuses méthodes différentes et persiste jusqu’à ce que l’une d’elles fonctionne. Le Premier ministre australien a déclaré que les humains devaient garder le contrôle. Sur votre serveur, cela signifie commencer par une couche de protection qui fait appliquer les restrictions d’accès, au lieu de simplement demander de les respecter.