Ostrzeżenie Google przed LLM-jackingiem ujawnia mroczny rynek skradzionego dostępu do AI

Google ostrzegł, że ataki LLM-jacking gwałtownie rosną, ponieważ przestępcy coraz częściej kradną konta AI, poświadczenia API oraz firmowe zasoby chmurowe.

Sprzedawcy z podziemia mają reklamować nieautoryzowany dostęp do modeli Google, Anthropic i OpenAI z rabatami sięgającymi 97%. Wartość ta opisuje zaobserwowane oferty na platformach handlowych, a nie niezależnie zweryfikowaną średnią cenę transakcyjną.

Istotniejsze ustalenie kryje się jednak za tym nagłówkiem. Dostęp do AI stał się zbywalnym aktywem przestępczym, podobnie jak skradzione karty płatnicze, konta chmurowe i domowe połączenia proxy.

Google Threat Intelligence Group informuje, że w 2026 roku zaobserwował więcej kupujących i sprzedających konta AI. Popyt koncentrował się wokół poświadczeń Claude i Gemini, a także produktów AI do programowania, takich jak Cursor Pro i Devin.

Nie jest to wyłącznie oszustwo subskrypcyjne. Atakujący mogą ukraść klucz API lub tożsamość chmurową, kierować zapytania przez konto innej firmy i pozostawić ofiarę odpowiedzialną za tę aktywność.

Wynikające z tego zagrożenie łączy nieoczekiwane zużycie zasobów, wyciek danych, zakłócenia usług oraz przestępcze wykorzystanie zaufanej infrastruktury. Stanowi też wyzwanie dla programów bezpieczeństwa, które wciąż traktują wydatki na AI jak budżet na oprogramowanie, a nie jak kontrolowany zasób obliczeniowy.

Wcześniejsze kampanie przejmowania zasobów zwykle dotyczyły kopania kryptowalut lub mocy proxy. LLM-jacking kieruje tę samą logikę ekonomiczną na inferencję modeli, agentów dla programistów oraz infrastrukturę potrzebną do ich działania.

Konflikt jest więc większy niż spór przestępców z dostawcami AI. To starcie skradzionego dostępu z kontrolą przedsiębiorstwa, a każdy nieśledzony klucz lub nadmiernie uprzywilejowane obciążenie zwiększa podaż na tym rynku.

Co właściwie mówi ostrzeżenie Google przed LLM-jackingiem

Dowody Google pokazują, że przestępcy budują łańcuch dostaw wokół przejętego dostępu do AI, a nie tylko eksperymentują z pojedynczymi skradzionymi kontami.

Wrześniowy monitor zagrożeń AI Google z 2026 roku opisuje wzrost kradzieży, eksfiltracji i sprzedaży kont AI w społecznościach cyberprzestępczych.

Google twierdzi, że w 2026 roku więcej person z podziemia poszukiwało kont związanych z AI. W porównaniu z poprzednim rokiem firma zaobserwowała też więcej sprzedawców reklamujących takie konta.

Według postów śledzonych przez Google średnie ceny za konto na tych rynkach wzrosły w 2026 roku ponad dwukrotnie. Wzrost ten sugeruje rosnący popyt, mimo że niektóre pojedyncze oferty obiecywały skrajne rabaty.

Ta pozorna sprzeczność ma sens na nielegalnym rynku. Kupujący cenią dostęp, ponieważ legalna inferencja i obliczenia o wysokiej wydajności wymagają ograniczonych, rozliczanych zasobów.

Skradzione konto może przenieść te koszty na ofiarę. Sprzedawca może więc oferować ceny niższe od legalnego dostępu, nie utrzymując porównywalnej infrastruktury.

Doniesienia o rabatach sięgających 97% wydają się opisywać najgłębsze oferty z podziemia. Publiczny raport Google nie przedstawia tej wartości jako średniej dla całego rynku.

Nie ujawnia też łącznej liczby ofiar, zagregowanych strat finansowych ani zweryfikowanego wolumenu transakcji. Te braki ograniczają możliwość oszacowania pełnej skali rynku.

Jednak podstawowa działalność jest udokumentowana pewniej niż wartość z nagłówka. Google zaobserwował wzrost popytu, ukierunkowane kradzieże poświadczeń oraz przejęcia chmur wspierające nieautoryzowane obciążenia AI.

