Mysterium legte KI-Endpunkte offen, und Self-Hosting verlor sein Sicherheitsalibi
Mysterium legte KI-Endpunkte in einem Ausmaß offen, das aus einem Konfigurationsfehler eine Warnung für die gesamte Branche macht. Die Forschenden identifizierten 36.769 erreichbare Systeme, während nur 741 eine HTTP-Authentifizierungsabfrage zurückgaben.
Die Studie vom 10. September umfasste Modellserver, Chat-Oberflächen, Agenten-Builder und Konsolen für Vektorspeicher. Diese Komponenten bilden die operative Ebene zwischen einem KI-Modell und den Personen, Dokumenten, Zugangsdaten und Anwendungen in seinem Umfeld.
Dadurch entsteht ein unangenehmer Widerspruch für selbstgehostete KI. Unternehmen betreiben Modelle häufig lokal, um die Kontrolle über Prompts und sensible Daten zu behalten. Dennoch scheinen viele Deployments ohne Netzwerk-Gate erreichbar zu sein, wodurch das Vertrauen auf Anwendungssicherheit, Patches und korrekte Konfiguration verlagert wird.
Die Zahl beweist nicht, dass alle 36.769 Systeme private Informationen preisgaben. Einige Anwendungen könnten nach dem Laden weiterhin eine Anmeldung verlangen. Die Ergebnisse zeigen jedoch, dass Tausende von KI-Diensten sich direkt gegenüber Internet-Scannern zu erkennen geben.
Diese Unterscheidung ist wichtig. Eine sichtbare Anmeldeseite ist weiterhin eine exponierte Anwendung, die neuen Schwachstellen, gestohlenen Passwörtern, schwachen Standardeinstellungen und automatisierten Prüfungen standhalten muss. Ein Dienst hinter einem privaten Netzwerk oder einem authentifizierten Gateway bietet ein kleineres Angriffsziel.
Der Vergleich lautet daher nicht einfach lokale KI gegen gehostete KI. Es geht um Kontrolle im Prinzip gegenüber Kontrolle im Deployment. Die Ergebnisse von Mysterium legen nahe, dass Organisationen Self-Hosting wählen, ohne die Sicherheitsgrenze, die Self-Hosting wertvoll macht, konsequent zu betreiben.
Von Mysterium offengelegte KI-Endpunkte im gesamten produktiven KI-Stack
Die zentrale Erkenntnis betrifft nicht ein einzelnes verwundbares Produkt. Es ist ein erkennbarer KI-Stack, der aus dem öffentlichen Internet kartiert werden kann.
Mysterium erklärte, seine Forschenden hätten einen Drittanbieter-Scanning-Index genutzt, statt die identifizierten Maschinen direkt zu prüfen. Die ursprüngliche Erhebung suchte nach Dienst-Fingerprints, darunter Seitentitel, Antworttexte und Ports, die mit gängiger KI-Software verbunden sind.
Der finale Datensatz enthielt 36.769 sich selbst identifizierende Endpunkte. Produkte zur Modellbereitstellung machten den Großteil dieser Population aus, angeführt von 18.529 Open WebUI-Instanzen. Open WebUI bietet eine browserbasierte Oberfläche für die Interaktion mit lokal gehosteten Sprachmodellen.
Nur einer dieser Open WebUI-Endpunkte gab während der Studie eine HTTP-Authentifizierungsabfrage zurück. Das belegt nicht, dass die übrigen Anwendungen uneingeschränkten Kontozugriff erlaubten. Es belegt jedoch, dass fast keiner eine erkennbare HTTP-Schranke vor der Anwendung hatte.
Ollama, ein Dienst zum Herunterladen und Ausführen von Modellen auf lokaler Hardware, stellte weitere 6.935 bestätigte Endpunkte dar. Jeder von ihnen gab laut Mysterium anonym die Root-Antwort des Produkts zurück. Von dieser Gruppe lieferten 729 eine Authentifizierungsabfrage.
Die Forschenden identifizierten außerdem 4.880 vLLM-Endpunkte, von denen drei eine Abfrage zurückgaben. vLLM ist ein Inferenzserver, das heißt, er nimmt Anfragen entgegen und verarbeitet sie mit einem Sprachmodell, um Antworten zu erzeugen.
Kleinere Gruppen umfassten 150 LocalAI-Endpunkte, 69 llama.cpp-Server und 63 Xinference-Deployments. Diese Produkte richten sich an unterschiedliche Zielgruppen, teilen jedoch einen operativen Zweck. Sie machen Modelle für Anwendungen oder Nutzende zugänglich.
Der Datensatz ging über Inferenz hinaus. Mysterium zählte 5.223 Endpunkte, die mit Agenten-Buildern und Workflow-Tools verbunden waren, darunter Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow und Open WebUI Pipelines.
Diese Kategorie bringt ein anderes Risikoprofil mit sich. Ein Inferenzserver verarbeitet Prompts, doch ein Agenten-Builder verbindet Modelle häufig mit Datenbanken, Messaging-Systemen, Cloud-Diensten und internen Anwendungen. Er kann Tokens speichern oder Tools mit tatsächlichen Berechtigungen aufrufen.
Flowise machte 1.341 erreichbare Endpunkte aus, von denen keiner eine Authentifizierungsabfrage zurückgab. Die Studie zählte außerdem 891 RAGFlow-Deployments, 792 Dify-Endpunkte, 788 ComfyUI-Endpunkte und 675 n8n-Instanzen.
Die Sichtbarkeit von Vektorspeichern war deutlich geringer. Forschende fanden 914 Milvus-Attu-Konsolen und sechs Weaviate-Endpunkte. Ein Vektorspeicher hält numerische Repräsentationen von Inhalten vor, damit eine KI-Anwendung während eines Gesprächs relevante Dokumente abrufen kann.
Diese Zahlen sollten nicht als Beleg dafür gelesen werden, dass Vektordatenbanken nur selten exponiert sind. Mysterium erklärte, dass seine Quelle die nativen Ports zweier großer Produkte nicht scannte. Die Erhebung erfasste hauptsächlich sichtbare Webkonsolen und maß damit die datenempfindlichste Kategorie nur unzureichend.
Der Bericht fand außerdem 22.024 zusätzliche Antworten auf Ollamas Standardport. Die Forschenden schlossen sie aus der bestätigten Gesamtzahl aus, weil eine Portantwort allein schwächere Belege lieferte als ein erkennbares Produkt-Banner.
Dieser konservative Ausschluss stärkt die zentrale Schlussfolgerung. Die Zahl von 36.769 ist eine bestätigte Untergrenze innerhalb eines Scanning-Index, keine vollständige Bestandsaufnahme öffentlicher KI-Infrastruktur.
Warum die Sicherheit selbstgehosteter KI am Perimeter scheitert
Self-Hosting schützt Daten nur, wenn die Organisation auch kontrolliert, wer den Host erreichen kann.
Das Argument für lokale Modelle beginnt meist mit Datenhoheit. Prompts, hochgeladene Dokumente, abgerufene Passagen und generierte Antworten können auf Geräten verbleiben, die von der Organisation kontrolliert werden. Diese Anordnung kann die Abhängigkeit von einem externen Modellanbieter verringern.
Der Standort allein schafft jedoch keine Vertraulichkeit. Ein auf Unternehmenshardware laufendes Modell kann weiterhin öffentlich sein, wenn sein Dienst an einer internetseitig erreichbaren Adresse lauscht. Ein internes Deployment kann durch eine Firewall-Regel, eine Cloud-Sicherheitsgruppe, eine Container-Einstellung oder einen hastig konfigurierten Tunnel extern werden.
Viele lokale KI-Produkte lauschen standardmäßig nur auf der Loopback-Adresse. Loopback beschränkt Verbindungen auf Software, die auf demselben Rechner läuft. Betreiber ändern diese Adresse manchmal zu 0.0.0.0, wodurch der Dienst Verbindungen über jede verfügbare Netzwerkschnittstelle akzeptieren kann.
Diese Änderung ist nützlich, wenn ein Entwickler Zugriff von einem anderen Gerät benötigt. Sie wird gefährlich, wenn das umgebende Netzwerk zugleich eingehenden Internetverkehr zulässt.
Ein Reverse Proxy kann eine Authentifizierungsschicht bereitstellen, bevor Anfragen die KI-Anwendung erreichen. Ein virtuelles privates Netzwerk kann den Dienst aus dem öffentlichen Adressraum heraushalten. Eine IP-Allowlist kann den Zugriff auf genehmigte Netzwerke beschränken.
Mysterium fand kaum Hinweise auf solche HTTP-Schutzmaßnahmen. Über die gesamte Erhebung hinweg gaben nur 2,02 Prozent der Endpunkte eine Authentifizierungsabfrage zurück. Fünf Produktabfragen waren aufgrund von Ratenlimits der Quelle unvollständig, weshalb die Forschenden diesen Gruppen keine Abfragezahlen zuordneten.
Die enge Auslegung ist wichtig. Eine HTTP-Abfrage ist nicht die einzig mögliche Sicherheitskontrolle. Eine Anwendung kann öffentlich laden und dennoch eigene Regeln für Anmeldung, Sitzungen oder Autorisierung durchsetzen.
Doch die Abhängigkeit von Anwendungsauthentifizierung verändert das Bedrohungsmodell. Die Anwendung bleibt für Scanner und Angreifer dauerhaft erreichbar. Jeder verpasste Patch, Autorisierungsfehler, exponierte Verwaltungsroute und jedes Standardpasswort wird folgenreicher.
Aktuelle Schwachstelleneinträge zeigen, warum diese Sorge konkret ist. Die Sicherheitswarnungen von Tenable aus dem Jahr 2026 führten schwerwiegende Probleme auf, die Open WebUI und mehrere Flowise-Komponenten betreffen.
Die Flowise-Warnungen umfassten Path Traversal, Graph-Query-Injection, fehlende Authentifizierung an NVIDIA-NIM-Endpunkten und die Offenlegung personenbezogener Informationen. Separate Warnungen behandelten die Preisgabe von Zugangsdaten, Autorisierungsfehler und beliebige Dateischreibvorgänge in weiteren KI-Tools.
Diese Einträge bedeuten nicht, dass jedes internetseitig sichtbare Deployment verwundbar ist. Versionen, Konfigurationen und kompensierende Kontrollen unterscheiden sich. Sie zeigen, dass die Anwendungsebene keine dauerhafte Alternative zur Netzwerkisolation sein kann.
Das Patch-Timing schafft ein weiteres Problem. Ein Entwickler kann innerhalb weniger Minuten einen nützlichen Proof of Concept starten und ihn anschließend monatelang weiterlaufen lassen. Der Dienst gelangt möglicherweise nie in das Asset-Inventar, das Sicherheits- und Infrastrukturteams verwenden.
Dieser Lebenszyklus erzeugt Schatten-KI: Systeme, die ohne die übliche organisatorische Aufsicht eingeführt oder gebaut werden. Das Projekt bleibt für seinen Ersteller sichtbar, für die Teams, die für Zugriffsprüfungen, Updates, Logs und Incident Response zuständig sind, jedoch unsichtbar.
Das Ergebnis ist eine Sicherheitsgrenze aus Annahmen. Der Data Scientist nimmt an, dass die Cloud-Firewall den Datenverkehr blockiert. Das Infrastrukturteam nimmt an, dass die Anwendung Authentifizierung erfordert. Der Anwendungsbesitzer nimmt an, dass das Deployment temporär ist.
Ein Internet-Scanner prüft diese Annahmen, ohne organisatorischen Kontext zu benötigen. Wenn das Produkt antwortet, sich identifiziert und eine Anwendungsoberfläche präsentiert, hat es bereits eine Grenze überschritten, die Self-Hosting eigentlich bewahren sollte.
Agenten-Builder verwandeln Exposition in Supply-Chain-Risiken
Die schwerwiegendsten exponierten KI-Endpunkte beantworten nicht nur Fragen, denn sie können über Zugangsdaten und verbundene Systeme handeln.
Eine KI-Lieferkette umfasst das Modell, Softwarepakete, Serving-Infrastruktur, Retrieval-Datenbanken, Plugins, Tools und externe Dienste, die zur Erzeugung eines Ergebnisses genutzt werden. Eine Schwäche in jeder verbundenen Komponente kann das System beeinflussen oder den Zugriff eines Angreifers erweitern.
Traditionelle Software-Lieferketten bergen bereits übernommene Risiken. Anwendungen hängen von Paketen ab, die von externen Entwicklern gepflegt werden, von andernorts erstellten Container-Images und von automatisierten Workflows mit Deployment-Zugangsdaten.
KI-Anwendungen ergänzen diese Kette um Prompts, Modelldateien, Retrieval-Inhalte, Agentenanweisungen und Tool-Definitionen. Einige dieser Artefakte wirken wie Daten, können jedoch das Verhalten eines Agenten verändern.
Fortinet bezeichnete Agenten-Skills als neue Abhängigkeitsebene für Coding-Assistenten. Seine Analyse von Skills stellte fest, dass ein Skill natürliche Sprachinstruktionen nutzen kann, um einem Agenten den Zugriff auf Dateien, das Ausführen von Shell-Befehlen oder die Übermittlung von Informationen aufzutragen.
Dieses Verhalten erfordert nicht immer eine herkömmliche Software-Schwachstelle. Eine bösartige Anweisung kann operativ werden, wenn ein Agent ihr vertraut und die Berechtigung hat, das angeforderte Tool zu verwenden.
Ein internetseitig exponierter Workflow-Builder verbindet diese Risiken. Er kann offenlegen, welche Integrationen eine Organisation nutzt, nicht vertrauenswürdige Eingaben akzeptieren oder Routen preisgeben, die mit gespeicherten Zugangsdaten interagieren. Ein kompromittierter Workflow könnte anschließend Systeme weit über den ursprünglichen KI-Server hinaus erreichen.
Betrachten wir einen Retrieval-Assistenten, den ein Engineering-Team verwendet. Die Anwendung könnte mit einem Quellcode-Repository, einem Dokumentationsspeicher, einem Issue-Tracker und einem Modell-Endpunkt verbunden sein. Ihre Vektordatenbank könnte Fragmente interner Dokumente enthalten.
Weist die öffentliche Oberfläche einen Autorisierungsfehler auf, beschränkt sich der Gewinn des Angreifers nicht auf kostenlose Modellinferenz. Je nach Produkt und Konfiguration könnte der Angreifer auf abgerufene Inhalte, Workflow-Definitionen, Verbindungsmetadaten oder Tokens zugreifen.
Ein Kundensupport-Agent bietet einen ähnlichen Weg. Er könnte mit E-Mails, Bestelldaten, Messaging-Tools und einer Kundendatenbank verbunden sein. Selbst eine eng begrenzte Zugangsdatenberechtigung wird wertvoll, wenn der Workflow Informationen über Dienste hinweg kombinieren kann.
Deshalb verdienen die 5.223 Endpunkte von Agenten-Buildern gesonderte Aufmerksamkeit gegenüber den Modellservern. Die kleinere Population kann einen größeren operativen Schadenradius haben.
Tenable’s Cloud-Risiko-Bericht vom Februar liefert den Kontext für Unternehmen. Die Telemetriedaten zeigten, dass 70 Prozent der untersuchten Organisationen mindestens ein KI- oder Model Context Protocol-Paket eines Drittanbieters integriert hatten.
Model Context Protocol, kurz MCP, ist ein Standard, mit dem KI-Anwendungen eine Verbindung zu Tools und Datenquellen herstellen können. Sein Nutzen liegt darin, Modellen strukturierten Zugriff auf externe Funktionen zu gewähren.
Tenable berichtete zudem, dass 18 Prozent der Organisationen KI-Diensten administrative Berechtigungen eingeräumt hatten, die nur selten überprüft wurden. Das Unternehmen stellte fest, dass nicht-menschliche Identitäten, darunter Agents und Dienstkonten, ein höheres gemessenes Risiko aufwiesen als menschliche Nutzer.
Diese Erkenntnisse stammen aus Tenables Kunden- und Cloud-Telemetrie, nicht aus Mysteriums Internet-Zensus. Die Datensätze sollten nicht zu einer einzigen Prävalenzschätzung zusammengeführt werden. Gemeinsam zeigen sie zwei Seiten desselben operativen Problems.
Mysterium maß erreichbare Dienste. Tenable maß Berechtigungen, Drittanbieterpakete und Identitätsbedingungen innerhalb von Unternehmensumgebungen. Öffentliche Exponierung wird folgenreicher, wenn der erreichbare Dienst zugleich eine privilegierte nicht-menschliche Identität steuert.
Der Druck betrifft sowohl Entwickler als auch Sicherheitsteams. Entwickler benötigen schnellen Zugriff auf Modelle und Integrationen. Sicherheitsteams benötigen ein Inventar, klare Verantwortlichkeiten, begrenzte Berechtigungen und Nachweise dafür, dass jeder öffentliche Dienst einen bewusst definierten Zweck erfüllt.
Keines dieser Ziele lässt sich allein durch Modellrichtlinien erreichen. Wenn ein Modell eine schädliche Eingabe ablehnt, repariert das keine öffentlich erreichbare Administrationskonsole. Schutzmechanismen von Anbietern rotieren weder ein kompromittiertes Token noch entfernen sie einen aufgegebenen Container.
Organisationen, die KI für die Arbeit mit internem Wissen nutzen, müssen außerdem klassifizieren, was in Retrieval-Systeme gelangt. Eine durchsuchbare Wissensdatenbank kann den Zugriff auf technisches Material verbessern, doch ihre Speicherung und Connectoren übernehmen die Sensibilität dieses Materials.
Die Sicherheitsfrage verlagert sich daher nach vorn. Bevor ein Agent einen Prompt erhält, muss jemand entscheiden, welche Daten er abrufen, welche Tools er aufrufen und welches Netzwerk ihn erreichen darf.
Was die Zahl 36.769 nicht beweist
Der Zensus belegt öffentliche Erreichbarkeit, aber nicht 36.769 erfolgreiche Kompromittierungen oder Datenlecks.
Internetmessungen können eine eindrucksvolle Zahl liefern, ohne jede Sicherheitsfrage zu beantworten. Produkt-Fingerprints identifizieren Dienste, während eine HTTP-Antwort etwas über deren Perimeter verrät. Beides offenbart nicht automatisch den internen Autorisierungszustand der Anwendung.
Einige Endpunkte im Datensatz zeigten vermutlich eine Anmeldeseite. Andere könnten wichtige Funktionen erst nach dem Laden der Oberfläche eingeschränkt haben. Manche könnten Forschungssysteme, Honeypots, bewusst öffentliche Demonstrationen oder leere Testinstallationen gewesen sein.
Mysterium erkannte diese Grenze an. Der Bericht behauptete nicht, dass jede sichtbare Anwendung anonymen Zugriff auf private Funktionen ermöglichte. Er beschrieb das Fehlen einer Netzwerk- oder HTTP-Schranke als die gemeinsame Form der Exponierung.
Diese Einschränkung verhindert eine direkte Berechnung kompromittierter Datensätze, gefährdeter Organisationen oder betroffener Nutzer. Die Forschenden veröffentlichten keine Liste der Zielbetreiber, da dies zusätzliche Risiken schaffen könnte.
Auch die Authentifizierungsmessung variiert je nach Produkt. Nur für 12 der 17 Produktkategorien lagen aufgelöste Challenge-Zahlen vor. Ein Gedankenstrich im Datensatz kennzeichnete eine unvollständige Abfrage, nicht das bestätigte Fehlen einer Authentifizierung.
Auch die geografische Analyse war begrenzt. Mysterium berichtete die Länderzuordnung nur für eine Teilmenge der Ollama-Antworten auf dessen Standardport. Jede weitreichende Behauptung darüber, welche Länder oder Branchen am stärksten exponiert sind, ginge über die Belege hinaus.
Die Zahl der Endpunkte kann außerdem mehrere Dienste umfassen, die von einer Organisation betrieben werden. Umgekehrt kann ein Endpunkt vor einer größeren gemeinsam genutzten Umgebung stehen. Die Zahl erreichbarer Adressen ist nicht die Zahl betroffener Unternehmen.
Die Scanner-Abdeckung stellt eine weitere Unsicherheit dar. Ein anderer Index, Abfragezeitplan oder Fingerprint kann eine andere Population liefern. Dienste gehen online und offline, ändern Banner, wechseln hinter Proxys oder erhalten Patches.
Diese Einschränkungen heben den Befund nicht auf. Sie präzisieren die Schlussfolgerung von „36.769 kompromittierte Systeme“ zu Folgendem: Tausende erkennbare KI-Dienste waren über einen öffentlichen Scan-Index erreichbar.
Dieser Zustand ist für Angreifer wertvoll, noch bevor eine Ausnutzung beginnt. Die Produktidentifikation hilft dabei, das Abgleichen mit Schwachstellen zu automatisieren. Ein Scanner kann nach einer bekannten Oberfläche suchen, ihre Version schätzen und passende Routen in großem Maßstab testen.
Der Unterschied zwischen Exponierung und Kompromittierung ähnelt einer unverschlossenen, zur Straße gerichteten Tür. Das Sehen der Tür beweist nicht, dass jemand eingedrungen ist. Es zeigt jedoch, dass das Objekt stärker von allen verbleibenden internen Kontrollen abhängt.
Auch die Zahl von 2,02 Prozent im Bericht erfordert Vorsicht. HTTP Basic Authentication ist nicht in jeder Architektur grundsätzlich besser als moderne Anwendungs-Authentifizierung. Ein schlecht verwalteter Proxy kann eigene Schwachstellen einführen.
Das stärkere Prinzip ist mehrschichtige Sicherheit. Ein sensibler KI-Dienst sollte nicht von einem einzigen Anwendungs-Login abhängen, wenn private Netzwerke, authentifizierte Gateways, identitätsbewusste Proxys und begrenzte eingehende Regeln verfügbar sind.
Hinter einigen breiteren Kommentaren zur KI-Exponierung steht zudem ein kommerzieller Anreiz. Sicherheitsanbieter profitieren, wenn Organisationen Produkte für Discovery, Scanning, Identitäten und Monitoring kaufen. Ihre Empfehlungen sollten anhand technischer Belege bewertet werden.
Mysterium ist selbst ein VPN-Unternehmen, weshalb Netzwerkprivatsphäre für sein Geschäft relevant ist. Das entkräftet seinen Datensatz nicht. Es macht transparente Methoden, reproduzierbare Fingerprints und unabhängige Bestätigung wichtiger.
Die Studie veröffentlichte ihre Fingerprints und erklärte ausgeschlossene Ergebnisse, Lücken durch Rate Limits sowie unterzählte Kategorien. Diese Entscheidungen machen die zentrale Messung leichter überprüfbar als eine Behauptung, die nur auf privater Telemetrie basiert.
Der nächste sinnvolle Forschungsschritt ist eine kontrollierte Validierung. Unabhängige Teams sollten die Abfragen wiederholen, das Verhalten von Endpunkten testen, ohne auf sensible Inhalte zuzugreifen, und verfolgen, wie sich die Population nach der Offenlegung verändert.
Ein sinkender Wert würde darauf hindeuten, dass Betreiber oder Software-Maintainer reagiert haben. Ein stabiler Wert würde darauf hindeuten, dass unsichere Bereitstellung strukturell und nicht nur vorübergehend ist.
Der eigentliche Zielkonflikt lautet Bereitstellungsgeschwindigkeit versus überprüfbare Kontrolle
Die Studie von Mysterium zu exponierten KI-Endpunkten stellt die Annahme infrage, dass Self-Hosting automatisch Privatsphäre liefert.
Gehostete KI bündelt Vertrauen bei einem Anbieter. Kunden verlassen sich auf Verträge, Dienstisolation, Aufbewahrungskontrollen, Zugriffsrichtlinien und das Sicherheitsprogramm des Anbieters.
Self-Hosting verteilt dieses Vertrauen neu. Die Organisation kontrolliert Hardware und Bereitstellung, übernimmt aber auch Patch-Management, Identitätsverwaltung, Netzwerkdesign, Logging, Backups und Incident Response.
Das kann für regulierte Informationen oder spezialisierte Workloads die richtige Wahl sein. Standardmäßig ist es jedoch nicht die einfachere Wahl. Der lokale Server muss als sensible Infrastruktur betrieben werden, nicht als Desktop-Experiment, das zufällig gemeinsam genutzt wurde.
Geschwindigkeit erzeugt die zentrale Spannung. KI-Frameworks sollen die Distanz zwischen einer Idee und einer funktionierenden Anwendung verkürzen. Ein Forschender kann eine Oberfläche starten, ein Modell anbinden, Dokumente verbinden und das Ergebnis schnell teilen.
Jede Bequemlichkeit kann eine operative Entscheidung verbergen. Einen Port freizugeben erleichtert die Zusammenarbeit. Ein Token in einem Workflow zu speichern beschleunigt die Integration. Weitreichende Berechtigungen zu vergeben vermeidet wiederholte Autorisierungsfehler.
Diese Entscheidungen summieren sich zu einer Umgebung, die funktioniert, bevor jemand ihre Sicherheitsgrenze definiert hat. Die Anwendung wird nützlich, gewinnt Nutzer und rückt näher an die Produktion, während sie ihre experimentellen Kontrollen beibehält.
Auch traditionelle Sicherheitsprozesse können zur Lücke beitragen. Wenn es Wochen dauert, eine genehmigte Umgebung zu erhalten, werden Mitarbeitende den Prozess umgehen. Jeden KI-Dienst zu blockieren, ohne einen praktikablen Weg anzubieten, fördert unverwaltete Alternativen.
Organisationen benötigen einen Bereitstellungsweg, der schnell genug ist, um mit Schatteninfrastruktur zu konkurrieren. Dieser Weg sollte standardmäßig private Netzwerke, verwaltete Identitäten, Secret Storage, Logging, Patch-Verantwortung und Ablaufdaten bereitstellen.
Kurzlebige Experimente verdienen Ablaufdaten, weil temporäre Systeme sich selten selbst entfernen. Eine Cloud-Instanz, die für eine Demonstration erstellt wurde, kann online bleiben, nachdem ihr Besitzer die Rolle gewechselt oder das Projekt vergessen hat.
Das Inventar muss die gesamte operative Kette umfassen. Einen Modellserver ohne dessen Vektorspeicher, Workflow-Engine, Container-Host und Dienstkonten zu finden, hinterlässt Verteidiger mit einem fragmentierten Bild.
Identität verdient die gleiche Aufmerksamkeit. Ein Agent sollte nur die engsten Berechtigungen erhalten, die für seine Aufgabe erforderlich sind. Administrative Zugangsdaten sollten nicht zur Standardantwort werden, wenn eine Integration fehlschlägt.
Zugangsdaten, die in öffentlichen oder zuvor exponierten Workflows gespeichert waren, sollten rotiert werden. Das Entfernen des Internetzugangs schließt einen Weg, entwertet aber kein Token, das ein Angreifer möglicherweise bereits besitzt.
Logs müssen Aktionen abdecken, nicht nur Unterhaltungen. Teams müssen wissen, welches Tool ein Agent aufgerufen, welche Identität er verwendet, welche Ressource er erreicht und ob die Aktion einem genehmigten Workflow entsprochen hat.
Das ist besonders wichtig, wenn Agent-Anweisungen von Dritten stammen. Eine importierte Vorlage, ein Plugin oder ein Skill kann das Verhalten verändern, ohne wie ausführbarer Code auszusehen. Prüfungen müssen sowohl herkömmliche Pakete als auch natürlichsprachliche Steuerdateien untersuchen.
Auch Software-Maintainer stehen unter Druck. Sichere Standardeinstellungen sollten versehentliche Exponierung erschweren. Produkte können warnen, wenn Dienste an öffentliche Schnittstellen gebunden werden, bei der ersten Ausführung Zugangsdaten verlangen und administrative Routen von nutzerorientierten Endpunkten trennen.
Dokumentation ist wichtig, weil Tutorials häufig zur Produktionsarchitektur werden. Eine Schnellstartanleitung, die einen Dienst exponiert, ohne die Netzwerkkonsequenzen zu erklären, kann denselben Fehler über Tausende Installationen hinweg verbreiten.
Cloud- und Modellanbieter bleiben Teil des Vergleichs. Verwaltete Plattformen können Konfigurationsaufwand reduzieren, führen jedoch Risiken durch Anbieterkonzentration und Kontoberechtigungen ein. Die Antwort lautet nicht, dass ein Hosting-Modell immer gewinnt.
Die vertretbare Wahl ist jene, deren Kontrollen überprüft werden können. Eine Organisation sollte wissen, wo das Modell läuft, wer es erreichen kann, welche Daten es verarbeitet, welche Identitäten es verwendet und wie schnell der Zugriff widerrufen werden kann.
Drei Signale werden zeigen, ob die Exponierung abnimmt
Der nächste Test besteht darin, ob Maintainer und Betreiber einen breit berichteten Zensus in messbare Behebung umsetzen.
Das erste Signal ist ein erneuter Internet-Scan mit denselben Fingerprints. Die aufschlussreichsten Kennzahlen werden die bestätigte Gesamtzahl der Endpunkte und der Anteil sein, der durch Authentifizierung auf Netzwerkebene geschützt ist.
Eine niedrigere Zahl von Endpunkten würde darauf hindeuten, dass Betreiber unnötigen öffentlichen Zugriff entfernt haben. Eine höhere Authentifizierungsrate würde zeigen, dass Dienste nützlich blieben und zugleich einen Perimeter erhielten.
Keine der beiden Veränderungen reicht für sich allein aus. Ein Endpunkt kann aus einem Fingerprint verschwinden, weil sich sein Banner geändert hat, und dennoch erreichbar bleiben. Forschende sollten daher Abfrageänderungen dokumentieren und vergleichbare Messungen erhalten.
Das zweite Signal sind Maßnahmen großer Maintainer. Open WebUI verdient besondere Aufmerksamkeit, da es 18.529 Endpunkte repräsentierte, ungefähr die Hälfte der von Mysterium bestätigten Population.
Warnungen vor öffentlicher Bindung, verpflichtende initiale Zugangsdaten, sicherere Deployment-Vorlagen und klarere Hinweise zu Reverse-Proxys würden die übergeordnete Argumentation des Berichts stärken. Schweigen oder kosmetische Änderungen an Bannern würden das operative Problem weitgehend bestehen lassen.
Besondere Aufmerksamkeit sollten Agent-Builder erhalten. Flowise, RAGFlow, Dify, n8n, Langflow und ähnliche Tools benötigen sichere Standardeinstellungen, die ihren Zugriff auf Geheimnisse und externe Systeme berücksichtigen.
Das dritte Signal sind Belege für Schwachstellen und Vorfälle. Neue Hinweise zu Autorisierung, Offenlegung von Zugangsdaten, Remote-Ausführung oder dem Zugriff von Agenten auf Tools würden zeigen, wie öffentliche Exponierung zu einem Angriffsweg werden kann.
Bestätigte Ausnutzung würde die Dringlichkeit unterstreichen, doch Verteidiger sollten nicht darauf warten. Das Fehlen offengelegter Vorfälle belegt keine Sicherheit, wenn Verantwortliche für die Assets möglicherweise keine Logs oder ausreichende Transparenz haben.
Organisationen können handeln, bevor diese Signale eintreffen. Sie sollten ihre KI-Dienste inventarisieren, testen, welche Schnittstellen öffentlich erreichbar sind, und die für jedes Deployment verantwortlichen Personen bestimmen.
Alles, was keinen öffentlichen Zugriff benötigt, sollte an eine private Schnittstelle gebunden werden. Dienste, die erreichbar bleiben müssen, sollten hinter authentifizierten Gateways mit begrenzten Identitäten und aktuellen Patches betrieben werden.
Agent-Builder benötigen eine zusätzliche Behandlung als Infrastruktur für Geheimnisse. Teams sollten gespeicherte Integrationen überprüfen, offengelegte Zugangsdaten rotieren, importierte Workflows untersuchen und Agentenaktionen in verbundenen Systemen dokumentieren.
Die Zahl der von Mysterium offengelegten KI-Endpunkte wird irgendwann veraltet sein. Das ist zu erwarten. Entscheidend ist, ob die nächste Zahl bessere Kontrollen widerspiegelt oder lediglich eine größere Sammlung übersehener Dienste.
Für Entwickler, Unternehmenskäufer und KI-Nutzer ist der Praxistest einfach: Kann die Organisation zeigen, wer jedes System erreichen kann und was dieses System tun darf? Wenn die Antwort von Annahmen abhängt, bietet das Deployment nicht die Kontrolle, die Self-Hosting versprochen hat.
