Mysterium ujawniło punkty końcowe AI, a self-hosting stracił swoje alibi bezpieczeństwa

Mysterium ujawniło punkty końcowe AI na skalę, która zamienia błąd konfiguracji w ostrzeżenie dla całej branży. Badacze firmy zidentyfikowali 36 769 osiągalnych systemów, podczas gdy zaledwie 741 zwróciło wyzwanie uwierzytelnienia HTTP.

Badanie z 10 września objęło serwery modeli, interfejsy czatów, kreatory agentów i konsole magazynów wektorowych. Komponenty te tworzą warstwę operacyjną między modelem AI a ludźmi, dokumentami, poświadczeniami i aplikacjami, które go otaczają.

Tworzy to niewygodny konflikt dla AI hostowanej samodzielnie. Firmy często uruchamiają modele lokalnie, aby zachować kontrolę nad promptami i wrażliwymi danymi. Mimo to wiele wdrożeń wydaje się dostępnych bez bramy na poziomie sieci, przenosząc zaufanie na bezpieczeństwo aplikacji, aktualizacje i prawidłową konfigurację.

Liczba ta nie dowodzi, że wszystkie 36 769 systemów ujawniało prywatne informacje. Niektóre aplikacje mogły nadal wymagać od użytkowników logowania po ich załadowaniu. Ustalenia pokazują jednak, że tysiące usług AI bezpośrednio sygnalizują swoją obecność skanerom internetowym.

To rozróżnienie ma znaczenie. Widoczna strona logowania wciąż jest wystawioną aplikacją, która musi przetrwać nowe podatności, skradzione hasła, słabe ustawienia domyślne i automatyczne sondowanie. Usługa za prywatną siecią lub uwierzytelnioną bramą stanowi mniejszy cel.

Porównanie nie sprowadza się więc po prostu do lokalnego AI kontra AI hostowanego. Chodzi o kontrolę w teorii kontra kontrolę we wdrożeniu. Wyniki Mysterium sugerują, że organizacje wybierają self-hosting, nie utrzymując konsekwentnie granicy bezpieczeństwa, która nadaje self-hostingowi wartość.

Ujawnione przez Mysterium punkty końcowe AI w całym działającym stosie AI

Kluczowym ustaleniem nie jest jeden podatny produkt. To rozpoznawalny stos AI, który można zmapować z publicznego internetu.

Mysterium podało, że jego badacze korzystali z zewnętrznego indeksu skanowania, zamiast bezpośrednio sondować zidentyfikowane maszyny. Oryginalny spis wyszukiwał sygnatury usług, w tym tytuły stron, tekst odpowiedzi i porty powiązane z popularnym oprogramowaniem AI.

Końcowy zbiór danych zawierał 36 769 punktów końcowych samodzielnie identyfikujących się jako takie. Produkty do obsługi modeli stanowiły większość tej populacji, na czele z 18 529 instancjami Open WebUI. Open WebUI zapewnia oparty na przeglądarce interfejs do interakcji z lokalnie hostowanymi modelami językowymi.

Tylko jeden z tych punktów końcowych Open WebUI zwrócił podczas badania wyzwanie uwierzytelnienia HTTP. Nie dowodzi to, że pozostałe aplikacje pozwalały na nieograniczony dostęp do kont. Dowodzi jednak, że niemal żadna z nich nie miała wykrywalnej bramy HTTP umieszczonej przed aplikacją.

Ollama, usługa do pobierania i uruchamiania modeli na lokalnym sprzęcie, stanowiła kolejne 6 935 potwierdzonych punktów końcowych. Według Mysterium każdy z nich anonimowo zwracał odpowiedź główną produktu. Z tej grupy 729 zwróciło wyzwanie uwierzytelnienia.

Badacze zidentyfikowali również 4 880 punktów końcowych vLLM, z których trzy zwróciły wyzwanie. vLLM to serwer inferencyjny, co oznacza, że przyjmuje żądania i przetwarza je przez model językowy w celu wygenerowania odpowiedzi.

