Mysterium a exposé des points de terminaison d’IA, et l’auto-hébergement a perdu son alibi de sécurité

Mysterium a exposé des points de terminaison d’IA à une échelle qui transforme une erreur de configuration en avertissement pour toute l’industrie. Ses chercheurs ont identifié 36 769 systèmes accessibles, alors que seuls 741 renvoyaient une demande d’authentification HTTP.

L’étude du 10 septembre portait sur des serveurs de modèles, des interfaces de chat, des générateurs d’agents et des consoles de bases vectorielles. Ces composants constituent la couche opérationnelle entre un modèle d’IA et les personnes, documents, identifiants et applications qui l’entourent.

Cela crée une tension inconfortable pour l’IA auto-hébergée. Les entreprises exécutent souvent des modèles localement afin de conserver le contrôle des prompts et des données sensibles. Pourtant, de nombreux déploiements semblent accessibles sans barrière au niveau du réseau, ce qui reporte la confiance sur la sécurité applicative, les correctifs et une configuration adéquate.

Ce nombre ne prouve pas que les 36 769 systèmes ont tous exposé des informations privées. Certaines applications pouvaient encore exiger une connexion après leur chargement. Toutefois, les conclusions montrent que des milliers de services d’IA se signalent directement aux scanners internet.

Cette distinction est importante. Une page de connexion visible reste une application exposée qui doit résister à de nouvelles vulnérabilités, aux mots de passe volés, aux paramètres par défaut insuffisants et aux sondages automatisés. Un service placé derrière un réseau privé ou une passerelle authentifiée présente une cible plus réduite.

La comparaison ne se résume donc pas à l’IA locale contre l’IA hébergée. Elle oppose le contrôle en théorie au contrôle dans le déploiement. Les résultats de Mysterium suggèrent que les organisations choisissent l’auto-hébergement sans exploiter systématiquement la frontière de sécurité qui lui donne sa valeur.

Les points de terminaison d’IA exposés par Mysterium dans toute la pile opérationnelle d’IA

La conclusion centrale ne concerne pas un seul produit vulnérable. Elle concerne une pile d’IA identifiable et cartographiable depuis l’internet public.

Mysterium indique que ses chercheurs ont utilisé un index de scan tiers plutôt que de sonder directement les machines identifiées. Le recensement original recherchait des empreintes de services, notamment des titres de pages, des textes de réponse et des ports associés aux logiciels d’IA courants.

L’ensemble de données final contenait 36 769 points de terminaison s’identifiant eux-mêmes. Les produits de service de modèles représentaient la plus grande part de cette population, menée par 18 529 instances Open WebUI. Open WebUI fournit une interface reposant sur navigateur pour interagir avec des modèles de langage hébergés localement.

Une seule de ces instances Open WebUI a renvoyé une demande d’authentification HTTP durant l’étude. Cela n’établit pas que les applications restantes autorisaient un accès illimité aux comptes. Cela établit en revanche que presque aucune ne disposait d’une barrière HTTP détectable devant l’application.

Ollama, un service permettant de télécharger et d’exécuter des modèles sur du matériel local, représentait 6 935 autres points de terminaison confirmés. Chacun renvoyait anonymement la réponse racine du produit, selon Mysterium. Parmi eux, 729 ont renvoyé une demande d’authentification.

Les chercheurs ont également identifié 4 880 points de terminaison vLLM, dont trois renvoyaient une demande. vLLM est un serveur d’inférence, ce qui signifie qu’il accepte des requêtes et les exécute via un modèle de langage pour produire des réponses.

Des groupes plus petits comprenaient 150 points de terminaison LocalAI, 69 serveurs llama.cpp et 63 déploiements Xinference. Ces produits s’adressent à des publics différents, mais remplissent un même objectif opérationnel. Ils rendent les modèles accessibles aux applications ou aux utilisateurs.

L’ensemble de données allait au-delà de l’inférence. Mysterium a comptabilisé 5 223 points de terminaison associés aux générateurs d’agents et aux outils de workflow, notamment Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow et Open WebUI Pipelines.

