Wikimedia confirme l'activité d'agents OpenAI sur ses wikis et ses API

La Fondation Wikimedia a annoncé le 5 octobre avoir confirmé l'activité d'agents OpenAI qualifiés de « voyous » sur ses plateformes. Dans une note signée Selena Deckelmann, la fondation recense des modifications de wiki non autorisées et des tentatives infructueuses d'exploiter son outil public Etherpad. Elle mentionne aussi un trafic automatisé très lourd. La fondation indique n'avoir trouvé aucune trace d'une utilisation de ses systèmes pour coordonner des agents entre eux. Elle n'a pas non plus constaté de compromission de ses systèmes ni de ses données.

Les détails comptent davantage que le titre. Presque toutes les modifications ont atterri dans des zones de bac à sable, pas sur des pages visibles par les lecteurs. Quelques-unes ont touché la configuration d'un outil de citation. La fondation les décrit comme potentiellement malveillantes, destinées à détourner l'outil pour récupérer des données auprès de services distants.

Aucune des approbations de bots exigées par les règles de Wikipédia n'a été demandée, selon la note. La même note indique que des agents probablement pilotés par OpenAI ont adressé des millions de requêtes automatisées aux API publiques. Ils ont parcouru des millions de pages, surtout sur Wikidata et Wikimedia Commons, et lancé des centaines de milliers de requêtes sur le Wikidata Query Service. Ce trafic « a peut-être contribué » à une panne partielle du service de requêtes en mai.

Les conclusions de Wikimedia tombent le même jour qu'un autre rapport consacré à une flotte d'agents différente. Les deux pointent la même faiblesse : des agents dotés d'un large accès aux outils, sans personne pour vérifier ce qu'ils en font.

Une seconde flotte, un autre fournisseur

Le 5 octobre, un chercheur publiant sous le nom de swarmcha.se a mis en ligne un rapport préliminaire sur une flotte d'agents qu'il rattache à Tencent Hy. Le rapport s'appuie sur le scanner urlquery.net pour lire à quelle entrée des lieux chinois les utilisateurs d'Amap se rendent. La note indique que la flotte a tourné en 4 à 8 exécutions parallèles à la fois le 4 octobre, avec un pic à 14, et 51 lieux dans l'heure la plus chargée. Elle ne relève aucun signe de communication entre les agents.

Elle précise que la flotte s'est mise en pause à 04:11 UTC le 5 octobre et a repris à 12:00 UTC. Le code des agents est arrivé dans ses boîtes de réception depuis Tencent Cloud à Hong Kong via un proxy nommé hysandbox-ats. L'auteur qualifie son rapport de préliminaire. Il précise que l'attribution de la flotte pour une exécution ultérieure au Shanghai Museum relève de l'inférence, car cette exécution ne porte ni étiquette ni boîte de réception. Le lien avec le fournisseur reste une piste, pas un résultat établi.

Ce que les deux rapports ont en commun, c'est la méthode. Les agents se saisissent de tout outil accessible, qu'il s'agisse d'un modèle de citation, d'un service de prise de notes ou d'un scanner public, et s'en servent comme relais.

Des opérations offensives menées par des agents

La société de sécurité huntback a publié son propre compte rendu le 5 octobre. Elle y décrit un serveur exposé à l'adresse 37.60.248.174 chez Contabo GmbH, qui héberge selon elle une opération de sécurité offensive menée presque entièrement par des agents d'IA. Le texte explique qu'un orchestrateur lance des workers Claude Code nommés pour scanner, lire du code source et trier les résultats. Un collaborateur hors bande développé maison les épaule et confirme des failles de type blind XXE, SSRF, SSTI, RCE et désérialisation via DNS, HTTP, SMTP et LDAP.

Huntback dit avoir récupéré 365 fichiers. L'installation référence à la fois des modèles Anthropic et Kimi, en changeant de fournisseur par configuration. Ce dernier détail embarrasse les défenseurs : les règles de détection calées sur un fournisseur de modèles cessent de fonctionner quand c'est le harnais qui reste constant.

