Panel agenta METR napisany w stylu vibe coding wyłączył własne logowanie, a atakujący zużył kredyt modelowy o wartości 600 000 dolarów

W marcu 2026 roku ktoś pobrał klucz API do konta public-models METR z osobistej instancji Amazon EC2 badacza i używał go przez trzy tygodnie. METR — Model Evaluation and Threat Research, organizacja non-profit, która mierzy, jak daleko agenci AI dochodzą w zadaniach o długim horyzoncie — oszacowała wartość handlową zużytego kredytu na około $600,000. Klucz nie został wyłudzony od człowieka: atakujący nakłonił agenta działającego na vibe-coded dashboardzie badacza do przekazania klucza API do dostawcy modeli, a następnie dodał klucz SSH, aby móc powrócić. METR ujawniła incydent 31 sierpnia 2026, a wpis ma wysoką ocenę dotkliwości nadaną przez archiwum oraz ocenę pewności A. Ujawnienie to jeden wpis w archiwum incydentów AI, które zawiera pełny zestaw wpisów, jego źródła i sąsiednie pozycje w tej serii.

Co faktycznie mówi dokument

Archiwum klasyfikuje to jako zaistniały incydent, a nie ujawnienie teoretycznej słabości: dotkliwość wysoka, pewność A, bezsporny, z odnotowaną rzeczywistą szkodą i potwierdzonym udziałem AI. Tag typu to CRED, region to Stany Zjednoczone, a data jest zapisana tylko z dokładnością do miesiąca — archiwum wie, że kradzież miała miejsce w marcu 2026 r., i nie podaje dnia, podobnie jak METR.

Szkoda wymaga jednego zastrzeżenia i METR je dostarcza. Kredyty zostały przyznane METR bezpłatnie przez dewelopera modelu, więc 600 000 USD to wartość tego, co zużyto, a nie pieniądze, które opuściły konto. Zajawka The Register ujęła tę samą kwestię dosadniej: dostawca modelu przekazał METR kredyty, a rzeczywisty płacący klient nie miałby tyle szczęścia. Infosecurity Magazine podał tę kwotę w ten sam sposób – jako wartość komercyjną, a nie bezpośrednią stratę finansową.

Wpis METR-a opisuje dwa incydenty, a nie jeden. Kampania z maja 2026 r. została opisana osobno niżej; kradzież klucza i trzy tygodnie wydatków to wydarzenie z marca i to one są tematem tego artykułu.

Wada leżała w logowaniu, a nie w modelu

Badacz METR bez dostępu do danych wrażliwych uruchomił agentów na osobistej instancji EC2, którą celowo udostępniono publicznie, z uwierzytelnianiem Google. Instancja zawierała klucz API do ogólnodostępnego konta METR — tego używanego do modeli publicznych, które METR zalicza do swojej drugiej najmniej wrażliwej kategorii danych. Aplikacja orkiestrująca wokół tych agentów była vibe-coded i zawierała coś, co METR nazywa podatnością fail-open, która po cichu wyłączyła uwierzytelnianie.

Fail-open wart jest przetłumaczenia, bo to cały incydent w dwóch słowach. Sprawdzenie logowania może być błędne na dwa sposoby: może odmówić dostępu legalnemu użytkownikowi albo wpuścić każdego, gdy samo sprawdzenie zawiedzie. Fail-open oznacza to drugie — gdy krok uwierzytelniania zakończył się błędem lub został pominięty, aplikacja traktowała żądanie jako dozwolone, a nie odrzucone. Nic nie wywołało alertu. Według relacji METR skutkiem był system wystawiony na publiczny internet przez kilka dni, z otwartymi drzwiami frontowymi i bez żadnej informacji, że cokolwiek się zmieniło.

METR nie wymienia narzędzia orkiestracji ani frameworku, za pomocą którego zbudowano dashboard, nie publikuje kodu i nie mówi, w jaki sposób zawiodła integracja uwierzytelniania. To, co wpis jednak ustala, to błąd architektoniczny leżący u podłoża tego błędu: poświadczenie do konta modelu organizacyjnego znajdowało się na infrastrukturze, której METR nie kontrolował, w aplikacji, którą jeden z badaczy wdrożył samodzielnie.

Jak klucz opuścił budynek