Firma nazywa wersję infrastrukturalną tego zjawiska „LLMJacking”. Termin obejmuje przejmowanie firmowych zasobów chmurowych w celu uruchamiania modeli AI lub korzystania z hostowanych usług modeli bez autoryzacji.

Google wskazuje również metody pozyskiwania kont wykraczające poza bezpośrednią kradzież. Aktorzy zagrożeń korzystają z automatycznych rejestracji, pul kont, przekaźników proxy i oprogramowania pośredniczącego agregującego wiele kluczy.

Systemy te mogą rozdzielać zapytania między konta i ukrywać ich pochodzenie. Mogą też zastępować wyłączone poświadczenia bez zmiany interfejsu kupującego.

Taka struktura przekształca przejęty dostęp w usługę. Kupujący nie muszą wiedzieć, która organizacja opłaca rachunek bazowy.

Rynek ma obejmować poświadczenia do konsumenckich kont AI, asystentów programistycznych i API modeli. Te zasoby znacząco różnią się pod względem tego, co mogą ujawnić.

Skradzione konto czatu może ujawnić historię rozmów i przesłane dokumenty. Poświadczenie API może zapewnić programowalny dostęp do limitu, modelu lub połączonego projektu chmurowego.

Przejęta tożsamość chmurowa niesie najszersze ryzyko. Może umożliwić intruzowi udostępnianie infrastruktury, wykrywanie przechowywanych poświadczeń lub dostęp do sąsiednich usług firmowych.

Ostrzeżenie Google łączy te warstwy w jedną gospodarkę. Skradzione konta zapewniają natychmiastowy dostęp, a przejęta infrastruktura dostarcza trwałą moc obliczeniową.

To połączenie wyjaśnia, dlaczego zagrożenie wykracza poza jednego dostawcę. Google, Anthropic i OpenAI konkurują o legalnych klientów, lecz przestępcy mogą handlować dostępem do wszystkich trzech jako wymiennym zasobem.

Dlaczego dostęp do AI stał się cennym zasobem dla przestępców

Wzrost LLM-jackingu odzwierciedla podstawową zmianę ekonomiczną: dostęp do modeli zapewnia obecnie użyteczną, skalowalną moc obliczeniową, której przestępcy nie chcą finansować sami.

Grupy przestępcze od dawna kradną infrastrukturę, gdy przejęty zasób może generować przychód. Kopanie kryptowalut uczyniło przejęte procesory wartościowymi, ponieważ moc obliczeniowa bezpośrednio przekładała się na aktywa cyfrowe.

Proxyjacking stworzył kolejny rynek, kierując ruch przez systemy ofiar. Atakujący mogli sprzedawać przepustowość oraz wiarygodnie wyglądające domowe lub firmowe adresy.

LLM-jacking rozszerza ten model na inferencję. Skradzionym zasobem jest możliwość wysyłania promptów, generowania wyników, obsługi agentów lub uruchamiania modeli na przejętym sprzęcie.

MITRE klasyfikuje to szersze zachowanie jako przejmowanie zasobów. Jego framework obejmuje nadużywanie zasobów obliczeniowych, przepustowości, komunikacji i usług chmurowych.

AI czyni tę możliwość bardziej elastyczną. Jedno poświadczenie może wspierać generowanie kodu, rekonesans, produkcję treści, tłumaczenia, przygotowywanie phishingu lub zautomatyzowany ofensywny przepływ pracy.

To samo poświadczenie może również zapewnić dostęp do wyższych limitów lub możliwości niedostępnych przez anonimowe darmowe konto. Ma to znaczenie, gdy operacja zależy od ciągłej automatyzacji.

Google twierdzi, że dostęp premium i obliczenia o wysokiej wydajności pozostają istotnymi barierami dla atakujących. Kradzież tych zasobów obniża barierę bez konieczności budowania przez przestępców platformy AI.

Rynek może obsługiwać kilka rodzajów kupujących. Niektórzy chcą niedrogiego, ogólnego dostępu do modeli, inni zaś szukają kont odpornych na wykorzystanie na dużą skalę lub sprzeczne z zasadami.

Bardziej zaawansowane grupy mogą łączyć skradziony dostęp z systemami orkiestracji. Systemy te automatycznie wybierają konta, rotują punkty końcowe, ponawiają nieudane zapytania i rozdzielają pracę.

Majowe badania zagrożeń Google z 2026 roku udokumentowały przekaźniki proxy i zautomatyzowane procesy rejestracji używane do uprzemysłowienia dostępu do komercyjnych modeli.

