Wprowadzenie do problemu / definicja
Organizacja badawcza METR, zajmująca się oceną zaawansowanych modeli sztucznej inteligencji, opisała dwa incydenty bezpieczeństwa z 2026 roku, które pokazują rosnące zagrożenia dla środowisk AI. Najpoważniejsze zdarzenie dotyczyło kradzieży klucza API z publicznie dostępnej instancji badawczej oraz jego późniejszego wykorzystania do nieautoryzowanego zużycia kredytów obliczeniowych o wartości około 600 tys. dolarów.
Sprawa zwraca uwagę na kilka kluczowych obszarów ryzyka: niewłaściwe przechowywanie sekretów, podatności logiczne typu fail-open, ekspozycję eksperymentalnych usług do Internetu oraz niedostateczny monitoring kosztów w środowiskach intensywnie korzystających z modeli AI.
W skrócie
- METR ujawnił dwa odrębne incydenty bezpieczeństwa z marca i maja 2026 roku.
- W pierwszym przypadku napastnik przejął klucz API z publicznie dostępnej instancji badawczej.
- Skradziony klucz był używany przez około trzy tygodnie do intensywnego wykorzystania modeli publicznych.
- Szacunkowa wartość nieautoryzowanego zużycia kredytów AI wyniosła około 600 tys. dolarów.
- Drugi incydent obejmował szeroko zakrojone rozpoznanie infrastruktury, credential stuffing, próby uzyskania tokenów OAuth oraz phishing.
- Według analizy METR nie ma dowodów na dostęp do najbardziej wrażliwych danych ani do niepublicznych informacji modelowych.
Kontekst / historia
Incydenty wpisują się w szerszy trend zagrożeń wymierzonych w organizacje rozwijające i testujące zaawansowane systemy AI. W takich środowiskach klasyczne problemy bezpieczeństwa chmury i aplikacji webowych łączą się z nowymi ryzykami wynikającymi z użycia agentów, orkiestracji modeli i eksperymentalnych interfejsów sterowania.
W marcu 2026 roku źródłem problemu była osobista instancja EC2 używana przez badacza, który nie miał dostępu do najbardziej wrażliwych zasobów organizacji. Instancja miała być chroniona logowaniem Google, jednak wada aplikacji doprowadziła do obejścia mechanizmu uwierzytelniania. W maju 2026 roku METR zaobserwował z kolei bardziej systematyczną kampanię rozpoznawczą wymierzoną w publiczne usługi i procesy uwierzytelniania.
Cała sytuacja pokazuje, że nawet organizacje specjalizujące się w badaniu bezpieczeństwa i niezawodności zaawansowanych modeli AI pozostają podatne na dobrze znane klasy błędów operacyjnych i konfiguracyjnych.
Analiza techniczna
Najważniejszym elementem pierwszego incydentu było współwystępowanie kilku słabości. Na publicznie dostępnej instancji znajdował się klucz API przypisany do ogólnego konta METR wykorzystywanego do pracy z modelami publicznymi. Jednocześnie aplikacja orkiestrująca agentów zawierała błąd fail-open, przez co w określonych warunkach mechanizm bezpieczeństwa nie blokował dostępu, lecz go dopuszczał.
W praktyce oznaczało to, że panel został wystawiony do Internetu bez skutecznej kontroli dostępu przez kilka dni. Z opisu zdarzenia wynika, że napastnik mógł identyfikować nowe lub eksperymentalne wdrożenia powiązane z agentami LLM, a następnie nakłonić system do ujawnienia sekretu dostawcy modeli. Po pozyskaniu poświadczenia atakujący dodał własny klucz SSH, co sugeruje próbę utrzymania trwałego dostępu do środowiska.
Nieautoryzowane użycie skradzionego klucza trwało około trzech tygodni. Wykrycie nadużycia utrudniał fakt, że METR naturalnie generuje wysokie zużycie tokenów podczas ewaluacji modeli, a dodatkowo środowisko operacyjne było obciążone błędami i limitami po stronie dostawców. Brak skutecznych progów wydatków oraz alarmów kosztowych dla części kluczy sprawił, że anomalia nie została szybko wychwycona.
Drugi incydent miał charakter bardziej rozproszony i przypominał przygotowanie pod bardziej zaawansowany atak. METR odnotował credential stuffing wobec usług uwierzytelniania, próby uzyskania tokenów OAuth, skanowanie nowo wdrożonych usług oraz kampanie phishingowe skierowane do pracowników. Dodatkowo organizacja nieumyślnie wystawiła mechanizm zapytań SQL tylko do odczytu przez publiczny viewer transkryptów. Chociaż domyślnie zapytania miały dotyczyć danych publicznych, błąd w komponencie mógł potencjalnie otworzyć drogę do nieopublikowanych wyników ewaluacyjnych.
Szczególnie istotny jest fakt, że w bazie danych znalazły się także informacje bardziej wrażliwe, które nie powinny były się tam znaleźć. Według METR problem został wykryty przez niezależnego badacza bezpieczeństwa, a analiza śladów nie wskazała skutecznego wykorzystania tej ścieżki przez napastników.
Konsekwencje / ryzyko
Najbardziej wymiernym skutkiem pierwszego incydentu było zużycie kredytów API o wartości około 600 tys. dolarów. Nawet jeśli organizacja nie poniosła pełnego kosztu finansowego, ponieważ kredyty zostały przyznane przez dostawcę modeli, skala nadużycia pokazuje realne ryzyko budżetowe i operacyjne dla firm korzystających z usług AI w modelu pay-per-use.
W innym scenariuszu podobny incydent mógłby doprowadzić do natychmiastowych strat finansowych, wyczerpania limitów usług i zakłócenia legalnych procesów biznesowych. Przejęty klucz API może również posłużyć do maskowania aktywności, prowadzenia nieautoryzowanych eksperymentów lub testowania granic polityk bezpieczeństwa dostawcy.
Dodatkowym sygnałem ostrzegawczym jest dodanie klucza SSH przez atakującego. Taki ruch wskazuje, że celem nie było wyłącznie doraźne zużycie zasobów, lecz także utrzymanie dostępu i potencjalne rozszerzenie zakresu operacji. To podnosi ocenę dojrzałości przeciwnika i sugeruje bardziej świadome działanie niż zwykłe oportunistyczne nadużycie.
Drugi incydent unaocznia z kolei ryzyko wynikające ze słabej segmentacji danych i błędów konfiguracyjnych. Nawet bez potwierdzonego wycieku, samo umieszczenie bardziej wrażliwych informacji w mniej chronionej bazie narusza podstawowe zasady separacji stref zaufania. W środowiskach agentowych i badawczych takie uchybienia istotnie skracają drogę od rozpoznania do eksfiltracji danych.
Rekomendacje
Najważniejszym wnioskiem z incydentu jest konieczność traktowania kluczy API jak poświadczeń uprzywilejowanych. Powinny być przechowywane wyłącznie w dedykowanych systemach secret management, objęte regularną rotacją, ograniczane zakresem uprawnień i, tam gdzie to możliwe, zastępowane tokenami o krótkim czasie życia.
Organizacje rozwijające aplikacje oparte na agentach AI powinny również wdrożyć wyraźną segmentację infrastruktury. Publiczne dashboardy, eksperymentalne interfejsy agentów oraz narzędzia do przeglądania transkryptów nie powinny współdzielić tożsamości, sekretów ani baz danych z systemami zawierającymi bardziej wrażliwe informacje.
- Oddzielać środowiska eksperymentalne od produkcyjnych i badawczych o podwyższonej poufności.
- Testować aplikacje pod kątem błędów fail-open, prompt injection i nieautoryzowanego ujawniania sekretów.
- Wprowadzać limity kosztowe oraz alerty wykrywające nietypowe zużycie tokenów i kredytów API.
- Monitorować nowe hosty, wpisy DNS, certyfikaty TLS i świeżo publikowane usługi.
- Egzekwować zakaz przechowywania firmowych poświadczeń na niezarządzanych lub prywatnych instancjach.
- Rozwijać procedury red teamingu i odpowiedzialnego zgłaszania podatności.
W przypadku systemów agentowych szczególnie ważne jest też ograniczenie możliwości samodzielnego odczytu i zwracania sekretów przez agenta końcowemu użytkownikowi. Każda ścieżka ujawnienia poświadczeń powinna być objęta dodatkową warstwą autoryzacji, walidacji i audytu.
Podsumowanie
Incydent bezpieczeństwa w METR pokazuje, że infrastruktura AI wymaga takiej samej dyscypliny ochronnej jak krytyczne systemy produkcyjne. Kradzież klucza API z publicznie wystawionej instancji, wielotygodniowe nieautoryzowane zużycie zasobów oraz równoległa kampania rozpoznawcza potwierdzają, że napastnicy coraz lepiej rozumieją specyfikę środowisk opartych na agentach i dużych modelach językowych.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona sekretów, segmentacja stref zaufania, testowanie logiki dostępu i monitoring kosztów nie są dodatkiem do projektów AI, lecz ich absolutnym fundamentem. W przeciwnym razie nawet pojedyncza podatność lub błąd konfiguracyjny może szybko przełożyć się na kosztowny incydent o szerokich konsekwencjach operacyjnych.