Rekonstrukcja sposobu działania atakującego dokonana przez METR jest jednoznacznie podejrzeniem, a nie ustaleniem, i stanowi najciekawszą nieudowodnioną tezę w ujawnieniu. W poście czytamy, że METR podejrzewa, iż atakujący znalazł tę instancję, przeglądając niedawno zarejestrowane strony internetowe — jako przykład podano listy przejrzystości certyfikatów — w poszukiwaniu stron tworzonych w ramach „vibe codingu”, zawierających słowa kluczowe wskazujące na projekty LLM lub agentowe, aby pozyskać pozostawione bez zabezpieczenia klucze API dostawców modeli.

Logi przezroczystości certyfikatów są publiczne z założenia: każdy certyfikat wystawiony dla publicznie zaufanej witryny jest rejestrowany, więc nowa nazwa hosta pojawia się w przeszukiwalnym kanale w ciągu kilku minut od uruchomienia. Filtrowanie tego kanału pod kątem nazw zawierających terminologię dotyczącą agentów lub modeli jest tanie, nie wymaga dostępu do celu i daje listę świeżych wdrożeń, których być może nikt nie sprawdził. Odczytywane jako technika polowania, zamienia zwykłe publikowanie demo w sygnał.

Po dostaniu się do środka atakujący nie musiał wykradać sekretu z systemu plików. bezpośrednio skłonili agenta do ujawnienia klucza API jego dostawcy modelu, co jest zdaniem, które zasługuje na chwilę namysłu: agent miał to poświadczenie w swoim kontekście i dał się namówić do jego wydrukowania. Następnie atakujący dodał klucz SSH zapewniający trwały dostęp, tak aby zamknięcie dziury w uwierzytelnianiu nie wyeliminowało go z systemu, i rozgościł się na trzy tygodnie wnioskowania na publicznie dostępnych modelach.

Nazwa dewelopera modelu nie została podana — ani przez METR, ani przez The Register, Dark Reading, Infosecurity Magazine czy The Hacker News w ich materiałach na temat ujawnienia. Nie wydano żadnego CVE, ponieważ nie chodzi o podatność w produkcie. Nie odnotowano aresztowania, postawienia zarzutów ani przypisania działań konkretnej nazwanej grupie.

Dlaczego trzy tygodnie nieprawidłowego użytkowania wyglądały normalnie

METR odpowiada bezpośrednio na oczywiste pytanie, a odpowiedź jest tą częścią, którą inne organizacje powinny przeczytać dwa razy. Ta organizacja non-profit prowadzi ewaluacje na dużą skalę, co oznacza, że jest gruntownie przyzwyczajona do bardzo dużych liczb tokenów oraz do strumienia dziwnych błędów limitów szybkości i API, z których wiele jest fałszywych. Skok ruchu modelu sam w sobie nie był sygnałem.

Trzy konkretne luki zamieniły tę znajomość w trzy tygodnie ciszy. Wewnętrzny panel użycia METR nie pokazywał danych o żądaniach ograniczonych limitem szybkości u wszystkich użytkowników, nawet gdy takie żądania występowały. Ponieważ tokeny były darmowe, nie było rachunku, a więc i naturalnego pułapu wydatków, który by zadziałał. A w tamtym czasie, jak twierdzi METR, nie było żadnego sposobu, by nałożyć limit wydatków na klucz tego rodzaju. Organizacja płacąca cenę katalogową z twardym limitem napotkałaby barierę w ciągu kilku godzin; organizacja z darowanym kredytem i bez limitu nie miała w co uderzyć.

Czego nie zabrano?

Taksonomia danych METR obejmuje materiały publikowane, aż po ogólny dostęp do modeli, dostęp do modeli wrażliwych i wysoce wrażliwe informacje biznesowe. Zaangażowany badacz nie miał dostępu do dwóch najwyższych kategorii, a METR stwierdza, że według jego najlepszej wiedzy w wyniku żadnego z tych incydentów nie uzyskano dostępu do danych z tych kategorii.

Poza tym pojedynym kluczem METR twierdzi, że ręczna i wspomagana przez agentów analiza śledcza nie wykazała naruszenia, a także że konsultant METR ds. bezpieczeństwa, Calif, zweryfikował ustalenia i przeprowadził własną ocenę naruszenia. To istotny mechanizm kontrolny — zewnętrzna firma weryfikuje relację, zamiast przyjmować ją na słowo — ale nie jest niezależny od METR, która zaangażowała i opłaciła Calif. Żadna strona trzecia nie opublikowała własnej analizy śledczej tego incydentu.

Co METR zrobił, gdy to zauważył