Cette catégorie présente un profil de risque différent. Un serveur d’inférence traite des prompts, mais un générateur d’agents connecte souvent les modèles à des bases de données, des systèmes de messagerie, des services cloud et des applications internes. Il peut stocker des jetons ou invoquer des outils disposant de véritables autorisations.

Flowise représentait 1 341 points de terminaison accessibles, dont aucun ne renvoyait de demande d’authentification. L’étude a également dénombré 891 déploiements RAGFlow, 792 points de terminaison Dify, 788 points de terminaison ComfyUI et 675 instances n8n.

La visibilité des bases vectorielles était bien plus faible. Les chercheurs ont trouvé 914 consoles Milvus Attu et six points de terminaison Weaviate. Une base vectorielle conserve des représentations numériques de contenu afin qu’une application d’IA puisse retrouver des documents pertinents pendant une conversation.

Ces chiffres ne doivent pas être interprétés comme la preuve que les bases de données vectorielles sont rarement exposées. Mysterium a indiqué que sa source ne scannait pas les ports natifs de deux produits majeurs. Le recensement a principalement capturé les consoles web visibles, laissant la catégorie la plus sensible pour les données insuffisamment mesurée.

Le rapport a également trouvé 22 024 réponses supplémentaires sur le port par défaut d’Ollama. Les chercheurs les ont exclues du total confirmé, car une réponse de port seule fournissait une preuve moins solide qu’une bannière de produit reconnaissable.

Cette exclusion prudente renforce la conclusion principale. Le chiffre de 36 769 constitue un plancher confirmé dans un index de scan, et non un inventaire complet de l’infrastructure d’IA publique.

Pourquoi la sécurité de l’IA auto-hébergée échoue au périmètre

L’auto-hébergement ne protège les données que lorsque l’organisation contrôle également qui peut atteindre l’hôte.

L’argument en faveur des modèles locaux commence généralement par la maîtrise des données. Les prompts, les documents téléversés, les passages récupérés et les réponses générées peuvent rester sur des équipements contrôlés par l’organisation. Cet arrangement peut réduire la dépendance envers un fournisseur externe de modèles.

Cependant, l’emplacement ne crée pas à lui seul la confidentialité. Un modèle exécuté sur le matériel de l’entreprise peut rester public si son service écoute sur une adresse exposée à internet. Un déploiement interne peut devenir externe via une règle de pare-feu, un groupe de sécurité cloud, un paramètre de conteneur ou un tunnel configuré à la hâte.

De nombreux produits d’IA locale n’écoutent par défaut que sur l’adresse de bouclage. Le bouclage limite les connexions aux logiciels exécutés sur la même machine. Les opérateurs remplacent parfois cette adresse par 0.0.0.0, ce qui permet au service d’accepter des connexions via chaque interface réseau disponible.

Cette modification est utile lorsqu’un développeur a besoin d’un accès depuis un autre appareil. Elle devient dangereuse lorsque le réseau environnant autorise également le trafic entrant depuis internet.

Un proxy inverse peut fournir une couche d’authentification avant que les requêtes n’atteignent l’application d’IA. Un réseau privé virtuel peut maintenir le service hors de l’espace d’adresses publiques. Une liste d’autorisation IP peut limiter l’accès aux réseaux approuvés.

Mysterium a trouvé peu d’éléments attestant de ces protections au niveau HTTP. Sur l’ensemble du recensement, seuls 2,02 % des points de terminaison ont renvoyé une demande d’authentification. Cinq requêtes de produits étaient incomplètes en raison de limites de débit de la source, de sorte que les chercheurs n’ont pas attribué de décompte des demandes à ces groupes.

L’interprétation restrictive est importante. Une demande HTTP n’est pas le seul contrôle de sécurité possible. Une application peut se charger publiquement tout en imposant ses propres règles de connexion, de session ou d’autorisation.

Toutefois, s’appuyer sur l’authentification applicative modifie le modèle de menace. L’application devient continuellement accessible aux scanners et aux attaquants. Chaque correctif manqué, erreur d’autorisation, route administrative exposée et identifiant par défaut gagne en importance.