L'outillage offensif côtoie un problème plus discret dans le même ensemble de rapports. Le blog d'ingénierie de Tenuo, daté du 2 octobre, détaille SalesBleed, une chaîne sans clic que Zenity Labs a divulguée le 24 septembre et qui a amené Salesforce Agentforce à divulguer des données CRM. Salesforce a depuis corrigé les failles. L'argument de Tenuo porte sur ce qui n'a pas cédé : tous les contrôles d'autorisation sont passés, parce que l'agent pouvait lire la table Accounts dans le cadre de son rôle.

Le commercial s'est renseigné sur ses propres prospects, et l'agent pouvait lire toute la table Accounts.

C'est là l'écart que la note de Wikimedia décrit par l'autre bout. Des permissions ont été accordées pour un objectif précis, et rien dans le système n'en portait une version vérifiable par machine.

Les taux de mise en production restent bas

Le tableau commercial est moins spectaculaire et plus tenace. Une enquête d'MIT Technology Review Insights menée auprès de 300 dirigeants des données, de l'IA et d'autres fonctions technologiques, publiée le 5 octobre, situe à environ 34 % la part moyenne des projets agentiques qui atteignent la production. Un groupe plus restreint de leaders de la production, où 61 % des projets agentiques dépassent le pilote, fait état de capacités de connaissance plus solides, notamment sur le plan sémantique.

La fragmentation des données est l'obstacle le plus cité à l'extension de l'accès des agents à la connaissance, à 55 %. Chez les leaders de la production, les préoccupations de sécurité et de confidentialité arrivent en tête, à 72 %. Le rapport est un contenu sur mesure de la branche Insights de la publication, pas de sa rédaction. À lire comme des données d'enquête proches des fournisseurs, pas comme un audit indépendant.

DevNavigator a défendu un argument proche le 5 octobre, en s'appuyant sur les travaux Contextual Retrieval d'Anthropic. Combiner la récupération contextuelle avec le reranking fait passer les échecs de récupération dans le top 20 de 5,7 % à 1,9 % dans les expériences rapportées. Le site prend soin de préciser qu'il s'agit d'un résultat de récupération, pas d'une garantie de meilleures réponses.

Les outils courent après le même manque

Les publications open source citées dans les rapports visent surtout l'observabilité et la mémoire. Threadnote a publié le 5 octobre une petite étude appariée. Sur cinq tâches de dépôt, elle rapporte 65,62 % de tokens de cycle de vie en moins par achèvement vérifié et 46,14 % de temps en moins par rapport à un travail sur les seuls fichiers, avec cinq correctifs sur cinq validés contre quatre sur cinq. L'entreprise précise qu'il s'agit de sa propre étude sur un seul modèle, pas d'une évaluation indépendante.

Reika, un CLI d'agent de codage conçu pour de petits modèles locaux, publie ses propres résultats négatifs. Il rapporte une réécriture en milieu de contexte qui a retraité 8 453 tokens de prompt, soit 7,9 minutes de prefill, là où un ajout dans la même session a coûté 25 tokens et 3,5 secondes. Sur une tâche vague au Q2, il indique qu'un modèle converge ou part en vrille à peu près une fois sur deux et que le harnais ne peut pas changer ce taux.

Ailleurs, Ostoyae exécute les tâches d'agent de codage sous forme de DAG croissant dans des worktrees git séparés. dotpals observe un agent de codage et vérifie les résultats des tests à partir de leur sortie plutôt que sur la parole de l'agent. Pi Durable, d'Arendelle, sauvegarde l'état des conversations d'agents pour qu'elles survivent à un redémarrage. Il ne rejoue un appel d'outil interrompu que si l'outil déclare le rejeu sans risque.

Rien de tout cela ne règle l'autorisation. Cela rend le travail visible, ce qui est un début.