Sekwencja reakcji opisana w poście jest konkretna. METR ustalił, że gwałtowny wzrost wykorzystania nie był częścią ewaluacji, prześledził go do przejętej osobistej instancji, unieważnił wszystkie uprawnienia badacza, zatrzymał i wykonał obraz instancji, wymienił wszystkie poświadczenia na niej obecne oraz wykonał obraz i wyczyścił laptop badacza. Powiadomił partnerską firmę AI, której kredyty były zużywane, i informował tę firmę na bieżąco przez cały czas reakcji.

METR nie wyjaśnia powodów stojących za czyszczeniem laptopa, a to jedyny krok w tej sekwencji, który wykracza poza odebranie dostępu do samej instancji — wiarygodna interpretacja jest taka, że ten sam badacz posługiwał się poświadczeniem ze stacji roboczej, do której atakujący mógł dotrzeć, a wykonanie obrazu, a następnie odtworzenie, to tani sposób, by mieć pewność co do maszyny.

Co się potem zmieniło?

METR wymienia cztery zmiany powiązane z tym incydentem:

• Wyjaśniono i rozszerzono zasady bezpieczeństwa dla pracowników i wykonawców, w szczególności w odniesieniu do umieszczania poświadczeń lub danych METR na infrastrukturze i urządzeniach nienależących do METR.

• Proces formalnego przeglądu bezpieczeństwa obowiązuje teraz każdego badacza, który publicznie wdraża aplikację.

• Zwiększono zakres monitorowania, prowadząc prace nad wyeliminowaniem hałaśliwych alertów, które przyzwyczajają reagujących do ignorowania ich.

• Alerty o wydatkach dodano do kluczy tam, gdzie dostawca to umożliwia — to zastrzeżenie ma znaczenie, ponieważ wcześniejsza uwaga we wpisie mówiła, że niektórych kluczy tego rodzaju nie można było wtedy objąć limitem.

Dokument ujawniający wymienia również działania na szczeblu całej organizacji: zatrudnienie osoby odpowiedzialnej za bezpieczeństwo i plany zatrudnienia pełnoetatowego inżyniera ds. bezpieczeństwa, zwiększenie zaangażowania Calif, wyłączanie przestarzałej infrastruktury, która powiększała powierzchnię ataku, prowadzenie regularnych przeglądów modelowania zagrożeń, rozszerzenie rejestrowania zdarzeń na zapytania do baz danych i korzystanie z API, monitorowanie nietypowego użycia kluczy API, wdrażanie dodatkowego oprogramowania zabezpieczającego stacje końcowe i serwery, skracanie okresu ważności poświadczeń oraz ograniczanie zakresów uprawnień. METR podaje, że środki te są aktualne na dzień 30 lipca 2026 r. i zastrzega, że mogą ulec zmianie — zastrzeżenie warte zachowania, ponieważ oznacza, że wpis opisuje stan około czterech miesięcy po kradzieży i około miesiąca przed publikacją.

Drugi incydent w tym samym poście

Ujawnienie METR łączy kradzież klucza z drugim, odrębnym zdarzeniem, do którego doszło na początku maja 2026 r., a oba łatwo pomylić. W tym drugim przypadku METR otrzymał ostrzeżenie, że jest celem atakujących, którzy wydawali się kierować motywacją finansową i mogli chcieć uzyskać dostęp do modeli frontier; obserwował, jak sondowali jego publiczną infrastrukturę, intensywnie wykorzystując agentów do automatyzacji wykrywania luk w zabezpieczeniach, w tym credential stuffing wobec dostawców usług uwierzytelniania, próby przyznania tokenów OAuth, skanowanie nowo wdrożonych usług i phishing pracowników.

W tym samym okresie METR nieumyślnie ujawnił mechanizm zapytań SQL w trybie tylko do odczytu za pośrednictwem publicznej przeglądarki transkryptów. Zapytania domyślnie były ograniczone do danych publicznych, ale błąd można było wykorzystać wobec nieopublikowanych danych ewaluacyjnych, a do tej bazy omyłkowo załadowano pewne wrażliwe wyniki modelu. Niezależny badacz bezpieczeństwa znalazł lukę i odpowiedzialnie ją zgłosił; METR wyłączył API i wypłacił nagrodę. Według relacji METR atakujący natrafili na ten endpoint podczas swojej szerszej kampanii, ale nie wykazali żadnych oznak znalezienia exploitu ani dotarcia do danych niepublicznych — wniosek, który METR w przypisie określa jako „wysoce nieprawdopodobny”, a nie jako zerowy.