Mniejsze grupy obejmowały 150 punktów końcowych LocalAI, 69 serwerów llama.cpp i 63 wdrożenia Xinference. Produkty te obsługują różne grupy odbiorców, lecz łączy je cel operacyjny. Udostępniają modele aplikacjom lub użytkownikom.

Zbiór danych wykraczał poza inferencję. Mysterium naliczyło 5 223 punkty końcowe powiązane z kreatorami agentów i narzędziami workflow, w tym Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow i Open WebUI Pipelines.

Kategoria ta wiąże się z innym profilem ryzyka. Serwer inferencyjny przetwarza prompty, ale kreator agentów często łączy modele z bazami danych, systemami komunikacji, usługami chmurowymi i aplikacjami wewnętrznymi. Może przechowywać tokeny lub wywoływać narzędzia z rzeczywistymi uprawnieniami.

Flowise odpowiadał za 1 341 osiągalnych punktów końcowych, z których żaden nie zwrócił wyzwania uwierzytelnienia. Badanie naliczyło również 891 wdrożeń RAGFlow, 792 punkty końcowe Dify, 788 punktów końcowych ComfyUI i 675 instancji n8n.

Widoczność magazynów wektorowych była znacznie niższa. Badacze znaleźli 914 konsol Milvus Attu i sześć punktów końcowych Weaviate. Magazyn wektorowy przechowuje numeryczne reprezentacje treści, aby aplikacja AI mogła pobierać odpowiednie dokumenty podczas rozmowy.

Liczb tych nie należy interpretować jako dowodu, że bazy danych wektorowych rzadko są wystawione na zewnątrz. Mysterium podało, że jego źródło nie skanowało natywnych portów dwóch głównych produktów. Spis obejmował głównie widoczne konsole internetowe, przez co kategoria najbardziej wrażliwa pod względem danych została słabo zmierzona.

Raport wykrył także 22 024 dodatkowe odpowiedzi na domyślnym porcie Ollama. Badacze wyłączyli je z potwierdzonej łącznej liczby, ponieważ sama odpowiedź portu była słabszym dowodem niż rozpoznawalny baner produktu.

To konserwatywne wykluczenie wzmacnia główny wniosek. Liczba 36 769 jest potwierdzonym minimum w obrębie jednego indeksu skanowania, a nie pełnym spisem publicznej infrastruktury AI.

Dlaczego bezpieczeństwo AI hostowanej samodzielnie załamuje się na obrzeżach sieci

Self-hosting chroni dane tylko wtedy, gdy organizacja kontroluje również to, kto może dotrzeć do hosta.

Argument za lokalnymi modelami zwykle zaczyna się od pieczy nad danymi. Prompty, przesłane dokumenty, pobrane fragmenty i wygenerowane odpowiedzi mogą pozostawać na sprzęcie kontrolowanym przez organizację. Taki układ może ograniczyć zależność od zewnętrznego dostawcy modeli.

Sama lokalizacja nie zapewnia jednak poufności. Model działający na sprzęcie firmowym może nadal być publiczny, jeśli jego usługa nasłuchuje pod adresem dostępnym z internetu. Wewnętrzne wdrożenie może stać się zewnętrzne przez regułę zapory, grupę zabezpieczeń chmury, ustawienie kontenera lub pospiesznie skonfigurowany tunel.

Wiele lokalnych produktów AI domyślnie nasłuchuje wyłącznie na adresie loopback. Loopback ogranicza połączenia do oprogramowania działającego na tej samej maszynie. Operatorzy czasami zmieniają ten adres na 0.0.0.0, co pozwala usłudze przyjmować połączenia przez każdy dostępny interfejs sieciowy.

Taka zmiana jest przydatna, gdy deweloper potrzebuje dostępu z innego urządzenia. Staje się niebezpieczna, gdy otaczająca sieć zezwala również na przychodzący ruch z internetu.

Reverse proxy może zapewnić warstwę uwierzytelniania, zanim żądania dotrą do aplikacji AI. Wirtualna sieć prywatna może utrzymać usługę poza publiczną przestrzenią adresową. Lista dozwolonych adresów IP może ograniczyć dostęp do zatwierdzonych sieci.