Raport opisał przeglądarki anti-detect, pule kont oraz własne oprogramowanie pośredniczące zaprojektowane, by omijać ograniczenia rozliczeniowe lub egzekwowanie zasad platformy. Mechanizmy te zmniejszają zależność od pojedynczego poświadczenia.

Utrudniają również atrybucję. Ruch docierający do dostawcy może przechodzić przez przekaźniki i przejęte projekty, zanim gdzie indziej doprowadzi do złośliwego rezultatu.

Dla ofiary korporacyjnej pierwszym oczywistym sygnałem może być nietypowe zużycie modeli. Atakujący mógł jednak uzyskać dostęp przez urządzenie programisty kilka dni wcześniej.

Infostealer, czyli złośliwe oprogramowanie zaprojektowane do zbierania poświadczeń i danych sesyjnych, może przeszukiwać lokalne pliki w poszukiwaniu informacji konfiguracyjnych AI. Następnie może wyeksportować wszystko, co użyteczne, do swojego operatora.

Google zaobserwował operatorów ACRSTEALER atakujących magazyny konfiguracji powiązane z Cline i Continue AI. Pliki te mogą zawierać klucze API w postaci zwykłego tekstu lub niestandardowe punkty końcowe routingu.

Ten szczegół sprawia, że środowiska AI dla programistów są szczególnie ważne. Asystenci programistyczni często działają w pobliżu repozytoriów kodu źródłowego, rejestrów pakietów, terminali i narzędzi chmurowych.

Skradzione poświadczenie z takiego środowiska może zapewnić więcej niż dostęp do modelu. Może pomóc atakującym zmapować stos programistyczny albo zidentyfikować drogę do systemów produkcyjnych.

Rosnący rynek wywiera więc jednocześnie presję na liderów bezpieczeństwa, menedżerów inżynierii oraz zespoły finansowe odpowiedzialne za chmurę. Każda grupa widzi inny fragment incydentu.

Bezpieczeństwo widzi przejętą tożsamość. Inżynieria widzi nieudane zapytania lub wyczerpane limity. Finanse widzą niewyjaśnione zużycie, gdy dostęp został już zmonetyzowany.

Bez wspólnego monitorowania te fragmenty mogą nigdy nie zostać połączone w jeden incydent. Mroczny rynek korzysta na takim opóźnieniu organizacyjnym.

Ostrzeżenie Google przed LLM-jackingiem zwiększa presję na kontrolę tożsamości

Główny problem nie polega na tym, że modele nagle stały się łatwe do zhakowania. Atakujący kradną tożsamości i infrastrukturę, które je otaczają.

Badania Google rozróżniają ataki na zasoby AI od skutecznych przejęć samych zaawansowanych modeli. Zaobserwowana aktywność koncentruje się przede wszystkim na poświadczeniach, konektorach, konfiguracjach programistycznych, projektach chmurowych i warstwach orkiestracji.

To rozróżnienie ma znaczenie, ponieważ mechanizmy bezpieczeństwa modeli nie mogą unieważnić ujawnionego firmowego klucza. Nie mogą też skorygować roli tożsamości, która przyznaje niepotrzebny dostęp w całym środowisku chmurowym.

Poświadczenie typu bearer pozwala jego posiadaczowi działać z uprawnieniami przypisanymi do tego poświadczenia. System może nie wiedzieć, czy zapytanie pochodzi od właściciela, czy od złodzieja.

Długotrwałe klucze API utrudniają zarządzanie tą słabością. Często pozostają aktywne po zmianach personelu, porzuconych prototypach i migracjach między dostawcami AI.

Programiści mogą kopiować je do lokalnych plików konfiguracyjnych dla wygody. Zautomatyzowane narzędzia mogą również generować klucze bez umieszczania ich w istniejącym rejestrze bezpieczeństwa.

Rezultatem jest rozproszenie poświadczeń. Organizacje wiedzą, które narzędzia AI zatwierdziły, lecz niekoniecznie które tożsamości, klucze, rozszerzenia i lokalni agenci mogą uzyskać do nich dostęp.

LLM-jacking przekształca tę lukę w zarządzaniu w towar dla przestępców. Każde poświadczenie wielokrotnego użytku staje się potencjalnym produktem.

Wyzwanie dla bezpieczeństwa rośnie, gdy organizacje łączą modele z wewnętrznymi danymi. Asystent AI może mieć dostęp do kodu źródłowego, dokumentów technicznych, rejestrów wsparcia lub dyskusji projektowych.