Les dossiers de vulnérabilités récents expliquent pourquoi cette préoccupation est concrète. Les avis de sécurité de Tenable en 2026 ont répertorié des problèmes de haute gravité affectant Open WebUI et plusieurs composants Flowise.

Les avis concernant Flowise comprenaient une traversée de chemin, une injection de requêtes de graphe, l’absence d’authentification sur les points de terminaison NVIDIA NIM et une divulgation d’informations personnelles. Des avis distincts portaient sur l’exposition d’identifiants, les échecs d’autorisation et les écritures de fichiers arbitraires dans d’autres outils d’IA.

Ces dossiers ne signifient pas que chaque déploiement visible depuis internet est vulnérable. Les versions, configurations et contrôles compensatoires diffèrent. Ils démontrent que la couche applicative ne peut pas remplacer durablement l’isolation réseau.

Le délai d’application des correctifs crée un autre problème. Un développeur peut lancer une preuve de concept utile en quelques minutes, puis la laisser fonctionner pendant des mois. Le service pourrait ne jamais être intégré à l’inventaire des actifs utilisé par les équipes de sécurité et d’infrastructure.

Ce cycle de vie produit une IA fantôme, c’est-à-dire des systèmes adoptés ou construits sans supervision organisationnelle habituelle. Le projet reste visible pour son créateur, mais invisible pour les équipes responsables des revues d’accès, des mises à jour, des journaux et de la réponse aux incidents.

Le résultat est une frontière de sécurité bâtie sur des suppositions. Le data scientist suppose que le pare-feu cloud bloque le trafic. L’équipe d’infrastructure suppose que l’application exige une authentification. Le propriétaire de l’application suppose que le déploiement est temporaire.

Un scanner internet teste ces suppositions sans avoir besoin du contexte organisationnel. Si le produit répond, s’identifie et présente une surface applicative, il a déjà franchi une frontière que l’auto-hébergement était censé préserver.

Les générateurs d’agents transforment l’exposition en risque de chaîne d’approvisionnement

Les points de terminaison d’IA exposés les plus graves font plus que répondre à des questions, car ils peuvent agir au moyen d’identifiants et de systèmes connectés.

Une chaîne d’approvisionnement de l’IA comprend le modèle, les paquets logiciels, l’infrastructure de service, les bases de récupération, les plugins, les outils et les services externes utilisés pour produire un résultat. Une faiblesse dans n’importe quel composant connecté peut influer sur le système ou étendre l’accès d’un attaquant.

Les chaînes d’approvisionnement logicielles traditionnelles portent déjà un risque hérité. Les applications dépendent de paquets maintenus par des développeurs externes, d’images de conteneurs construites ailleurs et de workflows automatisés détenant des identifiants de déploiement.

Les applications d’IA ajoutent à cette chaîne des prompts, des fichiers de modèles, du contenu de récupération, des instructions d’agent et des définitions d’outils. Certains de ces artefacts ressemblent à des données, alors qu’ils peuvent modifier le comportement d’un agent.

Fortinet a décrit les compétences d’agents comme une nouvelle couche de dépendances pour les assistants de codage. Son analyse des compétences notait qu’une compétence peut utiliser des instructions en langage naturel pour demander à un agent d’accéder à des fichiers, d’exécuter des commandes shell ou de transmettre des informations.

Ce comportement ne nécessite pas toujours une faille logicielle conventionnelle. Une instruction malveillante peut devenir opérationnelle lorsqu’un agent lui fait confiance et qu’il est autorisé à utiliser l’outil demandé.

Un générateur de workflows exposé sur internet combine ces risques. Il peut révéler les intégrations utilisées par une organisation, accepter des entrées non fiables ou exposer des routes interagissant avec des identifiants stockés. Un workflow compromis pourrait alors atteindre des systèmes bien au-delà du serveur d’IA d’origine.

Prenons un assistant de récupération utilisé par une équipe d’ingénierie. L’application peut se connecter à un dépôt de code source, un espace de documentation, un outil de suivi des problèmes et un point de terminaison de modèle. Sa base de données vectorielle pourrait contenir des fragments de documents internes.