Mysterium znalazło niewiele dowodów na istnienie takich zabezpieczeń na poziomie HTTP. W całym spisie zaledwie 2,02 procent punktów końcowych zwróciło wyzwanie uwierzytelnienia. Pięć zapytań dotyczących produktów było niekompletnych z powodu limitów szybkości źródła, dlatego badacze nie przypisali liczby wyzwań tym grupom.

Wąska interpretacja jest istotna. Wyzwanie HTTP nie jest jedynym możliwym mechanizmem bezpieczeństwa. Aplikacja może ładować się publicznie, a mimo to egzekwować własne reguły logowania, sesji lub autoryzacji.

Poleganie na uwierzytelnianiu aplikacji zmienia jednak model zagrożeń. Aplikacja staje się stale dostępna dla skanerów i atakujących. Każda pominięta aktualizacja, błąd autoryzacji, wystawiona ścieżka administracyjna i domyślne poświadczenie nabierają większego znaczenia.

Najnowsze rejestry podatności pokazują, dlaczego ta obawa jest konkretna. Doradztwa bezpieczeństwa Tenable z 2026 r. wskazały problemy o wysokiej wadze dotyczące Open WebUI i kilku komponentów Flowise.

Doradztwa dotyczące Flowise obejmowały przejście po ścieżkach, wstrzykiwanie zapytań grafowych, brak uwierzytelniania w punktach końcowych NVIDIA NIM oraz ujawnianie danych osobowych. Osobne doradztwa obejmowały ujawnianie poświadczeń, błędy autoryzacji i arbitralne zapisy plików w innych narzędziach AI.

Zapisy te nie oznaczają, że każde wdrożenie widoczne w internecie jest podatne. Wersje, konfiguracje i kontrole kompensacyjne są różne. Pokazują one, że warstwa aplikacji nie może służyć jako trwały substytut izolacji sieciowej.

Czas stosowania poprawek tworzy kolejny problem. Deweloper może uruchomić użyteczny proof of concept w kilka minut, a następnie pozostawić go działającego przez miesiące. Usługa może nigdy nie trafić do inwentaryzacji zasobów używanej przez zespoły bezpieczeństwa i infrastruktury.

Ten cykl życia prowadzi do shadow AI, czyli systemów wdrożonych lub zbudowanych bez zwykłego nadzoru organizacyjnego. Projekt pozostaje widoczny dla swojego twórcy, lecz niewidoczny dla zespołów odpowiedzialnych za przeglądy dostępu, aktualizacje, logi i reagowanie na incydenty.

W rezultacie granica bezpieczeństwa jest zbudowana z założeń. Specjalista ds. danych zakłada, że zapora chmurowa blokuje ruch. Zespół infrastruktury zakłada, że aplikacja wymaga uwierzytelnienia. Właściciel aplikacji zakłada, że wdrożenie jest tymczasowe.

Skaner internetowy testuje te założenia bez konieczności znajomości kontekstu organizacyjnego. Jeśli produkt odpowiada, identyfikuje się i udostępnia powierzchnię aplikacyjną, przekroczył już jedną granicę, którą self-hosting miał zachować.

Kreatory agentów zamieniają ekspozycję w ryzyko dla łańcucha dostaw

Najpoważniejsze wystawione punkty końcowe AI robią więcej niż odpowiadają na pytania, ponieważ mogą działać za pośrednictwem poświadczeń i połączonych systemów.

Łańcuch dostaw AI obejmuje model, pakiety oprogramowania, infrastrukturę obsługującą, bazy danych do wyszukiwania, wtyczki, narzędzia i usługi zewnętrzne wykorzystywane do osiągnięcia wyniku. Słabość dowolnego połączonego komponentu może wpłynąć na system lub rozszerzyć dostęp atakującego.

Tradycyjne łańcuchy dostaw oprogramowania już niosą odziedziczone ryzyko. Aplikacje zależą od pakietów utrzymywanych przez zewnętrznych deweloperów, obrazów kontenerów zbudowanych gdzie indziej oraz zautomatyzowanych workflow przechowujących poświadczenia wdrożeniowe.