Jeśli intruz ukradnie sesję asystenta, incydent może ujawnić zapisane rozmowy lub połączone zasoby. Jeśli atakujący ukradnie wyłącznie klucz API, bezpośrednie ujawnienie danych zależy od jego uprawnień.

Tych scenariuszy nie należy łączyć w jedno twierdzenie. Przejęty klucz nie daje automatycznie dostępu do każdego promptu ani wewnętrznego systemu.

Zespoły nie powinny jednak zakładać, że nieautoryzowane użycie tworzy wyłącznie problem rozliczeniowy. Dzienniki, wyniki modeli, połączone narzędzia i kontekst aplikacji mogą zawierać wrażliwe informacje.

Ryzyko staje się większe w przypadku agentów. Agent może wywoływać narzędzia, pobierać dokumenty, wykonywać zatwierdzone działania i zachowywać kontekst operacyjny przez cały przepływ pracy.

Możliwości te są użyteczne, ponieważ ograniczają pracę ręczną. Są niebezpieczne, gdy podstawowa tożsamość nie ma wąskich uprawnień i wiarygodnych ścieżek audytu.

Google poinformował, że atakujący zmierzają w stronę operacji agentowych, z mniejszym udziałem opóźnień wynikających z działań człowieka. W jednym przypadku z drugiego kwartału przejęty zasób chmurowy wsparł masową kampanię wykradania poświadczeń w mniej niż sześć godzin.

Ten przykład nie dowodzi, że każde skradzione konto AI posłuży do przeprowadzenia autonomicznego ataku. Pokazuje jednak, dlaczego powolne, ręczne łańcuchy zatwierdzeń nie mogą pozostać jedynym mechanizmem obronnym.

Przedsiębiorstwa muszą wiedzieć, które tożsamości mogą korzystać z modeli, które aplikacje są ich właścicielami oraz jak wygląda normalne zużycie. Potrzebują też szybkiego sposobu zawieszania dostępu.

Wymaga to koordynacji wykraczającej poza centrum operacji bezpieczeństwa. Zespoły platformowe muszą zapewnić obserwowalność poświadczeń, a zespoły zakupowe — powiązać faktury z konkretnymi właścicielami i obciążeniami.

Deweloperzy potrzebują także zatwierdzonych sposobów przechowywania i rotacji poświadczeń, które pozostają wygodne w użyciu. Jeśli bezpieczny proces będzie powodował zbyt duże tarcie, niezarządzane lokalne alternatywy będą się nadal rozpowszechniać.

Zwycięzcą w tym konflikcie nie będzie firma z najdłuższą polityką dopuszczalnego użytkowania. Będzie nim firma, która potrafi szybko identyfikować, ograniczać i cofać dostęp do AI.

Łańcuch ataku zaczyna się przed pierwszym podejrzanym promptem

LLM-jacking zwykle odnosi sukces dzięki znanej kradzieży poświadczeń i nadużyciom w chmurze, a następnie wykorzystuje zużycie AI jako warstwę monetyzacji.

Typowa ścieżka zaczyna się na stacji roboczej dewelopera. Phishing, złośliwe oprogramowanie, przejęty pakiet lub zwodnicze rozszerzenie przeglądarki mogą dostarczyć infostealer.

Złośliwe oprogramowanie przeszukuje przeglądarki, katalogi konfiguracji, historię poleceń, pliki środowiskowe i magazyny aplikacji. Narzędzia do rozwoju AI tworzą dodatkowe cele, ponieważ wiele z nich wymaga poświadczeń do modeli.

Po kradzieży klucz można testować automatycznie. Operatorzy przestępczy mogą zidentyfikować jego dostawcę, dostępny limit, ograniczenia oraz to, czy poświadczenie nadal działa.

Przydatne poświadczenia mogą zostać sprzedane bezpośrednio lub załadowane do przekaźnika. Przekaźnik przyjmuje żądania od klientów i przekazuje je przez jedno lub więcej przejętych kont.

Klient widzi stabilny punkt końcowy usługi. W tle operator może zastąpić cofnięte poświadczenie, rozproszyć zużycie lub kierować konkretne obciążenia do różnych modeli.

To rozdzielenie chroni kupującego przed niestabilnością pojedynczych skradzionych kont. Pozwala też sprzedającemu monetyzować jedną kolekcję poświadczeń wśród wielu klientów.