Co jest ustalone, a co nie

Ustalone. METR opublikował ujawnienie 31 sierpnia 2026 r.; opisuje ono marcową kradzież, awarię uwierzytelniania typu fail-open, ujawnienie klucza za pośrednictwem agenta, klucz SSH, trzytygodniowe okno i wycenę na około 600 000 USD. Cztery serwisy branży bezpieczeństwa — The Register, Dark Reading, Infosecurity Magazine i The Hacker News — w ciągu doby podały tę samą relację i żaden jej nie zaprzecza — choć wszystkie cztery opierają się na tym samym wpisie METR, a nie na niezależnym dostępie do logów METR lub rozliczeń dostawcy.

Nie ustalono. Kwota 600 000 USD to własne szacunki METR dotyczące darowanego kredytu; nie opublikowano żadnej faktury, oświadczenia dostawcy ani niezależnej wyceny, a ponieważ nic nie zapłacono, nie ma transakcji, z którą można by to zweryfikować. Metoda polowania oparta na przejrzystości certyfikatów jest przez METR określana jako podejrzenie i nie została potwierdzona przez żadną stronę mającą wgląd w działalność atakującego. Tożsamość atakującego, tożsamość dostawcy modelu i dokładny dzień w marcu są nieznane lub nieopublikowane. A twierdzenie, że nie uzyskano dostępu do żadnych danych wrażliwych, opiera się na analizie śledczej METR i przeglądzie jej konsultanta, a nie na zewnętrznym audycie.

Warto też zachować precyzję co do słowa „near-miss”. METR określa oba incydenty w ten sposób, a Dark Reading zakwestionował takie ujęcie marcowego zdarzenia, argumentując, że było to udane naruszenie, w którym napastnik utrzymał trwałą obecność i przez trzy tygodnie działał przy użyciu skradzionego poświadczenia. Oba opisy są trafne, ale dotyczą różnych rzeczy: skutek został ograniczony, a włamanie było prawdziwe.

Dark Reading zamieścił również w swoim artykule najostrzejszą zewnętrzną ocenę. Jacob Krell, senior director ds. bezpiecznych rozwiązań AI i cyberbezpieczeństwa w Suzu Labs, powiedział redakcji, że METR jest jedną z bardziej dojrzałych pod względem bezpieczeństwa organizacji w obszarze AI — posiada certyfikat SOC 2 Type I, dedykowanego konsultanta ds. bezpieczeństwa i czteropoziomowy system klasyfikacji danych — a mimo to incydenty i tak wynikały ze zwykłych przyczyn: wady uwierzytelniania typu fail-open w osobistej instancji chmurowej. Krell argumentował, że jeśli organizacja na takim poziomie dojrzałości daje się złapać na podstawowych kwestiach higieny chmurowej i zarządzania poświadczeniami, mówi to coś o dolnej granicy bezpieczeństwa w branży AI, a nie o jego górnej granicy. Dark Reading zauważa, że METR nie odpowiedział na prośbę redakcji o komentarz do tej historii.

Dlaczego klucz ewaluatora nie jest drobiazgiem

Rola METR jest powodem, dla którego ten zapis trafia do archiwum bezpieczeństwa, a nie do przeglądu higieny chmurowej. Dark Reading donosi, że organizacja współpracuje z większością głównych zachodnich dostawców modeli, w tym z OpenAI, Anthropic, Google, Meta i Amazon, a The Register zauważa, że METR współpracował z OpenAI przy badaniu, w jaki sposób agenci OpenAI dotarli do serwerów Hugging Face wcześniej w 2026 roku. Ewaluator dysponuje niepublikowanymi wynikami, nieopublikowanymi transkryptami oraz dostępem do modeli przed ich wydaniem; jego dane uwierzytelniające są w istocie częścią obwodu bezpieczeństwa jego klientów.

Marcowy incydent nie sięgnął niczego z tego. Sięgnął po klucz do publicznych modeli, na osobistej instancji, za loginem, który po cichu przestał działać — i właśnie dlatego jest użytecznym zapisem. Awaria nie wymagała nowatorskiego ataku na model. Wymagała wdrożenia demonstracyjnego, którego nikt nie przejrzał, kontroli uwierzytelniania, która w razie awarii domyślnie przepuszczała, oraz systemu rozliczeniowego, w którym ogromne użycie było normalnym stanem rzeczy.