Aplikacje AI dodają do tego łańcucha prompty, pliki modeli, treści do wyszukiwania, instrukcje agentów i definicje narzędzi. Niektóre z tych artefaktów wyglądają jak dane, choć mogą zmieniać zachowanie agenta.

Fortinet opisał umiejętności agentów jako nową warstwę zależności dla asystentów programistycznych. Jego analiza umiejętności wskazała, że umiejętność może wykorzystywać instrukcje w języku naturalnym, aby nakazać agentowi dostęp do plików, uruchomienie poleceń powłoki lub przesłanie informacji.

Takie zachowanie nie zawsze wymaga konwencjonalnej luki w oprogramowaniu. Złośliwa instrukcja może stać się operacyjna, gdy agent jej zaufa i ma uprawnienia do użycia żądanego narzędzia.

Kreator workflow wystawiony na internet łączy te ryzyka. Może ujawnić, z jakich integracji korzysta organizacja, przyjmować niezaufane dane wejściowe lub wystawiać ścieżki współdziałające z przechowywanymi poświadczeniami. Przejęty workflow mógłby następnie dotrzeć do systemów znacznie wykraczających poza pierwotny serwer AI.

Rozważmy asystenta wyszukiwania używanego przez zespół inżynierski. Aplikacja może łączyć się z repozytorium kodu źródłowego, magazynem dokumentacji, systemem śledzenia zgłoszeń i punktem końcowym modelu. Jej baza wektorowa może zawierać fragmenty wewnętrznych dokumentów.

Jeśli publiczny interfejs ma błąd autoryzacji, nagroda dla atakującego nie ogranicza się do darmowej inferencji modelu. W zależności od produktu i konfiguracji atakujący mógłby uzyskać dostęp do pobranych treści, definicji workflow, metadanych połączeń lub tokenów.

Agent obsługi klienta stwarza podobną ścieżkę. Może łączyć się z pocztą e-mail, zapisami zamówień, narzędziami komunikacyjnymi i bazą danych klientów. Nawet wąsko ograniczone poświadczenie staje się cenne, gdy workflow może łączyć informacje z różnych usług.

Dlatego 5 223 punkty końcowe kreatorów agentów zasługują na odrębną uwagę od serwerów modeli. Mniejsza populacja może wiązać się z większym promieniem rażenia operacyjnego.

Lutowy raport Tenable dotyczący ryzyka w chmurze dostarcza kontekstu dla przedsiębiorstw. Telemetria firmy pokazała, że 70 procent analizowanych organizacji zintegrowało co najmniej jeden zewnętrzny pakiet AI lub Model Context Protocol.

Model Context Protocol, czyli MCP, to standard umożliwiający aplikacjom AI łączenie się z narzędziami i źródłami danych. Jego użyteczność wynika z zapewniania modelom ustrukturyzowanego dostępu do zewnętrznych możliwości.

Tenable poinformowało również, że 18 procent organizacji przyznało usługom AI uprawnienia administracyjne, które rzadko były audytowane. Firma ustaliła, że tożsamości niebędące ludźmi, w tym agenci i konta usługowe, wiązały się z wyższym mierzonym ryzykiem niż użytkownicy będący ludźmi.

Ustalenia te pochodzą z telemetrii klientów i chmury Tenable, a nie z internetowego spisu Mysterium. Tych zbiorów danych nie należy łączyć w jeden szacunek skali zjawiska. Łącznie pokazują one dwie strony tego samego problemu operacyjnego.

Mysterium mierzyło dostępne usługi. Tenable mierzyło uprawnienia, pakiety zewnętrzne i warunki dotyczące tożsamości wewnątrz środowisk przedsiębiorstw. Publiczna ekspozycja staje się bardziej istotna, gdy dostępna usługa kontroluje również uprzywilejowaną tożsamość niebędącą człowiekiem.

Presja dotyczy zarówno programistów, jak i zespołów bezpieczeństwa. Programiści potrzebują szybkiego dostępu do modeli i integracji. Zespoły bezpieczeństwa potrzebują inwentaryzacji, jasnej odpowiedzialności, ograniczonych uprawnień oraz dowodów, że każda publiczna usługa ma uzasadniony powód istnienia.