Przejęcie chmury tworzy kolejną ścieżkę. Atakujący mogą uzyskać tożsamość pozwalającą im aktywować usługi modeli lub wdrażać infrastrukturę hostowaną samodzielnie.

Mogą następnie korzystać z hostowanego wnioskowania przez projekt ofiary. Alternatywnie mogą wykorzystać skradzioną moc obliczeniową do bezpośredniego uruchomienia modelu.

Firma bezpieczeństwa Sysdig ukuła w 2024 roku termin LLMjacking na określenie używania skradzionych poświadczeń chmurowych do korzystania z płatnych usług modeli. Jej późniejsze badanie LLMjacking opisuje rozwój w kierunku ofensywnych obciążeń agentowych.

Modele hostowane samodzielnie stwarzają powiązane zagrożenie. Dostępny z internetu serwer wnioskowania bez uwierzytelniania może oferować darmową przepustowość każdemu, kto go odkryje.

Ta droga nie wymaga skradzionego klucza API. Słabość leży w wystawionej usłudze i niewystarczających kontrolach sieciowych.

Skutek może nadal przypominać LLM-jacking, ponieważ osoba z zewnątrz korzysta z infrastruktury AI organizacji. Jednak działania naprawcze różnią się od dochodzenia dotyczącego kradzieży konta.

Zespoły muszą rozróżniać co najmniej trzy rodzaje incydentów: przejęte sesje użytkowników, skradzione poświadczenia do modeli oraz przejętą infrastrukturę chmurową lub hostowaną samodzielnie.

Kradzież sesji wymaga cofnięcia dostępu do konta, zbadania urządzenia i przeglądu ujawnionych treści. Kradzież klucza API wymaga rotacji klucza, analizy logów i weryfikacji powiązanych uprawnień.

Przejęcie infrastruktury wymaga szerszej reakcji na incydent. Dochodzeniowcy muszą ustalić, w jaki sposób atakujący uzyskał dostęp, jakie zasoby utworzył i czy utrzymuje trwały dostęp.

Anomalie zużycia mogą ujawnić wszystkie trzy przypadki, ale same w sobie nie są wystarczające. Legalne wprowadzenie produktu na rynek również może wywołać nagły ruch związany z modelami.

Przydatne wykrywanie łączy wolumen, tożsamość, geografię, czas, wybór modelu i zachowanie aplikacji. Obciążenie, które zmienia kilka wymiarów jednocześnie, zasługuje na szybką weryfikację.

Zespoły powinny także monitorować żądania odrzucone przez mechanizmy bezpieczeństwa. Takie zdarzenia mogą wskazywać na nadużycia, choć zaawansowani atakujący mogą wykorzystywać nieszkodliwe zadania lub własne modele.

Najlepsze kontrole ograniczają zarówno prawdopodobieństwo, jak i wpływ. Krótkotrwałe poświadczenia zawężają okno działania, a tożsamości przypisane do konkretnych obciążeń ograniczają zakres, do którego może dotrzeć skradzione poświadczenie.

Ograniczenia sieciowe mogą blokować użycie z nieoczekiwanych środowisk. Limity i pułapy zużycia mogą spowolnić nadużycia, gdy osoby reagujące prowadzą dochodzenie.

Żadna z tych kontroli nie zapewnia pewności. Razem sprawiają, że skradziony dostęp jest mniej niezawodny, a przez to mniej wartościowy dla sprzedawców na podziemnym rynku.

Czego nie dowodzi twierdzenie o 97% rabacie

Dramatyczny rabat jest użytecznym sygnałem ostrzegawczym, ale nie mierzy rzeczywistej wielkości rynku, jego niezawodności ani skutków finansowych.

Ogłoszenie na podziemnym rynku nie jest sfinalizowaną sprzedażą. Sprzedawcy mogą wyolbrzymiać jakość dostępu, rodzaj konta, pozostały limit lub czas do cofnięcia dostępu.

Reklamowany produkt może również różnić się od legalnego dostępu. Kupujący mogą otrzymać współdzielony serwer proxy, sesję przeglądarki lub krótkotrwałe konto zamiast przenoszalnej subskrypcji.

To rozróżnienie zmienia sposób obliczania rabatu. Porównanie niestabilnego przestępczego przekaźnika z niezawodnym, wspieranym dostępem może prowadzić do mylącego odsetka.