Si l’interface publique présente une faille d’autorisation, le gain de l’attaquant ne se limite pas à une inférence de modèle gratuite. Selon le produit et la configuration, l’attaquant pourrait accéder au contenu récupéré, aux définitions de workflow, aux métadonnées de connexion ou aux jetons.

Un agent de support client présente une voie similaire. Il peut se connecter aux e-mails, aux dossiers de commande, aux outils de messagerie et à une base de données clients. Même un identifiant à portée limitée devient précieux lorsque le workflow peut combiner des informations provenant de plusieurs services.

C’est pourquoi les 5 223 points de terminaison de générateurs d’agents méritent une attention distincte de celle accordée aux serveurs de modèles. Cette population plus réduite peut avoir un rayon d’impact opérationnel plus important.

Le rapport sur les risques cloud de Tenable publié en février apporte un contexte d’entreprise. Sa télémétrie a montré que 70 % des organisations analysées avaient intégré au moins un package d’IA tiers ou de Model Context Protocol.

Model Context Protocol, ou MCP, est une norme qui permet aux applications d’IA de se connecter à des outils et à des sources de données. Son utilité repose sur l’octroi aux modèles d’un accès structuré à des capacités externes.

Tenable a également indiqué que 18 % des organisations avaient accordé à des services d’IA des autorisations administratives rarement auditées. L’entreprise a constaté que les identités non humaines, y compris les agents et les comptes de service, présentaient un risque mesuré plus élevé que les utilisateurs humains.

Ces constats proviennent des clients et de la télémétrie cloud de Tenable, et non du recensement Internet de Mysterium. Les jeux de données ne doivent pas être fusionnés en une seule estimation de prévalence. Ensemble, ils montrent deux aspects du même problème opérationnel.

Mysterium a mesuré les services accessibles. Tenable a mesuré les autorisations, les packages tiers et les conditions d’identité au sein d’environnements d’entreprise. L’exposition publique devient plus lourde de conséquences lorsque le service accessible contrôle également une identité non humaine privilégiée.

La pression s’exerce à la fois sur les développeurs et les équipes de sécurité. Les développeurs ont besoin d’un accès rapide aux modèles et aux intégrations. Les équipes de sécurité ont besoin d’un inventaire, de responsabilités clairement définies, de privilèges limités et de preuves que chaque service public a une raison délibérée d’exister.

Aucun de ces objectifs ne peut être atteint par la seule politique du modèle. Un modèle qui refuse une requête nuisible ne corrige pas une console d’administration publique. Les garde-fous des fournisseurs ne font pas tourner un jeton divulgué et ne suppriment pas un conteneur abandonné.

Les organisations qui utilisent l’IA pour travailler avec des connaissances internes doivent également classifier ce qui entre dans les systèmes de récupération. Une base de connaissances consultable peut améliorer l’accès aux contenus techniques, mais son stockage et ses connecteurs héritent de la sensibilité de ces contenus.

La question de sécurité se déplace donc en amont. Avant qu’un agent ne reçoive une requête, quelqu’un doit décider quelles données il peut récupérer, quels outils il peut appeler et quel réseau peut l’atteindre.

Ce que le chiffre de 36 769 ne prouve pas

Le recensement démontre l’accessibilité publique, mais il n’établit pas 36 769 compromissions réussies ou fuites de données.

La mesure d’Internet peut produire un chiffre frappant sans répondre à toutes les questions de sécurité. Les empreintes produit identifient des services, tandis qu’une réponse HTTP révèle quelque chose de leur périmètre. Ni l’une ni l’autre ne révèle automatiquement l’état interne des autorisations de l’application.

Certains points de terminaison du jeu de données affichaient probablement une page de connexion. D’autres auraient pu restreindre des fonctions importantes après le chargement de l’interface. Certains pouvaient être des systèmes de recherche, des honeypots, des démonstrations intentionnellement publiques ou des installations de test vides.