Żadnego z tych celów nie można osiągnąć wyłącznie za pomocą polityki modelu. Model odmawiający realizacji szkodliwego polecenia nie naprawia publicznej konsoli administracyjnej. Zabezpieczenia dostawcy nie rotują ujawnionego tokenu ani nie usuwają porzuconego kontenera.

Organizacje wykorzystujące AI do pracy z wewnętrzną wiedzą muszą również klasyfikować dane trafiające do systemów wyszukiwania wspomaganego. Przeszukiwalna baza wiedzy może ułatwiać dostęp do materiałów technicznych, ale jej magazyny danych i konektory dziedziczą wrażliwość tych materiałów.

Pytanie o bezpieczeństwo przesuwa się więc na wcześniejszy etap. Zanim agent otrzyma polecenie, ktoś musi zdecydować, jakie dane może pobierać, jakie narzędzia może wywoływać i z której sieci można do niego dotrzeć.

Czego liczba 36 769 nie dowodzi

Spis pokazuje publiczną dostępność, ale nie potwierdza 36 769 udanych włamań ani wycieków danych.

Pomiary internetu mogą dać uderzającą liczbę, nie odpowiadając przy tym na każde pytanie dotyczące bezpieczeństwa. Odciski produktów identyfikują usługi, a odpowiedź HTTP ujawnia coś o ich granicach sieciowych. Żadne z nich nie pokazuje automatycznie wewnętrznego stanu autoryzacji aplikacji.

Niektóre punkty końcowe w zbiorze danych prawdopodobnie wyświetlały stronę logowania. Inne mogły ograniczać ważne funkcje po załadowaniu interfejsu. Część mogła być systemami badawczymi, honeypotami, celowo publicznymi demonstracjami lub pustymi instalacjami testowymi.

Mysterium przyznało, że taka granica istnieje. Raport nie twierdził, że każda widoczna aplikacja umożliwiała anonimowy dostęp do prywatnych funkcji. Opisywał brak zabezpieczenia na poziomie sieci lub HTTP jako wspólną cechę ekspozycji.

To ograniczenie uniemożliwia bezpośrednie obliczenie liczby naruszonych rekordów, podatnych organizacji lub dotkniętych użytkowników. Badacze nie opublikowali listy właścicieli celów, a jej publikacja mogłaby stworzyć dodatkowe ryzyko.

Pomiar uwierzytelniania różni się też w zależności od produktu. Tylko 12 z 17 kategorii produktów miało rozstrzygnięte liczby dotyczące zabezpieczeń. Myślnik w zbiorze danych oznaczał niekompletne zapytanie, a nie potwierdzony brak uwierzytelniania.

Analiza geograficzna również była ograniczona. Mysterium podało przypisanie do krajów tylko dla podzbioru odpowiedzi Ollama na domyślnym porcie. Każde szerokie twierdzenie o krajach lub branżach najbardziej narażonych na ekspozycję wykraczałoby poza dostępne dowody.

Liczba punktów końcowych może również obejmować wiele usług obsługiwanych przez jedną organizację. Z drugiej strony jeden punkt końcowy może znajdować się przed większym współdzielonym środowiskiem. Liczba dostępnych adresów nie jest liczbą dotkniętych firm.

Zasięg skanera stanowi kolejną niewiadomą. Inny indeks, harmonogram zapytań lub odcisk może zwrócić inną populację. Usługi pojawiają się i znikają z internetu, zmieniają banery, przenoszą się za proxy albo otrzymują poprawki.

Te ograniczenia nie unieważniają ustalenia. Zmieniają wniosek z „36 769 skompromitowanych systemów” na bardziej precyzyjny: tysiące rozpoznawalnych usług AI było dostępnych przez jeden publiczny indeks skanowania.

Taki stan jest wartościowy dla atakujących jeszcze przed rozpoczęciem eksploatacji. Identyfikacja produktu pomaga automatyzować dopasowywanie podatności. Skaner może szukać znanego interfejsu, oszacować jego wersję i testować odpowiednie ścieżki na dużą skalę.