Liczba ta nie ujawnia również, kto poniósł koszt podstawowego zużycia. Część dostępu może pochodzić ze skradzionych poświadczeń, podczas gdy inne oferty mogą wykorzystywać okresy próbne lub automatyczne tworzenie kont.

Google udokumentował wszystkie te ścieżki pozyskiwania dostępu. Publiczne dowody nie przypisują każdej z nich procentowego udziału w rynku.

Raport nie ustala też, że atakujący naruszyli podstawową infrastrukturę modeli Google, Anthropic lub OpenAI. Obserwowany rynek w dużej mierze zależy od przejętych klientów i ekosystemów kont.

Ten niuans powinien kształtować reakcję. Przedsiębiorstwa nie mogą czekać, aż dostawcy rozwiążą każdy przypadek, ponieważ wiele luk istnieje w tożsamościach i urządzeniach zarządzanych przez klientów.

Dostawcy nadal ponoszą istotną odpowiedzialność. Mogą wykrywać współdzielenie kont, podejrzane przekaźniki, niemożliwe wzorce użycia oraz skoordynowane nadużycia rejestracyjne na swoich platformach.

Google twierdzi, że wykorzystuje analizę zagrożeń do wzmacniania zabezpieczeń oraz wyłączania złośliwych projektów lub kont. Takie egzekwowanie zasad może zwiększyć koszt utrzymywania podziemnej usługi.

Działania dostawców wprowadzają jednak kolejną niepewność. Agresywne automatyczne blokowanie może zakłócić działanie legalnej współdzielonej infrastruktury lub globalnie rozproszonych zespołów deweloperskich.

Systemy bezpieczeństwa potrzebują więc dowodów wykraczających poza pojedynczy skok ruchu. Muszą szybko rozróżniać wprowadzenie produktu na rynek, błędnie skonfigurowaną aplikację i skradzione poświadczenie.

Brak zbiorczych danych o stratach ogranicza również porównania z ransomware, cryptojackingiem i innymi zagrożeniami chmurowymi. LLM-jacking może być powszechny, a jednocześnie powodować umiarkowane straty na ofiarę.

Możliwy jest także odwrotny wzorzec. Mniejsza liczba przejęć chmury może generować poważne ryzyko, ponieważ skradziona tożsamość zapewnia dostęp do cennych danych i infrastruktury.

Telemetria Google wyznacza kolejną granicę. Zapewnia silny wgląd we własny ekosystem i działania związane z reagowaniem na incydenty, ale nie obejmuje każdego dostawcy ani każdej podziemnej transakcji.

Niezależne badania pomagają potwierdzić wzorzec ataku. Nadal nie mogą jednak przekształcić fragmentarycznych obserwacji w pełną globalną ocenę wielkości rynku.

Uzasadniony wniosek jest węższy i bardziej użyteczny. Istnieje przestępczy popyt, sprzedawcy na niego odpowiadają, a skradziony dostęp do AI ma obecnie powtarzalną ścieżkę monetyzacji.

Ten wniosek nie wymaga przyjmowania każdego ogłoszenia z dark webu za dobrą monetę. Wymaga traktowania poświadczeń AI jako aktywów, których atakujący aktywnie poszukują.

Sceptyczna interpretacja wzmacnia zatem lekcję operacyjną. Zespoły powinny reagować na zweryfikowane mechanizmy ataku, a nie budować politykę wokół jednej promocyjnej liczby od nielegalnego sprzedawcy.

Trzy sygnały pokażą, czy LLM-Jacking nadal rośnie

Kolejny etap stanie się widoczny dzięki celowaniu przez kradnące poświadczenia malware, egzekwowaniu zasad przez dostawców oraz anomaliom zużycia w przedsiębiorstwach.

Pierwszym sygnałem będzie to, czy infostealery rozszerzają celowanie w pliki konfiguracji AI. Google zaobserwował już kontrolery złośliwego oprogramowania szukające konkretnych sekretów asystentów programowania.

Nowe reguły ukierunkowane na dodatkowych agentów, routery modeli i lokalne narzędzia deweloperskie wskazywałyby, że atakujący nadal znajdują tam wartościowe poświadczenia.

Zespoły bezpieczeństwa powinny więc sprawdzać wykrycia na punktach końcowych pod kątem nietypowych wyszukiwań w katalogach konfiguracji. Powinny również zinwentaryzować aplikacje, które lokalnie przechowują poświadczenia do modeli.