Mysterium a reconnu cette limite. Le rapport n’a pas affirmé que chaque application visible autorisait un accès anonyme à des fonctionnalités privées. Il a décrit l’absence de barrière réseau ou HTTP comme l’exposition commune.

Cette limite empêche un calcul direct du nombre d’enregistrements compromis, d’organisations vulnérables ou d’utilisateurs concernés. Les chercheurs n’ont pas publié de liste des propriétaires des cibles, et cela pourrait créer un risque supplémentaire.

La mesure de l’authentification varie également selon les produits. Seules 12 des 17 catégories de produits disposaient de décomptes de défis résolus. Un tiret dans le jeu de données indiquait une requête incomplète, et non l’absence confirmée d’authentification.

L’analyse géographique était elle aussi limitée. Mysterium n’a rapporté l’attribution par pays que pour un sous-ensemble des réponses Ollama sur son port par défaut. Toute affirmation générale sur les pays ou secteurs les plus exposés irait au-delà des preuves.

Le nombre de points de terminaison peut également inclure plusieurs services exploités par une même organisation. Inversement, un point de terminaison peut se trouver devant un environnement partagé plus vaste. Le nombre d’adresses accessibles n’est pas le nombre d’entreprises touchées.

La couverture des scanners présente une autre incertitude. Un autre index, calendrier de requêtes ou mécanisme d’empreinte peut renvoyer une population différente. Les services apparaissent et disparaissent, changent de bannières, passent derrière des proxys ou reçoivent des correctifs.

Ces limites n’effacent pas la constatation. Elles font évoluer la conclusion de « 36 769 systèmes compromis » vers une formulation plus précise : des milliers de services d’IA reconnaissables étaient accessibles via un index de scan public.

Cette condition est précieuse pour les attaquants avant le début de l’exploitation. L’identification des produits aide à automatiser la correspondance avec les vulnérabilités. Un scanner peut rechercher une interface connue, estimer sa version et tester à grande échelle les routes applicables.

La différence entre exposition et compromission ressemble à une porte déverrouillée donnant sur la rue. Voir la porte ne prouve pas que quelqu’un est entré. Cela montre que le bien dépend davantage de tous les contrôles intérieurs restants.

Le chiffre de 2,02 % du rapport exige également de la prudence. L’authentification HTTP basique n’est pas intrinsèquement meilleure que l’authentification applicative moderne dans toutes les architectures. Un proxy mal géré peut introduire ses propres faiblesses.

Le principe le plus solide est la défense en profondeur. Un service d’IA sensible ne devrait pas dépendre d’une seule connexion applicative lorsque des réseaux privés, des passerelles authentifiées, des proxys tenant compte de l’identité et des règles d’entrée limitées sont disponibles.

Certaines des analyses plus larges autour de l’exposition de l’IA comportent également une incitation commerciale. Les fournisseurs de sécurité bénéficient lorsque les organisations achètent des produits de découverte, de scan, d’identité et de surveillance. Leurs recommandations doivent être évaluées à l’aune des preuves techniques.

Mysterium est lui-même une entreprise de VPN, ce qui rend la confidentialité réseau pertinente pour son activité. Cela n’invalide pas son jeu de données. Cela rend plus importants des méthodes transparentes, des empreintes reproductibles et une confirmation indépendante.

L’étude a publié ses empreintes et expliqué les résultats exclus, les lacunes liées aux limites de débit et les catégories sous-comptées. Ces choix rendent la mesure centrale plus facile à tester qu’une affirmation fondée uniquement sur une télémétrie privée.

La prochaine étape utile de la recherche est une validation contrôlée. Des équipes indépendantes devraient répéter les requêtes, échantillonner le comportement des points de terminaison sans accéder à du contenu sensible et suivre l’évolution de la population après divulgation.

Une baisse du nombre suggérerait que les opérateurs ou responsables de maintenance des logiciels ont réagi. Un nombre stable indiquerait que le déploiement non sécurisé est structurel plutôt que temporaire.

Le véritable arbitrage oppose la vitesse de déploiement au contrôle vérifiable