Różnica między ekspozycją a kompromitacją przypomina odblokowane drzwi wychodzące na ulicę. Sam widok drzwi nie dowodzi, że ktoś wszedł. Pokazuje jednak, że nieruchomość w większym stopniu zależy od wszystkich pozostałych zabezpieczeń wewnętrznych.

Wartość 2,02 procent z raportu również wymaga ostrożności. Podstawowe uwierzytelnianie HTTP nie jest z natury lepsze od nowoczesnego uwierzytelniania aplikacji w każdej architekturze. Źle zarządzane proxy może wprowadzać własne słabości.

Silniejszą zasadą jest wielowarstwowa ochrona. Wrażliwa usługa AI nie powinna zależeć od jednego logowania do aplikacji, gdy dostępne są prywatne sieci, uwierzytelnione bramy, proxy uwzględniające tożsamość oraz ograniczone reguły ruchu przychodzącego.

Za częścią szerszych komentarzy dotyczących ekspozycji AI kryje się też zachęta komercyjna. Dostawcy bezpieczeństwa odnoszą korzyści, gdy organizacje kupują produkty do wykrywania zasobów, skanowania, zarządzania tożsamością i monitorowania. Ich rekomendacje należy oceniać na podstawie dowodów technicznych.

Mysterium samo jest firmą VPN, dlatego prywatność sieciowa ma znaczenie dla jej działalności. Nie unieważnia to jego zbioru danych. Sprawia natomiast, że bardziej istotne stają się przejrzyste metody, odtwarzalne odciski oraz niezależne potwierdzenie.

Badanie opublikowało swoje odciski i wyjaśniło wykluczone wyniki, luki wynikające z limitów zapytań oraz niedoszacowane kategorie. Te decyzje sprawiają, że centralny pomiar jest łatwiejszy do sprawdzenia niż twierdzenie oparte wyłącznie na prywatnej telemetrii.

Kolejnym użytecznym krokiem badawczym jest kontrolowana walidacja. Niezależne zespoły powinny powtórzyć zapytania, próbkować zachowanie punktów końcowych bez uzyskiwania dostępu do wrażliwych treści oraz śledzić, jak populacja zmienia się po ujawnieniu wyników.

Spadająca liczba sugerowałaby, że operatorzy lub opiekunowie oprogramowania zareagowali. Stabilna liczba wskazywałaby, że niebezpieczne wdrożenie ma charakter strukturalny, a nie tymczasowy.

Rzeczywisty kompromis dotyczy szybkości wdrożenia i weryfikowalnej kontroli

Badanie Mysterium dotyczące wystawionych punktów końcowych AI podważa przekonanie, że samodzielne hostowanie automatycznie zapewnia prywatność.

Hostowane AI koncentruje zaufanie w rękach dostawcy. Klienci polegają na umowach, izolacji usług, mechanizmach retencji, politykach dostępu oraz programie bezpieczeństwa dostawcy.

Samodzielne hostowanie rozdziela to zaufanie. Organizacja kontroluje sprzęt i wdrożenie, ale przejmuje też odpowiedzialność za poprawki, zarządzanie tożsamością, projekt sieci, logowanie, kopie zapasowe i reagowanie na incydenty.

Może to być właściwy wybór dla regulowanych informacji lub wyspecjalizowanych obciążeń. Domyślnie nie jest jednak wyborem łatwiejszym. Lokalny serwer musi być obsługiwany jako wrażliwa infrastruktura, a nie jako eksperyment desktopowy, który przypadkowo stał się współdzielony.

Szybkość tworzy podstawowe napięcie. Frameworki AI są projektowane tak, aby skracać drogę od pomysłu do działającej aplikacji. Badacz może szybko uruchomić interfejs, podłączyć model, połączyć dokumenty i udostępnić rezultat.

Każda wygoda może ukrywać decyzję operacyjną. Wystawienie portu ułatwia współpracę. Przechowywanie tokenu w przepływie pracy przyspiesza integrację. Przyznanie szerokich uprawnień pozwala uniknąć powtarzających się błędów autoryzacji.