Drugim sygnałem będzie egzekwowanie zasad przez dostawców. Warto obserwować ujawnienia dotyczące wyłączonych pul kont, zlikwidowanych sieci przekaźników, bardziej rygorystycznych kontroli rejestracji i węższych opcji uwierzytelniania.

Silniejsze egzekwowanie potwierdziłoby, że dostawcy obserwują skoordynowane nadużycia na znaczącą skalę. Może też popchnąć przestępców w stronę modeli hostowanych samodzielnie i bezpośredniego przejmowania chmury.

To przesunięcie ma znaczenie. Blokowanie skradzionych kont konsumenckich nie kończy popytu na tanią moc obliczeniową.

Trzecim sygnałem będzie telemetria przedsiębiorstw. Niewyjaśniony wzrost liczby żądań wnioskowania, użycie nowych modeli, nieznane regiony lub zużycie poza oknami wdrożeniowymi mogą ujawnić przejęty dostęp.

Model przejęcia usług chmurowych MITRE zaleca szukanie nagłych zmian zasobów i nieautoryzowanego korzystania z usług. Zespoły AI mogą dostosować tę logikę do tokenów, żądań, punktów końcowych i rodzin modeli.

Wskazówki Google dotyczące kluczy API zalecają ograniczenia, monitorowanie użycia, izolowane klucze, okresową rotację i silniejsze uwierzytelnianie tam, gdzie jest dostępne.

Zespoły powinny przełożyć te zasady na reguły własności. Każde poświadczenie modelu potrzebuje wskazanej aplikacji, odpowiedzialnego zespołu, zatwierdzonego środowiska i udokumentowanej ścieżki cofnięcia dostępu.

Należy unikać współdzielenia jednego klucza między osobami i obciążeniami. Oddzielne poświadczenia tworzą lepsze ścieżki audytu i ograniczają zasięg pojedynczego przejęcia.

Nie przechowuj sekretów produkcyjnych w repozytoriach, notatnikach, kodzie dostępnym z poziomu przeglądarki ani luźno zarządzanych plikach lokalnych. Korzystaj z zarządzanego magazynu sekretów i automatyzuj dostarczanie poświadczeń.

Preferuj krótkotrwałe poświadczenia tożsamości, jeśli dostawcy je obsługują. Tymczasowe poświadczenie daje atakującym mniej czasu na przetestowanie, przygotowanie i odsprzedanie dostępu.

Ustaw alerty zużycia na poziomie obciążenia, a nie tylko dla całego konta chmurowego. Zagregowane rozliczenia mogą ukryć nadużycia w ramach normalnego wzrostu przedsiębiorstwa.

Monitoruj odrzucone żądania i nagłe zmiany w wyborze modeli. Przejęta aplikacja, która nagle wywołuje inne modele, może ujawnić eksperymenty atakującego.

Ogranicz, z których usług, aplikacji, sieci i metod może korzystać każda tożsamość. Zasada najmniejszych uprawnień zmienia skradziony klucz z poświadczenia nadrzędnego w ograniczony zasób.

Przeglądaj narzędzia połączone z AI z taką samą dyscypliną jak repozytoria źródłowe i konsole chmurowe. Agenci mogą dziedziczyć wrażliwe uprawnienia przez konektory, które zespoły pomijają.

Utrzymuj playbook reagowania na incydenty dotyczące poświadczeń AI. Powinien obejmować cofnięcie dostępu, zachowanie logów, inspekcję punktów końcowych, powiadomienie dostawcy oraz sprawdzenie sąsiedniego dostępu do chmury.

Przeszukiwalna baza wiedzy inżynieryjnej może pomóc zespołom zachować rejestry własności i procedury reagowania. Nigdy nie powinna zawierać aktywnych sekretów.

Ostrzeżenie Google dotyczące LLM-jackingu zmienia pytanie, które powinny zadawać przedsiębiorstwa. Problemem nie jest już to, czy przestępcy cenią dostęp do AI, ponieważ podziemny rynek jasno pokazuje, że tak.

Praktyczne pytanie brzmi, czy Twoja organizacja potrafi zidentyfikować każde poświadczenie docierające do modelu, wykryć nietypowe użycie oraz odebrać dostęp, zanim stanie się on towarem.

Przeprowadź audyt tych poświadczeń już teraz. Przypisz właściciela do każdego pozostałego klucza, usuń porzucony dostęp i przetestuj proces unieważniania w realistycznych warunkach.