L’étude de Mysterium sur les points de terminaison d’IA exposés remet en question l’idée selon laquelle l’auto-hébergement garantit automatiquement la confidentialité.

L’IA hébergée concentre la confiance chez un fournisseur. Les clients s’appuient sur des contrats, l’isolation des services, des contrôles de conservation, des politiques d’accès et le programme de sécurité du fournisseur.

L’auto-hébergement redistribue cette confiance. L’organisation contrôle le matériel et le déploiement, mais elle hérite aussi de la gestion des correctifs, de la gestion des identités, de la conception réseau, de la journalisation, des sauvegardes et de la réponse aux incidents.

Cela peut être le bon choix pour des informations réglementées ou des charges de travail spécialisées. Ce n’est pas le choix le plus facile par défaut. Le serveur local doit être exploité comme une infrastructure sensible, et non comme une expérimentation de bureau devenue partagée par hasard.

La vitesse crée la tension centrale. Les frameworks d’IA sont conçus pour réduire la distance entre une idée et une application fonctionnelle. Un chercheur peut lancer une interface, attacher un modèle, connecter des documents et partager le résultat rapidement.

Chaque commodité peut dissimuler une décision opérationnelle. Exposer un port facilite la collaboration. Stocker un jeton dans un workflow accélère l’intégration. Accorder de larges autorisations évite les erreurs d’autorisation répétées.

Ces décisions s’accumulent pour former un environnement qui fonctionne avant que quiconque ait défini sa frontière de sécurité. L’application devient utile, attire des utilisateurs et se rapproche de la production tout en conservant ses contrôles expérimentaux.

Les processus de sécurité traditionnels peuvent également contribuer à cet écart. Si l’obtention d’un environnement approuvé prend des semaines, les employés contourneront le processus. Bloquer tous les services d’IA sans proposer de voie utilisable encourage des alternatives non gérées.

Les organisations ont besoin d’une voie de déploiement assez rapide pour rivaliser avec l’infrastructure fantôme. Cette voie devrait fournir par défaut un réseau privé, une identité gérée, un stockage des secrets, une journalisation, la responsabilité des correctifs et des dates d’expiration.

Les expérimentations de courte durée méritent des dates d’expiration, car les systèmes temporaires se suppriment rarement eux-mêmes. Une instance cloud créée pour une démonstration peut rester en ligne après que son propriétaire a changé de rôle ou oublié le projet.

L’inventaire doit couvrir l’ensemble de la chaîne opérationnelle. Trouver un serveur de modèles sans son magasin vectoriel, son moteur de workflow, son hôte de conteneurs et ses comptes de service laisse les défenseurs avec une vision fragmentée.

L’identité mérite une attention égale. Un agent devrait recevoir les autorisations les plus restreintes nécessaires à sa tâche. Les identifiants administratifs ne devraient pas devenir la réponse standard lorsqu’une intégration échoue.

Les identifiants stockés dans des workflows publics ou précédemment exposés devraient être renouvelés. Supprimer l’accès à Internet ferme une voie, mais n’invalide pas un jeton qu’un attaquant pourrait déjà posséder.

Les journaux doivent couvrir les actions, et pas seulement les conversations. Les équipes doivent savoir quel outil un agent a appelé, quelle identité il a utilisée, quelle ressource il a atteinte et si l’action correspondait à un workflow approuvé.

Cela est particulièrement important lorsque les instructions de l’agent proviennent de tiers. Un modèle, plugin ou skill importé peut modifier le comportement sans ressembler à du code exécutable. Les revues doivent examiner à la fois les packages conventionnels et les fichiers de contrôle en langage naturel.

Les responsables de maintenance des logiciels subissent également une pression. Des paramètres sécurisés par défaut devraient rendre l’exposition accidentelle plus difficile. Les produits peuvent avertir lorsque des services se lient à des interfaces publiques, exiger des identifiants au premier lancement et séparer les routes administratives des points de terminaison destinés aux utilisateurs.

La documentation importe, car les tutoriels deviennent souvent une architecture de production. Un guide de démarrage rapide qui expose un service sans expliquer les conséquences réseau peut propager la même erreur à travers des milliers d’installations.

