Ataki Google LLM-Jacking zmieniają dostęp do AI w kradziony towar
Google twierdzi, że przestępcy kradną konta AI i poświadczenia chmurowe, ponieważ koszt zaawansowanych modeli tworzy rosnący podziemny rynek dostępu.
Ostrzeżenie z września 2026 roku przesuwa punkt ciężkości w bezpieczeństwie AI. Firmy przez lata debatowały, czy atakujący mogą manipulować samymi modelami lub je kompromitować. Google opisuje teraz pilniejszy problem: atakujący kradną konta, klucze API, pliki konfiguracyjne i zasoby chmurowe otaczające te modele.
Wynikające z tego ataki Google LLM-jacking przeciwstawiają szybko rosnący dostęp do AI mechanizmom kontroli tożsamości zaprojektowanym dla zwykłych usług programistycznych. LLM-jacking oznacza wykorzystywanie przejętych poświadczeń do korzystania z płatnego dostępu do modeli lub mocy obliczeniowej należących do kogoś innego. Technika ta po raz pierwszy publicznie pojawiła się w 2024 roku, lecz dowody Google sugerują, że weszła ona do szerszej gospodarki przestępczej.
Ataki Google LLM-Jacking wykraczają poza kradzione klucze API
Kluczowe ustalenie Google jest takie, że dostęp do AI stał się na tyle wartościowy, by go kraść, sprzedawać, łączyć we wspólne pule i odsprzedawać.
Ocena zagrożeń z września pochodzi od Google Threat Intelligence Group, czyli GTIG. Jej dowody opierają się na działaniach Mandiant związanych z reagowaniem na incydenty, śledzeniu grup zagrożeń, podziemnych forach oraz aktywności obserwowanej w usługach Google.
GTIG odnotowała, że w 2026 roku więcej kupujących poszukiwało kont związanych z AI. Badacze zauważyli również więcej sprzedawców, którzy je reklamowali. Popyt koncentrował się podobno na poświadczeniach do Claude i Gemini, a zainteresowanie budziły także konta dla autonomicznych środowisk programistycznych.
Google nie opublikowało łącznej liczby skradzionych kont. Podało jednak, że średnie podziemne ceny za konto wzrosły w 2026 roku ponad dwukrotnie. Ten szczegół ma znaczenie, ponieważ wskazuje na reakcję rynku, a nie jedynie rozproszone kradzieże poświadczeń.
Atakujący chcą dostępu do zaawansowanej AI z kilku powodów. Płatne konta oferują wyższe limity użycia, silniejsze modele i mniej przerw niż jednorazowe bezpłatne konta. Poświadczenia API mogą również obsługiwać zautomatyzowane obciążenia, które trudno byłoby utrzymać za pośrednictwem konsumenckiego interfejsu czatu.
Poświadczenia chmurowe mają jeszcze większą wartość. Przejęta tożsamość może ujawnić hostowane modele, uprawnienia do wdrażania, pamięć masową i kosztowne zasoby obliczeniowe. Atakujący mogą następnie uruchamiać obciążenia inferencyjne, podczas gdy ofiara ponosi koszty użycia i konsekwencje operacyjne.
Google wiąże to zachowanie z LLM-jackingiem, w którym przestępcy bez uprawnienia przejmują płatne usługi modelowe lub infrastrukturę chmurową. Bezpośrednim celem może być darmowy dostęp, ale ta sama infrastruktura może wspierać phishing, badania podatności, rozwój złośliwego oprogramowania lub odsprzedaż.
To zjawisko jest szersze niż znalezienie wyciekłego klucza API w publicznym repozytorium. Google zaobserwowało ekosystem obejmujący skradzione konta, automatyczną rejestrację, łączenie kont w pule, agregację API, usługi proxy i narzędzia antydetekcyjne.
Łączenie kont w pule zestawia kilka tożsamości lub kluczy API za jedną usługą. Taka organizacja może rozłożyć użycie, zmniejszyć skutki indywidualnych blokad i utrudnić przypisanie aktywności. Agregator może też udostępniać kilku dostawców przez jeden zgodny interfejs.
Google wcześniej udokumentowało podmioty korzystające z usług konsolidujących konta z Gemini, Claude i OpenAI. Jego raport o zagrożeniach z maja opisywał narzędzia do automatycznej rejestracji, weryfikacji, routingu, monitorowania limitów i maskowania odcisku przeglądarki.
Niektóre z tych narzędzi mają legalne zastosowania. Deweloperzy często kierują żądania do różnych modeli, aby poprawić dostępność lub kontrolować wewnętrzne obciążenia. Problem bezpieczeństwa pojawia się wtedy, gdy operatorzy zasilają te systemy skradzionymi lub utworzonymi w wyniku oszustwa kontami.
To rozróżnienie pozwala uniknąć częstego błędu analitycznego. Oprogramowanie proxy samo w sobie nie jest dowodem działalności przestępczej. Jednak połączenie skradzionych poświadczeń, wymijającej rejestracji, ukrytego ruchu i nieuprawnionej odsprzedaży tworzy rozpoznawalny łańcuch nadużyć.
Google wykryło również atakujących celujących w lokalne magazyny konfiguracji używane przez asystentów programistycznych AI. W maju 2026 roku operatorzy związani z rodziną złośliwego oprogramowania ACRSTEALER wydali reguły pobierania plików dla secrets.json Cline i config.yaml Continue AI.
Pliki te mogą zawierać klucze API w postaci zwykłego tekstu lub niestandardowe punkty końcowe routingu modeli. Skradziona sesja przeglądarki może ujawnić jedno konto użytkownika, podczas gdy konfiguracja deweloperska może otworzyć drogę do organizacyjnych limitów i infrastruktury.
Praktyczna granica konta AI stała się więc trudna do zdefiniowania. Może obejmować tożsamość, token sesji, sekret API, konfigurację wiersza poleceń, rolę chmurową oraz uprawnienie do wywoływania kilku zewnętrznych modeli.
Dla zespołów bezpieczeństwa ta rozszerzona granica tworzy główne napięcie artykułu. Organizacje chcą, aby dostęp do modeli był osadzony w codziennej pracy, ale każda wygodna integracja tworzy kolejne miejsce, z którego mogą wyciec wartościowe poświadczenia.
Dlaczego kradzież kont AI wywiera teraz presję na każdego klienta chmury
Presja spada na organizacje najszybciej wdrażające AI, ponieważ dostęp do ich modeli rozprzestrzenia się szybciej niż odpowiedzialność za bezpieczeństwo.
Zwykłe skradzione konto do oprogramowania zazwyczaj daje atakującemu dostęp do danych lub funkcji aplikacji. Skradzione konto AI może dodatkowo zapewnić mierzone zużycie modeli, moc obliczeniową w chmurze, autonomiczne narzędzia i połączenia z wewnętrzną wiedzą.
Ta kombinacja zmienia skalę potencjalnych szkód. Przejęte poświadczenie może generować rachunek, ujawniać informacje zastrzeżone i dostarczać infrastruktury do ataków na inne cele. Ofiara może początkowo dostrzec jedynie nietypowe użycie, a nie znany sygnał włamania.
Deweloperzy są szczególnie narażeni. Asystenci programistyczni AI często działają obok repozytoriów kodu źródłowego, terminali, menedżerów pakietów i narzędzi wdrożeniowych. Ich pliki konfiguracyjne mogą ujawniać poświadczenia o znacznie większym zasięgu niż pojedyncza historia czatu.
Rosnące wykorzystanie agentowej AI dodatkowo podnosi stawkę. System agentowy pozwala modelowi planować kroki i obsługiwać narzędzia przy ograniczonym udziale człowieka. Jego poświadczenia mogą autoryzować dostęp do plików, wykonywanie kodu, przeglądanie internetu lub komunikację z usługami zewnętrznymi.
Google poinformowało, że aktorzy zagrożeń również wdrażają frameworki wieloagentowe do ofensywnych przepływów pracy. Systemy te mogą koordynować skanowanie, rozwiązywać błędy i zarządzać zbieraniem poświadczeń przy mniejszej liczbie przerw na decyzje podejmowane przez ludzi.
Jeden przypadek z drugiego kwartału 2026 roku skondensował tę zmianę w uderzającej osi czasu. GTIG zaobserwowało, jak atakujący przejęli zasób chmurowy, a następnie w mniej niż sześć godzin zaplanowali, zbudowali i przeprowadzili masową kampanię pozyskiwania poświadczeń wspieraną przez agenty.
To ustalenie nie oznacza, że każda grupa przestępcza prowadzi obecnie autonomiczne systemy ataków. Pokazuje ono, że automatyzacja może skrócić czas od początkowego dostępu do skalowalnego wykorzystania.
Obrońcy tradycyjnie polegają na czasie między tymi etapami. Alert może uruchomić dochodzenie, zanim atakujący rozszerzy dostęp, ustanowi trwały dostęp lub dotrze do wrażliwych systemów. Sześciogodzinny cykl budowy i wykonania pozostawia znacznie mniej miejsca na ręczną analizę.
Wartość skradzionych poświadczeń AI wykracza również poza ich bezpośrednie limity. Plik konfiguracyjny może ujawnić prywatny punkt końcowy, a powiązana tożsamość chmurowa może ujawnić logi, magazyny danych lub połączone aplikacje.
Organizacje powinny zatem traktować kradzież kont Google AI jako problem bezpieczeństwa tożsamości, a nie wyłącznie kwestię zarządzania AI. Punkt kontroli często stanowią poświadczenia i otaczające je uprawnienia, a nie warstwa bezpieczeństwa modelu.
Długowieczne sekrety tworzą najbardziej oczywiste ryzyko. Mogą pozostać użyteczne po zamknięciu laptopa przez pracownika lub zmianie hasła do sieci. Atakujący mogą je po cichu testować, kierować ruch przez proxy i zwiększać użycie po potwierdzeniu dostępnych usług.
Współdzielone konta deweloperskie tworzą kolejną słabość. Gdy kilka osób lub zautomatyzowanych systemów korzysta z jednej tożsamości, nietypową aktywność trudniej przypisać. Cofnięcie dostępu może także zakłócić legalną pracę, co może opóźnić powstrzymanie incydentu.
Klienci chmury stają wobec drugiego problemu: zużycie na poziomie infrastruktury wygląda normalnie. Prawidłowy klucz wysyłający prawidłowe żądania do modelu może nie uruchomić mechanizmów zaprojektowanych do wykrywania złośliwego oprogramowania lub niedozwolonego ruchu sieciowego.
Zespoły potrzebują zamiast tego sygnałów behawioralnych. Przydatne wskaźniki obejmują nowe lokalizacje geograficzne, nieoczekiwane aktywacje modeli, nagłe zmiany limitów, nieznane bramy API, nietypowy czas żądań oraz użycie niezgodne z profilem właściciela poświadczenia.
Presja spoczywa również na dostawcach modeli. Muszą oni odróżniać legalną agregację od przestępczego łączenia kont bez blokowania zwykłych architektur przedsiębiorstw. Muszą też łączyć sygnały dotyczące kont, sieci, płatności, urządzeń i użycia w szybko zmieniających się produktach.
Wymuszona odpowiedź to przeprojektowanie tożsamości wokół dostępu do AI. Organizacje potrzebują krótkotrwałych poświadczeń, węższych uprawnień, oddzielnych tożsamości usługowych, limitów użycia, szybkiego unieważniania oraz monitorowania powiązanego z oczekiwanym zachowaniem.
Środki te brzmią znajomo, ponieważ leżące u ich podstaw błędy są znajome. Zmienił się zasób podlegający monetyzacji oraz szybkość, z jaką skradziony dostęp może wspierać kolejne operacje.
Rzeczywistym kompromisem jest wygoda AI kontra kontrola poświadczeń
Wdrażanie AI zmniejsza tarcie dla użytkowników, ale ta sama wygoda może ukrywać poświadczenia w narzędziach, wtyczkach, agentach i plikach lokalnych.
Większość organizacji nie wdraża jednego centralnie zarządzanego systemu AI. Pracownicy korzystają z aplikacji przeglądarkowych, asystentów programistycznych, klientów wiersza poleceń, bram modeli, platform chmurowych, rozszerzeń i niestandardowych automatyzacji.
Każda ścieżka dostępu inaczej obsługuje tożsamość. Jedna może używać pliku cookie sesji, inna klucza API, a kolejna roli chmurowej dziedziczonej ze środowiska użytkownika. Zespoły bezpieczeństwa mogą mieć trudności z zinwentaryzowaniem wszystkich trzech.
Narzędzia programistyczne AI szczególnie wyraźnie pokazują ten kompromis. Deweloperzy oczekują szybkiej konfiguracji i nieprzerwanego dostępu do modeli. Zapisanie klucza w pliku konfiguracyjnym jest wygodne, lecz złośliwe oprogramowanie, które już przeszukuje systemy lokalne, może dodać ten plik do swojej listy zbieranych danych.
Ustalenia Google pokazują, że infostealery odpowiednio się dostosowują. Operatorzy LUMMAC.V2, STEALC.V2, VIDAR i ACRSTEALER wykazywali zainteresowanie konfiguracjami deweloperskimi AI, wykraczając poza kradzież profili przeglądarek.
Infostealery to złośliwe oprogramowanie zaprojektowane do zbierania wartościowych informacji z zainfekowanego urządzenia. Zwykle celują w hasła, pliki cookie, portfele i dane aplikacji. Dodanie plików konfiguracyjnych AI jest logicznym rozszerzeniem ugruntowanego modelu biznesowego.
Mechanizm ten pomaga wyjaśnić, dlaczego problem może narastać bez przełomowego ataku na modele czołowe. Atakujący nie muszą przełamywać podstawowej architektury bezpieczeństwa modelu, jeśli mogą podszyć się pod płacącego użytkownika.
Google wielokrotnie podkreślało to rozróżnienie. Jego ustalenia z lutego wskazywały, że atakujący potrzebowali kluczy API i zasobów, aby nadużywać usług LLM na dużą skalę. Wymóg ten tworzy bezpośrednią zachętę do przejmowania organizacji dysponujących znaczną pojemnością AI.
Konflikt staje się ostrzejszy, gdy agenci otrzymują szerokie uprawnienia do korzystania z narzędzi. Agent może potrzebować dostępu do repozytoriów, dokumentacji, systemów śledzenia zgłoszeń i systemów wdrożeniowych, aby zapewniać użyteczną pomoc. Każdy dodatkowy konektor zwiększa zarówno użyteczność, jak i potencjalną ekspozycję.
Skradziona poświadczenie AI nie zapewnia automatycznie wszystkich tych połączonych uprawnień. Rezultat zależy od tego, jak organizacja zaprojektowała uwierzytelnianie i autoryzację. Źle rozdzielone tożsamości mogą jednak zamienić jeden skradziony sekret w kilka ścieżek dostępu.
Sekrety nie powinny znajdować się w promptach, plikach źródłowych, notebookach ani katalogach konfiguracyjnych dostępnych do szerokiego odczytu. Organizacje powinny przechowywać je w zarządzanych systemach sekretów i udostępniać wyłącznie temu obciążeniu roboczemu, które ich potrzebuje.
To zalecenie łatwo sformułować, lecz trudniej wyegzekwować. Deweloperzy mogą tworzyć tymczasowe eksperymenty poza centralnymi platformami. Zespoły mogą współdzielić poświadczenia, aby dotrzymać terminu, podczas gdy porzucone prototypy mogą zachowywać aktywne klucze przez wiele miesięcy.
Bramy AI mogą ograniczać rozproszenie, centralizując uwierzytelnianie i polityki. Mogą też stać się celami o wysokiej wartości. Jeśli jedna brama ma dostęp do wielu dostawców i szerokich limitów, jej przejęcie daje atakującemu skoncentrowaną pulę zasobów.
Odpowiedzią nie jest unikanie bram. Należy ograniczać zakres wywołań dostępnych dla każdej tożsamości bramy, ustanowić przypisanie działań do poszczególnych użytkowników i uniemożliwić jednemu przejętemu komponentowi aktywowanie niepowiązanych usług.
Organizacje muszą także oddzielić dostęp do modeli od dostępu administracyjnego. Usługa wysyłająca żądania inferencji nie powinna automatycznie otrzymywać uprawnień do zmiany rozliczeń, włączania nowych modeli, tworzenia tożsamości ani pobierania niepowiązanych sekretów chmurowych.
Silne uwierzytelnianie ma znaczenie dla kont interaktywnych, ale uwierzytelnianie wieloskładnikowe nie rozwiązuje wszystkich scenariuszy. Klucze API i tożsamości usługowe często działają bez interaktywnego potwierdzenia, a skradzione dane sesji mogą czasem ominąć konieczność ponownego logowania.
Krótkie okresy ważności poświadczeń ograniczają tę ekspozycję. Podobnie działają systemy tożsamości obciążenia roboczego, które zastępują statyczne klucze tymczasowymi tokenami opartymi na zweryfikowanym kontekście uruchomionej aplikacji.
Kontrole użycia zapewniają kolejną warstwę ochrony. Budżety dla poszczególnych tożsamości, limity szybkości, listy dozwolonych modeli i alerty dotyczące nowych regionów mogą ograniczyć czas i możliwości dostępne dla atakującego.
Logi muszą także zachowywać wystarczający kontekst do prowadzenia dochodzenia. Żądanie do modelu powinno być możliwe do powiązania z użytkownikiem, usługą, środowiskiem i zatwierdzonym celem bez niepotrzebnego ujawniania wrażliwej treści promptów.
Dla pracowników umysłowych wniosek jest bardziej osobisty. Rozszerzenie przeglądarki, pobrane narzędzie do programowania lub nieoficjalny klient mogą znajdować się między użytkownikiem a kilkoma płatnymi usługami AI. Zainstalowanie jednego z nich oznacza podjęcie decyzji o zaufaniu dotyczącym sposobu przechowywania i przesyłania poświadczeń.
Pracownicy nie powinni wklejać organizacyjnych kluczy API do niezatwierdzonych narzędzi. Powinni też zgłaszać nieoczekiwane alerty logowania, powiadomienia o użyciu modeli i nagłe wyczerpanie limitów jako możliwe incydenty bezpieczeństwa, a nie zwykłe błędy rozliczeniowe.
Nie da się wyeliminować kompromisu między wygodą a kontrolą. Narzędzia AI stają się użyteczne, gdy docierają do większej ilości informacji i wykonują więcej działań. Uzasadnione podejście polega na tym, by każde połączenie było widoczne, ograniczone, przypisywalne i łatwe do cofnięcia.
Ostrzeżenie Google nie mierzy pełnej skali LLM-jackingu
Dowody wskazują na realne i dojrzewające zagrożenie, ale nie określają, ile organizacji poniosło straty w wyniku LLM-jackingu.
Raport Google używa sformułowań kierunkowych, takich jak „zwiększone ukierunkowanie” i „rosnąca liczba włamań”. Przedstawia przykłady, zaobserwowane taktyki, trendy na rynku oraz przypadki reagowania na incydenty, a nie pełne oszacowanie skali zjawiska.
To ograniczenie ma znaczenie. Wywiad o zagrożeniach odzwierciedla środowiska, klientów, platformy i podziemne przestrzenie widoczne dla badaczy, którzy go gromadzą. Aktywność poza tym polem widzenia może pozostać niepoliczona, podczas gdy intensywnie monitorowani aktorzy mogą wydawać się bardziej znaczący.
Zgłoszone podwojenie średnich cen kont na podziemnym rynku jest informatywne, ale niepełne. Google nie opublikował wielkości próby, rozkładu cen ani metodologii potrzebnej do rygorystycznego porównania tego rynku w czasie.
Wyższe ceny mogą wskazywać na rosnący popyt, ograniczoną podaż, lepszą jakość kont lub zmiany na monitorowanych platformach handlowych. Same w sobie nie dowodzą, że liczba skutecznych kradzieży kont podwoiła się.
Określenie „gwałtownego wzrostu” należy zatem rozumieć jako dowód zwiększonej zaobserwowanej aktywności, a nie spis globalnych incydentów. Najmocniejsze twierdzenia Google dotyczą tego, co jego zespoły bezpośrednio zaobserwowały: większej liczby kupujących i sprzedających, ukierunkowanej kradzieży konfiguracji oraz przejęć środowisk chmurowych wspierających nieautoryzowane obciążenia robocze.
Istnieje też problem terminologiczny. LLM-jacking może opisywać kilka powiązanych zachowań — od użycia pojedynczego skradzionego klucza API po przejęcie firmowego środowiska chmurowego. Łączenie ich pod jedną etykietą może zacierać istotne różnice w skutkach.
Pierwotne publiczne badanie dotyczące skradzionych poświadczeń chmurowych zdefiniowało LLM-jacking jako nieautoryzowane korzystanie z hostowanych usług modelowych. Późniejsze doniesienia rozszerzyły ten obraz o sieci proxy, odsprzedaż i rozwój ofensywnych agentów.
Ta historia oferuje użyteczne porównanie. Cryptojacking w chmurze opierał się na podobnej logice ekonomicznej: atakujący kradli moc obliczeniową, ponieważ rachunek płaciła ofiara. Obciążenia AI tworzą kolejne możliwe do monetyzacji zastosowanie przejętej infrastruktury.
LLM-jacking może jednak generować ryzyko wykraczające poza koszty zużycia. Dostęp do modeli może pomóc atakującemu analizować skradziony kod, tworzyć zlokalizowane przynęty, automatyzować badania lub budować usługi dla innych przestępców.
Własne ustalenia Google wymagają kolejnego zastrzeżenia. Firma twierdzi, że atakujący stają się bardziej kompetentnymi użytkownikami AI, ale informowała również, że wiele prób nadużycia modeli uruchamiało systemy bezpieczeństwa lub nie prowadziło do istotnego wzrostu możliwości.
We wcześniejszych dochodzeniach grupy wspierane przez państwa korzystały z Gemini do badań, programowania, tłumaczeń i rozwiązywania problemów. Google wyłączył powiązane zasoby i zaktualizował swoje mechanizmy ochrony. Nie stwierdził, że ci aktorzy pokonali podstawowe zabezpieczenia modelu.
Ten kontrast jest istotny. Kradzież konta zapewnia dostęp, ale dostęp nie gwarantuje nieograniczonych wyników ani powodzenia operacji. Dostawcy nadal mogą wykrywać nadużycia, egzekwować polityki, wyłączać konta i aktualizować zabezpieczenia modeli.
Przestępcy mogą także preferować skradzione konta właśnie dlatego, że egzekwowanie zasad bezpieczeństwa pozostaje aktywne. Pule jednorazowych tożsamości mogą pomagać im absorbować blokady, rozdzielać żądania i ukrywać szerszy wzorzec działania.
Powstająca rywalizacja nie polega po prostu na starciu atakujących z zabezpieczeniami modeli. Chodzi o to, czy atakujący będą rotować tożsamości szybciej, niż dostawcy i klienci zdołają powiązać podejrzane zachowania między kontami.
Niezależne badania potwierdzają mechanizm leżący u podstaw tego zjawiska. Sysdig udokumentował LLM-jacking w 2024 roku, a później informował o bardziej zróżnicowanych celach i taktykach. Badania dostawców często opierają się jednak na wybranych incydentach, a nie reprezentatywnej globalnej próbie.
Czytelnicy powinni oprzeć się dwóm przeciwstawnym wnioskom. Błędem byłoby lekceważenie zagrożenia, ponieważ Google nie dysponuje globalną liczbą przypadków. Błędem byłoby także twierdzenie, że każde konto AI lub każdy klient chmurowy stoi przed natychmiastowym ryzykiem przejęcia.
Uzasadniony wniosek jest węższy. Skradziony dostęp do AI ma obecnie obserwowalną wartość rynkową, ugruntowane ścieżki techniczne i udokumentowane zastosowanie przestępcze. To wystarcza, by uzasadnić konkretne zabezpieczenia bez zawyżania dostępnych dowodów.
Na co zwracać uwagę po ostrzeżeniu Google dotyczącym kradzieży kont AI
Kolejną fazę określą telemetria dostawców, ukierunkowanie działań infostealerów oraz zdolność przedsiębiorstw do izolowania tożsamości AI, zanim atakujący zwiększą skalę dostępu.
Pierwszym sygnałem będą bardziej szczegółowe raporty dostawców modeli i chmury. Google wskazał kierunek zmian, ale przyszłe raporty powinny zawierać liczbę incydentów, rodzaje dotkniętych poświadczeń, czas trwania nadużyć oraz jaśniejszą metodologię analizy rynku.
Takie ujawnienia wzmocniłyby tezę, że ataki Google LLM-jacking stanowią odrębną kategorię wzrostu. Brak mierzalnej ekspansji sugerowałby, że obecne raportowanie łączy kilka utrwalonych form nadużywania poświadczeń pod etykietą związaną z AI.
Drugim sygnałem jest zachowanie operatorów infostealerów. Google zaobserwował ukierunkowane reguły dotyczące konfiguracji asystentów programowania AI, co pokazuje, że przestępcy wiedzą, gdzie deweloperzy przechowują poświadczenia do modeli.
Obrońcy powinni obserwować, czy kolejne rodziny złośliwego oprogramowania systematycznie dodają klientów AI, frameworki agentowe i bramy modeli do swoich list zbieranych danych. Powszechne wdrożenie wskazywałoby, że sekrety AI stały się standardowym celem obok plików cookie przeglądarki i portfeli kryptowalutowych.
Zespoły bezpieczeństwa mogą obserwować tę zmianę wewnętrznie. Wykrycia na punktach końcowych obejmujące ścieżki konfiguracji AI zasługują na analizę nawet wtedy, gdy nie wydaje się, aby dotknięto kod źródłowy ani tradycyjny magazyn haseł.
Trzecim sygnałem jest architektura tożsamości przedsiębiorstwa. Organizacje albo nadal będą wydawać przenośne, długotrwałe sekrety, albo przejdą na tymczasowe poświadczenia obciążeń roboczych z wąskimi uprawnieniami i przypisaniem do użytkownika.
Ta transformacja zdecyduje, czy skradziony dostęp pozostanie łatwy do ponownego użycia i odsprzedaży. Scentralizowane inwentarze, szybka rotacja, domyślne limity użycia i alerty dotyczące aktywacji modeli mogą obniżyć wartość przejętych poświadczeń.
Dostawcy modeli również mają do odegrania rolę. Mogą identyfikować współdzielenie kont na podstawie sygnałów sieciowych, urządzeń, płatności i wzorców żądań. Mogą wymagać silniejszej weryfikacji, gdy aktywność nagle obejmuje kolejne regiony, modele lub profile użycia.
Te zabezpieczenia muszą unikać karania legalnego routingu w przedsiębiorstwach. Firma może celowo rozdzielać obciążenia robocze między regiony lub dostawców. Systemy wykrywania potrzebują kontekstu wynikającego z polityk klienta, a nie tylko ogólnych progów anomalii.
Organizacje powinny zacząć od konkretnego inwentarza. Należy zidentyfikować, kto ma dostęp do płatnych modeli, które aplikacje przechowują poświadczenia, które role chmurowe mogą włączać usługi oraz gdzie rejestrowane są żądania do modeli.
Następnie powinny przetestować cofanie dostępu. Poświadczenie, którego nie można szybko zlokalizować i wyłączyć, już stanowi obciążenie dla reagowania na incydenty. Zespoły powinny potwierdzić, że usunięcie jednej tożsamości nie wymaga wyłączania niepowiązanych obciążeń AI.
Deweloperzy mogą ograniczyć ryzyko, zastępując lokalne statyczne klucze, oddzielając konta eksperymentalne od systemów produkcyjnych i odmawiając współdzielenia poświadczeń przez czat lub repozytoria kodu źródłowego. Zespoły bezpieczeństwa powinny sprawić, by zatwierdzona ścieżka była łatwiejsza niż obejście zasad.
Kadra zarządzająca powinna zadać proste pytanie: gdyby dziś w nocy skradziono poświadczenie AI, czy organizacja najpierw zauważyłaby atakującego, rachunek czy wyciek danych?
Ostrzeżenie Google nadaje temu pytaniu pilności, ponieważ atakujący nie postrzegają już dostępu do AI jako nowinki. Widzą w nim zasób, który można pozyskać, łączyć w pule, zużywać i sprzedawać.
Najbliższe miesiące powinny pokazać, czy dostawcy opublikują mocniejsze pomiary oraz czy infostealery poszerzą listy swoich celów. Czytelnicy powinni wykorzystać ten okres do audytu dostępu do AI, zanim podziemny rynek dojrzeje jeszcze bardziej.
