Badacze bezpieczeństwa ostrzegają przed nowym, istotnym ryzykiem dla organizacji korzystających z własnej infrastruktury AI: wystawione punkty końcowe modeli są nadużywane jako backendowa moc obliczeniowa dla ofensywnych agentów AI.
Według Zenity Labs badacze zaobserwowali między marcem a majem 2026 roku trzech różnych operatorów, którzy próbowali wykorzystać wystawione punkty końcowe Ollama i LiteLLM jako backendy modeli do działań ofensywnych. Przypadki dotyczyły autonomicznych frameworków do testów penetracyjnych, w tym Strix i HexStrike AI, a także agenta OpenAI Codex skonfigurowanego z personą mającą ograniczać odmowy ze względów bezpieczeństwa i wspierać prace nad inżynierią wsteczną aplikacji webowych.
Najbardziej niepokojące jest to, że takie ataki niekoniecznie wymagają tradycyjnego exploita.
W wielu przypadkach atakujący musi jedynie znaleźć wystawiony punkt końcowy.
Nowe ryzyko: Bring Your Own Agent
Schemat ataku jest prosty, ale niebezpieczny.
Organizacja wdraża własną infrastrukturę AI. Infrastruktura ta udostępnia punkty końcowe inferencji, aby aplikacje mogły wywoływać model. Jeśli punkty te są osiągalne z internetu i nie mają odpowiedniego uwierzytelniania, atakujący może skonfigurować własnego agenta AI lub klienta tak, by korzystał z backendu modelu tej organizacji.
Innymi słowy, atakujący przynosi agenta, a ofiara dostarcza moc obliczeniową.
Zenity opisało to jako przejmowanie wystawionych backendów AI do prowadzenia operacji ofensywnych. Wystawione punkty końcowe obejmowały /api/generate i /api/chat w Ollama na porcie 11434 oraz /v1/responses w LiteLLM na porcie 4000.
Zmienia to źle skonfigurowaną infrastrukturę AI w coś zbliżonego do skradzionej mocy obliczeniowej w chmurze, ale z groźniejszym zwrotem: może ona stać się silnikiem rozumowania stojącym za ofensywnymi przepływami pracy w cyberprzestrzeni.
Jak działa to nadużycie
Atakujący nie musi w pełni przejmować serwera.
Zamiast tego kieruje klienta AI lub framework agentowy na wystawiony punkt końcowy i wysyła żądanie zawierające pełny kontekst operacyjny agenta.
Takie żądanie może zawierać:
- prompt systemowy
- personę agenta
- definicje narzędzi
- instrukcje operacyjne
- szczegóły celu
- cele zadania
Zenity zauważyło, że operatorzy często najpierw wysyłali niewielką sondę „hello”, aby potwierdzić, że punkt końcowy odpowiada, a dopiero potem przesyłali pełny ładunek agenta.
Ma to znaczenie dla obrońców, ponieważ złośliwa logika nie zawsze jest przechowywana na serwerze. Może dotrzeć w treści żądania.
Oznacza to, że tradycyjne wskaźniki przejęcia serwera mogą nie występować. Infrastruktura może po prostu robić to, do czego została skonfigurowana: odpowiadać na żądania do modelu.
Trzy zaobserwowane kampanie
Zenity zaobserwowało trzy różne przykłady nadużywania wystawionej infrastruktury AI.
Pierwszy dotyczył Strix, autonomicznego agenta AI do testów penetracyjnych. Pojedyncze źródłowe IP wysłało bardzo duży prompt zawierający instrukcje Strix i próbowało skierować agenta przeciwko działającemu celowi należącemu do osoby trzeciej. Zenity twierdzi, że próbę wykryto i zablokowano przed jej ukończeniem.
Drugi dotyczył HexStrike AI, frameworka do orkiestracji narzędzi ofensywnych, zawierającego ponad 150 narzędzi. W tym przypadku atakujący skierował desktopowego klienta LLM na instancję Ollama i załadował szeroki zestaw narzędzi ofensywnych. Nie wskazano żadnego działającego celu, co sugeruje, że operator mógł przygotowywać lub testować konfigurację.
Trzeci dotyczył agenta OpenAI Codex przekierowanego przez proxy LiteLLM. Agent został skonfigurowany z personą w stylu audytora bezpieczeństwa i instrukcjami związanymi z inżynierią wsteczną aplikacji webowych. Zenity podało, że przechwycona struktura żądania odpowiadała aktywności typowej dla Codexa, choć nagłówki żądań zawsze można sfałszować.
Razem przypadki te pokazują wyraźną zmianę: atakujący uczą się wykorzystywać wystawioną infrastrukturę AI jako element swojego procesu operacyjnego.
Dlaczego Ollama i LiteLLM są atrakcyjnymi celami
Część problemu wynika ze sposobu, w jaki te narzędzia są zwykle wdrażane.
Ollama jest powszechnie używana do lokalnego hostowania modeli. Domyślnie jest przeznaczona do użytku lokalnego, ale można ją błędnie skonfigurować tak, aby nasłuchiwała na wszystkich interfejsach i była osiągalna spoza hosta.
LiteLLM jest szeroko stosowany jako proxy lub brama do kierowania żądań do modeli między różnymi dostawcami i systemami wewnętrznymi. Według Zenity uwierzytelnianie w LiteLLM zależy od tego, czy operator ustawi klucz główny, a w rzeczywistych atakach zaobserwowano klucze zastępcze, takie jak sk-1234.
Problemem nie jest to, że te narzędzia są z natury złośliwe.
Problemem jest wystawienie na zewnątrz w połączeniu ze słabym lub brakującym uwierzytelnianiem.
Backend modelu, który miał obsługiwać aplikacje wewnętrzne, może stać się publicznym zasobem dla każdego, kto go znajdzie.
Dlaczego ma to znaczenie dla zespołów bezpieczeństwa
To nie jest tylko kradzież darmowej mocy obliczeniowej.
Atakujący nie używają wystawionych punktów końcowych AI jedynie do uruchamiania nieszkodliwych promptów ani oszczędzania na kosztach inferencji. Próbują połączyć te punkty z przepływami pracy agentów, które mogą wspierać rozpoznanie, testy penetracyjne, inżynierię wsteczną i inne operacje ofensywne.
To zmienia model ryzyka.
Publiczny backend AI może stać się:
- darmowym backendem modeli dla atakujących
- ukrytą warstwą obliczeniową dla agentów ofensywnych
- sposobem na kierowanie aktywności przez legalną infrastrukturę
- źródłem nadużyć kosztowych
- potencjalnym ryzykiem w zakresie zgodności i ryzykiem prawnym
- wyzwaniem dla widoczności po stronie zespołów bezpieczeństwa
Jeśli agent atakującego wykorzystuje infrastrukturę AI organizacji do wsparcia działań przeciwko osobie trzeciej, organizacja-ofiara może zostać wciągnięta w incydent, którego nie wywołała.
Szansa na wykrywanie
Istnieje też przewaga po stronie obrony.
Zenity wskazuje, że żądania agentów często zawierają pełny kontekst operacyjny w treści żądania. Może to obejmować personę, listę narzędzi, instrukcje, a czasem nawet cel.
Dla obrońców oznacza to, że inspekcja treści żądań może być cenna.
Zespoły bezpieczeństwa powinny szukać oznak tego, że przychodzące żądania do modeli nie są zwykłymi promptami użytkowników. Podejrzane wskaźniki mogą obejmować nietypowo duże treści żądań, pełne tablice narzędzi, słownictwo z zakresu ofensywnego bezpieczeństwa, niebezpieczne persony, nieznane nazwy modeli lub klientów próbujących użyć modeli, których organizacja faktycznie nie hostuje.
Kluczowe jest traktowanie ruchu inferencji AI jako ruchu istotnego dla bezpieczeństwa.
Żądania do modeli nie są już tylko wywołaniami aplikacji. Mogą zawierać pełną logikę agenta kontrolowanego przez atakującego.
Zalecane działania obronne
Organizacje korzystające z własnej infrastruktury AI powinny niezwłocznie sprawdzić, co jest wystawione na zewnątrz.
Najważniejszy krok jest prosty: nie wystawiaj backendów modeli bezpośrednio do internetu, chyba że istnieje wyraźna potrzeba biznesowa i wdrożono odpowiednie zabezpieczenia.
Zespoły bezpieczeństwa powinny:
- powiązać Ollama i podobne narzędzia z localhostem lub interfejsami prywatnymi
- umieścić backendy AI za uwierzytelnianymi zwrotnymi serwerami proxy
- wymagać prawdziwego uwierzytelniania w LiteLLM i odrzucać klucze zastępcze
- monitorować dostęp do punktów końcowych Ollama i LiteLLM
- sprawdzać treści przychodzących żądań ze źródeł zewnętrznych
- blokować podejrzane ładunki agentów i definicje narzędzi ofensywnych
- alarmować o zbyt dużych promptach lub pełnych tablicach narzędzi
- ograniczyć dostęp do znanych aplikacji i użytkowników wewnętrznych
- rejestrować użycie modeli, źródłowe adresy IP i nietypowe wzorce żądań
- monitorować nieoczekiwane skoki kosztów lub nietypową aktywność modeli
Zenity zaleca również obserwowanie powszechnie nadużywanych punktów końcowych oraz blokowanie wzorców żądań powiązanych z agentami ofensywnymi, niebezpiecznymi personami i narzędziami, które nie powinny pojawiać się w normalnym biznesowym użyciu AI.
Nowa powierzchnia ataku dla CISO
Dla CISO wniosek jest jasny: infrastruktura AI jest teraz częścią powierzchni ataku przedsiębiorstwa.
Ryzyko nie ogranicza się do promptów, wycieku danych czy użycia AI poza kontrolą IT (shadow AI). Wystawione punkty końcowe modeli mogą zostać aktywnie przejęte przez osoby z zewnątrz i zamienione w infrastrukturę do operacji ofensywnych.
Tworzy to nową klasę pytań dla liderów bezpieczeństwa:
Kto może dotrzeć do naszych punktów końcowych modeli?
Które bramy AI są dostępne z internetu?
Czy domyślne klucze lub tokeny zastępcze są nadal akceptowane?
Czy sprawdzamy treści żądań do modeli?
Czy potrafimy wykrywać ładunki agentowe?
Czy wiemy, jakich narzędzi mogą używać nasi agenci AI?
Pytania te powinny stać się częścią programów bezpieczeństwa chmury, bezpieczeństwa aplikacji i zarządzania AI.
Podsumowanie
Ustalenia Zenity pokazują, że atakujący coraz lepiej orientują się w AI.
Rozumieją, jak działają frameworki agentowe. Wiedzą, jak kierować klientów na wystawione backendy modeli. Eksperymentują z autonomicznymi frameworkami do testów penetracyjnych, zestawami narzędzi ofensywnych i przepływami pracy z inżynierią wsteczną wspomaganą przez AI.
To ostrzeżenie dla każdej organizacji wdrażającej infrastrukturę AI.
Wystawiony punkt końcowy LLM to nie tylko kolejny otwarty port. Może stać się mózgiem cudzego ataku.
Kluczowa lekcja jest prosta: traktuj backendy AI jak infrastrukturę produkcyjną. Zabezpiecz je, wymagaj uwierzytelniania, sprawdzaj ruch, monitoruj użycie i zakładaj, że każdy publiczny system AI zostanie szybko odkryty przez atakujących.