Te decyzje kumulują się w środowisku, które działa, zanim ktokolwiek zdefiniuje jego granicę bezpieczeństwa. Aplikacja staje się użyteczna, przyciąga użytkowników i zbliża się do produkcji, zachowując jednocześnie eksperymentalne mechanizmy kontroli.

Tradycyjne procesy bezpieczeństwa również mogą pogłębiać tę lukę. Jeśli uzyskanie zatwierdzonego środowiska trwa tygodniami, pracownicy będą omijać proces. Blokowanie każdej usługi AI bez zapewnienia użytecznej ścieżki sprzyja niezarządzanym alternatywom.

Organizacje potrzebują ścieżki wdrożeniowej wystarczająco szybkiej, by konkurować z infrastrukturą tworzoną poza kontrolą. Powinna ona domyślnie zapewniać prywatną sieć, zarządzaną tożsamość, magazyn sekretów, logowanie, odpowiedzialność za poprawki i daty wygaśnięcia.

Krótkotrwałe eksperymenty zasługują na daty wygaśnięcia, ponieważ systemy tymczasowe rzadko usuwają się same. Instancja chmurowa utworzona na potrzeby demonstracji może pozostać online po zmianie roli jej właściciela lub po zapomnieniu o projekcie.

Inwentaryzacja musi obejmować cały łańcuch operacyjny. Odnalezienie serwera modelu bez jego magazynu wektorowego, silnika przepływów pracy, hosta kontenerów i kont usługowych pozostawia obrońcom fragmentaryczny obraz.

Tożsamość zasługuje na równą uwagę. Agent powinien otrzymywać najwęższe uprawnienia wymagane do wykonania zadania. Poświadczenia administracyjne nie powinny stawać się standardową odpowiedzią, gdy integracja zawodzi.

Poświadczenia przechowywane w publicznych lub wcześniej wystawionych przepływach pracy należy rotować. Usunięcie dostępu do internetu zamyka jedną ścieżkę, ale nie unieważnia tokenu, który atakujący może już posiadać.

Logi muszą obejmować działania, a nie tylko rozmowy. Zespoły muszą wiedzieć, które narzędzie wywołał agent, jakiej tożsamości użył, do jakiego zasobu dotarł oraz czy działanie odpowiadało zatwierdzonemu przepływowi pracy.

Jest to szczególnie ważne, gdy instrukcje dla agentów pochodzą od stron trzecich. Zaimportowany szablon, plugin lub skill może zmienić zachowanie, nie przypominając kodu wykonywalnego. Przeglądy muszą obejmować zarówno tradycyjne pakiety, jak i pliki sterujące w języku naturalnym.

Twórcy oprogramowania również odczuwają presję. Bezpieczne ustawienia domyślne powinny utrudniać przypadkową ekspozycję. Produkty mogą ostrzegać, gdy usługi wiążą się z publicznymi interfejsami, wymagać poświadczeń przy pierwszym uruchomieniu oraz oddzielać ścieżki administracyjne od punktów końcowych przeznaczonych dla użytkowników.

Dokumentacja ma znaczenie, ponieważ tutoriale często stają się architekturą produkcyjną. Przewodnik szybkiego startu, który wystawia usługę bez wyjaśnienia konsekwencji sieciowych, może rozpowszechnić ten sam błąd w tysiącach instalacji.

Dostawcy chmury i modeli pozostają częścią tego porównania. Platformy zarządzane mogą ograniczyć nakład pracy konfiguracyjnej, ale wprowadzają koncentrację u dostawcy oraz ryzyko związane z uprawnieniami kont. Odpowiedź nie brzmi, że jeden model hostowania zawsze wygrywa.

Uzasadniony wybór to taki, którego mechanizmy kontroli można zweryfikować. Organizacja powinna wiedzieć, gdzie działa model, kto może do niego dotrzeć, jakie dane przetwarza, jakich tożsamości używa i jak szybko można cofnąć dostęp.