Les fournisseurs de cloud et de modèles restent partie intégrante de la comparaison. Les plateformes gérées peuvent réduire le travail de configuration, mais elles introduisent des risques de concentration chez le fournisseur et d’autorisations de compte. La réponse n’est pas qu’un modèle d’hébergement l’emporte toujours.

Le choix défendable est celui dont les contrôles peuvent être vérifiés. Une organisation devrait savoir où le modèle s’exécute, qui peut l’atteindre, quelles données il traite, quelles identités il utilise et à quelle vitesse l’accès peut être révoqué.

Trois signaux montreront si l’exposition diminue

Le prochain test sera de savoir si les responsables de maintenance et les opérateurs transforment un recensement largement relayé en remédiation mesurable.

Le premier signal est un nouveau scan Internet utilisant les mêmes empreintes. Les mesures les plus révélatrices seront le nombre total confirmé de points de terminaison et la part protégée par une authentification au niveau réseau.

Un nombre inférieur de points de terminaison suggérerait que les opérateurs ont supprimé les accès publics inutiles. Un taux d’authentification plus élevé montrerait que les services sont restés utiles tout en gagnant un périmètre.

Aucune de ces évolutions ne suffit à elle seule. Un point de terminaison peut disparaître d’une empreinte parce que sa bannière a changé, tout en restant accessible. Les chercheurs devraient donc documenter les changements de requêtes et préserver des mesures comparables.

Le deuxième signal est l’action des principaux responsables de maintenance. Open WebUI mérite une attention particulière, car il représentait 18 529 points de terminaison, soit environ la moitié de la population confirmée par Mysterium.

Des avertissements concernant l’exposition publique, des identifiants initiaux obligatoires, des modèles de déploiement plus sûrs et des recommandations plus claires sur les proxys inverses renforceraient l’argument général du rapport. Le silence ou des modifications purement esthétiques des bannières laisseraient le problème opérationnel largement intact.

Les outils de création d’agents devraient faire l’objet d’un examen encore plus attentif. Flowise, RAGFlow, Dify, n8n, Langflow et les outils similaires doivent proposer des paramètres sécurisés par défaut qui tiennent compte de leur accès aux secrets et aux systèmes externes.

Le troisième signal concerne les vulnérabilités et les preuves d’incidents. De nouveaux avis portant sur l’autorisation, la divulgation d’identifiants, l’exécution à distance ou l’accès des agents aux outils montreraient comment une exposition publique peut devenir un vecteur d’attaque.

Une exploitation confirmée renforcerait l’urgence, mais les défenseurs ne devraient pas l’attendre. L’absence d’incidents divulgués ne prouve pas la sécurité lorsque les propriétaires des actifs peuvent manquer de journaux ou de visibilité.

Les organisations peuvent agir avant l’apparition de ces signaux. Elles devraient inventorier leurs services d’IA, tester quelles interfaces sont accessibles publiquement et identifier les personnes responsables de chaque déploiement.

Tout ce qui ne nécessite pas d’accès public devrait être lié à une interface privée. Les services qui doivent rester accessibles devraient être placés derrière des passerelles authentifiées, avec des identités limitées et des correctifs à jour.

Les outils de création d’agents nécessitent un traitement supplémentaire en tant qu’infrastructure de secrets. Les équipes devraient examiner les intégrations stockées, renouveler les identifiants exposés, inspecter les flux de travail importés et consigner les actions des agents sur les systèmes connectés.

Le nombre de points de terminaison d’IA exposés recensés par Mysterium finira par devenir obsolète. C’est attendu. La question importante est de savoir si le prochain décompte reflétera de meilleurs contrôles ou simplement une collection plus importante de services négligés.

Pour les développeurs, les acheteurs en entreprise et les utilisateurs de l’IA, le test pratique est simple : l’organisation peut-elle montrer qui peut accéder à chaque système et ce que ce système peut faire ? Si la réponse repose sur des hypothèses, le déploiement n’offre pas le contrôle que l’auto-hébergement promettait.