Trzy sygnały pokażą, czy ekspozycja maleje

Kolejnym testem będzie to, czy opiekunowie i operatorzy przekształcą szeroko opisywany spis w mierzalne działania naprawcze.

Pierwszym sygnałem jest powtórne skanowanie internetu z użyciem tych samych odcisków. Najbardziej wymowne wskaźniki to potwierdzona łączna liczba punktów końcowych oraz odsetek chroniony przez uwierzytelnianie na poziomie sieci.

Niższa liczba punktów końcowych sugerowałaby, że operatorzy usunęli niepotrzebny publiczny dostęp. Wyższy wskaźnik uwierzytelniania pokazałby, że usługi pozostały użyteczne, zyskując jednocześnie ochronę na granicy sieciowej.

Żadna z tych zmian sama w sobie nie jest wystarczająca. Punkt końcowy może zniknąć z odcisku, ponieważ zmienił się jego baner, pozostając jednocześnie dostępny. Badacze powinni zatem dokumentować zmiany zapytań i zachowywać porównywalne pomiary.

Drugim sygnałem będą działania głównych opiekunów oprogramowania. Open WebUI zasługuje na szczególną uwagę, ponieważ reprezentowało 18 529 punktów końcowych, czyli około połowy potwierdzonej populacji Mysterium.

Ostrzeżenia dotyczące publicznego udostępniania, obowiązkowych początkowych danych uwierzytelniających, bezpieczniejszych szablonów wdrożeń i jaśniejszych wskazówek dotyczących reverse proxy wzmocniłyby szerszą tezę raportu. Milczenie lub kosmetyczne zmiany banerów pozostawiłyby problem operacyjny w dużej mierze nierozwiązany.

Twórcy agentów powinni podlegać jeszcze dokładniejszej kontroli. Flowise, RAGFlow, Dify, n8n, Langflow i podobne narzędzia potrzebują bezpiecznych ustawień domyślnych, które uwzględniają ich dostęp do sekretów i systemów zewnętrznych.

Trzecim sygnałem są dowody dotyczące podatności i incydentów. Nowe komunikaty bezpieczeństwa dotyczące autoryzacji, ujawnienia danych uwierzytelniających, zdalnego wykonywania kodu lub dostępu agentów do narzędzi pokazałyby, w jaki sposób publiczna ekspozycja może stać się ścieżką ataku.

Potwierdzone wykorzystanie podatności zwiększyłoby pilność sytuacji, ale obrońcy nie powinni na nie czekać. Brak ujawnionych incydentów nie dowodzi bezpieczeństwa, gdy właściciele zasobów mogą nie dysponować logami ani odpowiednią widocznością.

Organizacje mogą działać, zanim pojawią się te sygnały. Powinny zinwentaryzować usługi AI, sprawdzić, które interfejsy są publicznie dostępne, oraz wskazać osoby odpowiedzialne za każde wdrożenie.

Wszystko, co nie wymaga publicznego dostępu, powinno być powiązane z prywatnym interfejsem. Usługi, które muszą pozostać dostępne, powinny działać za uwierzytelnionymi bramami z ograniczonymi tożsamościami i aktualnymi poprawkami.

Twórcy agentów wymagają dodatkowego traktowania jako element infrastruktury sekretów. Zespoły powinny przejrzeć zapisane integracje, rotować ujawnione dane uwierzytelniające, kontrolować importowane przepływy pracy i rejestrować działania agentów wobec połączonych systemów.

Liczba ujawnionych endpointów AI w Mysterium z czasem się zdezaktualizuje. To naturalne. Istotne pytanie brzmi, czy kolejny wynik będzie odzwierciedlał lepsze mechanizmy kontroli, czy jedynie większy zbiór pominiętych usług.

Dla deweloperów, nabywców korporacyjnych i użytkowników AI praktyczny test jest prosty: czy organizacja potrafi wykazać, kto może dotrzeć do każdego systemu i co ten system może zrobić? Jeśli odpowiedź zależy od założeń, wdrożenie nie zapewnia kontroli, którą miało gwarantować samodzielne hostowanie.