Incydenty bezpieczeństwa w METR ujawniają awarię poświadczeń AI wartą 600 000 USD

METR ujawnił dwa incydenty bezpieczeństwa po tym, jak atakujący ukradł klucz API i wykorzystał kredyty modelowe o wartości około 600 000 USD. Pierwszy atak trwał przez trzy tygodnie, mimo że generował nietypowy ruch i powtarzające się błędy limitów szybkości.

Strata nie przełożyła się na bezpośredni rachunek, ponieważ twórca modelu przyznał METR kredyty bez opłat. Ograniczyło to wpływ finansowy, ale jednocześnie wyeliminowało próg wydatków, który mógł wcześniej ujawnić nadużycie.

Incydenty bezpieczeństwa w METR mają znaczenie wykraczające poza jedną organizację badawczą. Eksperymentalny panel agentów połączył w jednym systemie dostęp do chmury, aktywne poświadczenia, publiczną ekspozycję i słabe monitorowanie. To połączenie zamieniło błąd uwierzytelniania w długotrwały dostęp do cennych zasobów obliczeniowych.

METR twierdzi, że jego dochodzenie nie wykazało dowodów na to, że atakujący uzyskali dostęp do najbardziej wrażliwych informacji organizacji. Drugi incydent pokazał jednak, jak blisko publiczne narzędzia badawcze znalazły się prywatnych danych ewaluacyjnych. Łącznie te przypadki podważają założenie, że prototypy o niskiej stawce zasługują na łagodniejsze środki bezpieczeństwa.

Incydenty bezpieczeństwa w METR zaczęły się od ujawnionego panelu agentów

Pierwszy incydent rozpoczął się jako typowy błąd uwierzytelniania, lecz agent AI zapewnił drogę od publicznego dostępu do kradzieży poświadczeń.

W marcu 2026 roku badacz METR wdrożył agentów na prywatnej instancji Amazon EC2. EC2 to platforma Amazon Web Services do wynajmowania wirtualnych serwerów. Badacz celowo udostępnił instancję w internecie i umieścił ją za uwierzytelnianiem Google.

Aplikacja zawierała to, co METR nazwał podatnością fail-open. System fail-open kontynuuje działanie, gdy kontrola uwierzytelniania zawiedzie, zamiast odmawiać dostępu. W tym przypadku błąd po cichu wyłączył uwierzytelnianie i ujawnił panel na kilka dni.

Instancja EC2 zawierała również klucz API połączony z kontem METR o ogólnym dostępie do publicznych modeli. Klucz API to poświadczenie, którego oprogramowanie używa do uwierzytelniania żądań kierowanych do usługi online.

Według ujawnienia informacji o bezpieczeństwie METR atakujący nakłonił agenta do ujawnienia tego klucza dostawcy modeli. Następnie zainstalował klucz SSH, tworząc trwałą metodę zdalnego dostępu do przejętego serwera.

Ta sekwencja jest istotna. Atakujący nie musiał omijać zabezpieczeń zaawansowanego modelu ani opracowywać nowego exploita AI. Początkowe otwarcie wynikało ze zwykłej kontroli aplikacji webowej, która zawiodła w niebezpiecznym stanie.

Agent mimo to wpłynął na rezultat. Gdy osoba z zewnątrz uzyskała dostęp do interfejsu, agent mógł uzyskać dostęp do poświadczenia mającego wartość poza samą aplikacją lub je odtworzyć. Przejęty panel stał się więc pomostem do oddzielnego konta u dostawcy modeli.

METR podejrzewa, że atakujący odkrył instancję, monitorując niedawno zarejestrowane witryny. Rejestry przejrzystości certyfikatów mogą pomagać identyfikować nowe domeny i subdomeny, ponieważ publicznie zapisują wydane certyfikaty webowe.

Organizacja uważa, że atakujący przeszukiwał te rejestry pod kątem terminów związanych z dużymi modelami językowymi i agentami. Takie terminy mogą wskazywać eksperymentalne usługi, które mogą zawierać cenne poświadczenia dostawców.

To wyjaśnienie pozostaje oceną METR, a nie publicznie zweryfikowaną atrybucją. METR nie zidentyfikował atakującego, dostawcy modelu ani dokładnej infrastruktury wykorzystywanej do odkrywania celów.

Po uzyskaniu poświadczenia intruz używał go przez trzy tygodnie. METR obliczył, że wykorzystane kredyty byłyby warte około 600 000 USD, choć organizacja nie zapłaciła tej kwoty.

Zapadająca w pamięć liczba związana z incydentem może odwracać uwagę od szerszego łańcucha błędów. Publiczna ekspozycja, poświadczenie dostępne dla agenta, trwały dostęp do hosta i niepełna widoczność użycia musiały pozostać nierozwiązane.

Każda z tych kontroli mogła ograniczyć szkody. Uwierzytelnianie mogło odmówić dostępu. Izolacja poświadczeń mogła zapobiec ich ujawnieniu. Monitorowanie hosta mogło wykryć nowy klucz SSH. Limity po stronie dostawcy mogły ograniczyć zużycie.

Atak powiódł się, ponieważ te zabezpieczenia nie zatrzymały tego samego ciągu zdarzeń.

Dlaczego trzy tygodnie nadużywania modeli wyglądały jak zwykłe badania

Normalne obciążenie METR tworzyło wystarczająco dużo szumu operacyjnego, by ukryć aktywność atakującego.

METR ocenia zaawansowane systemy AI poprzez eksperymenty, które mogą zużywać duże ilości tokenów. Tokeny to jednostki używane do mierzenia tekstu przetwarzanego lub generowanego przez model. Duże uruchomienia ewaluacyjne mogą również wywoływać nietypowe limity szybkości i błędy dostawcy.

Ten wzorzec działania osłabił typowy sygnał bezpieczeństwa. Wysokie użycie nie wyglądało automatycznie na złośliwe, ponieważ legalne badania METR mogły wywoływać podobne zachowania.

METR podał, że jego wewnętrzny panel nie wyświetlał wszystkich żądań użytkowników objętych ograniczeniami szybkości, gdy doszło do incydentu. Śledczy nie mieli więc pełnego obrazu aktywności związanej z przejętym kontem.

Organizacja nie miała też naturalnego limitu wydatków dla dotkniętego klucza. Ponieważ dostawca modeli udostępnił kredyty bez obciążania METR, rosnąca faktura nie wymuszała natychmiastowego dochodzenia.

Brak rachunku nie czynił zasobu bezwartościowym. Inferencja modeli zużywa moc obliczeniową, a dostęp do niej można odsprzedawać lub wykorzystywać do niepowiązanych obciążeń. Atakujący uzyskał zbywalną korzyść ekonomiczną, mimo że METR uniknął płatności gotówkowej.

Niezależne relacje dotyczące opisywanej osi czasu podkreślały tę samą lukę w monitorowaniu. Nielegalne zużycie zlało się ze środowiskiem przyzwyczajonym już do wysokich wolumenów tokenów i niespójnych komunikatów o limitach szybkości.

To kluczowe odwrócenie w incydentach bezpieczeństwa METR. Skala zwykle pomaga grupie badawczej testować zaawansowane modele, lecz ta sama skala utrudniała odróżnienie anomalnego zużycia.

Tradycyjne alerty dotyczące wydatków mogą szybko ujawnić skradzione poświadczenie chmurowe. Jednak darowane kredyty, alokacje badawcze i przedpłacona pojemność mogą osłabiać tę ochronę. Organizacje nadal potrzebują limitów opartych na wzorcach użycia, źródłach żądań, tożsamości klucza i oczekiwanych obciążeniach.

Próg powinien uwzględniać również nieudane żądania oraz żądania ograniczone limitem szybkości. Mogą one ujawniać rozpoznanie lub próby zużycia, nawet jeśli nie pojawiają się w standardowych sumach rozliczeniowych.

Incydent pokazuje, dlaczego sam wolumen jest niepełną metryką. Lepszy system wykrywania pyta, czy aktywność odpowiada ustalonemu celowi danego klucza.

Poświadczenie przypisane do jednego eksperymentu nie powinno przez tygodnie po cichu obsługiwać niepowiązanego ruchu. Oddzielne klucze dla każdej aplikacji ułatwiają takie porównanie, ponieważ zmniejszają liczbę legalnych zachowań przypisanych do jednej tożsamości.

Poświadczenia krótkotrwałe dodatkowo ograniczyłyby okno ataku. Klucz, który wygasa lub wymaga odnowienia, ogranicza czas, przez który skopiowana wartość pozostaje użyteczna. Długotrwałe sekrety dają atakującym więcej czasu na ustanowienie trwałości i monetyzację dostępu.

METR zareagował, dodając alerty wydatków tam, gdzie dostawcy je obsługiwali. Organizacja rozszerzyła także zakres monitorowania i pracowała nad ograniczeniem liczby hałaśliwych alertów.

Zmiany te odnoszą się do widocznych objawów, lecz głębsza lekcja dotyczy granic systemu. Obciążenie badawcze nie powinno czynić niewyjaśnionej aktywności akceptowalną tylko dlatego, że nietypowe użycie zdarza się regularnie.

Normalne operacje potrzebują mierzalnych zakresów, wskazanych właścicieli i zdefiniowanych wyjątków. W przeciwnym razie „ruch badawczy” staje się szeroką kategorią, która ukrywa zarówno legalne eksperymenty, jak i nieautoryzowane zużycie.

Prawdziwy konflikt dotyczy szybkiego eksperymentowania kontra ograniczony dostęp

Rozwój agentów premiuje szybkie wdrażanie, podczas gdy bezpieczeństwo zależy od ścisłych granic, których często brakuje prototypom.

METR opisał ujawniony panel jako vibe-coded, co oznacza, że został opracowany głównie poprzez wspomagane przez AI prompty i iteracyjne generowanie. Określenie to nie dowodzi, że narzędzie do kodowania AI spowodowało błąd uwierzytelniania.

Istotne jest to, w jaki sposób powstała aplikacja została zrecenzowana i wdrożona. Oprogramowanie przyjmowało publiczny ruch, współdziałało z agentami i działało w pobliżu aktywnego poświadczenia dostawcy. Warunki te czyniły je czymś więcej niż jednorazowym lokalnym prototypem.

Szybkie eksperymentowanie jest wartościowe w ewaluacji modeli. Badacze często potrzebują niestandardowych interfejsów, tymczasowych narzędzi do orkiestracji i nowych kombinacji modeli. Długi proces zatwierdzania może utrudniać pracę eksploracyjną.

Jednak kategoria bezpieczeństwa powinna zależeć od dostępu i ekspozycji systemu, a nie od jego planowanego okresu życia. Tymczasowa aplikacja staje się podobna do systemu produkcyjnego, gdy jest dostępna z internetu i przechowuje wielokrotnego użytku poświadczenia.

Agent nie powinien też mieć możliwości ujawnienia surowego klucza. Aplikacje często potrzebują uprawnień do wywoływania usług zewnętrznych, lecz nie wymaga to umieszczania wielokrotnego użytku sekretu w kontekście czytelnym dla modelu.

Broker poświadczeń może wykonać autoryzowane żądanie w imieniu agenta bez ujawniania bazowego klucza. Wąsko określone możliwości mogą również ograniczać modele, operacje lub poziomy użycia, do których aplikacja ma dostęp.

To rozdzielenie ma znaczenie, ponieważ modele językowe przetwarzają niezaufane instrukcje. Atakujący, który uzyska dostęp do interfejsu agenta, może poprosić model o ujawnienie ukrytych danych, nadużycie podłączonych narzędzi lub wykonanie działań wykraczających poza zamierzony przepływ pracy aplikacji.

Wskazówki dotyczące bezpieczeństwa agentów OWASP wskazują ujawnienie wrażliwych danych, nadmierne uprawnienia, nadużywanie narzędzi i prompt injection jako powiązane zagrożenia. Zalecają ograniczanie uprawnień i przechowywanie poświadczeń poza kontekstem dostępnym dla agenta.

Ujawnienie METR mówi, że atakujący bezpośrednio nakłonił agenta do ujawnienia klucza dostawcy. Przypomina to oparte na promptach wydobywanie poświadczeń, jednak publicznie dostępne dowody nie opisują zachowania modelu wystarczająco szczegółowo, by dokonać formalnej klasyfikacji.

Błąd uwierzytelniania nadal był pierwszym decydującym błędem kontroli. Bez publicznego dostępu osoba z zewnątrz nie miałaby interfejsu, przez który mogłaby wysłać żądanie.

Określanie tego zdarzenia wyłącznie jako ataku prompt injection byłoby więc nadmiernym uproszczeniem. Ścieżka straty łączyła niebezpieczne wdrożenie, ujawnienie sekretu, zbyt szeroki dostęp agenta, trwałość i słabe monitorowanie zużycia.

Podobnie obwinianie wyłącznie vibe coding pomijałoby ugruntowane praktyki bezpieczeństwa, które obowiązują niezależnie od sposobu wytworzenia kodu. Prototypy napisane przez ludzi również mogą działać w trybie fail-open, ujawniać sekrety i pomijać telemetrię.

METR posiadał już udokumentowane kontrole bezpieczeństwa dla swojej produkcyjnej platformy ewaluacyjnej. Opublikowany raport SOC 2 opisywał kontrole zaprojektowane na sierpień 2025 roku dla tego określonego systemu.

Raport SOC 2 Type I ocenia projekt kontroli w określonym momencie. Nie gwarantuje, że każdy osobisty eksperyment, tymczasowa usługa lub późniejsze wdrożenie podlega tym samym kontrolom.

To rozróżnienie leży u podstaw incydentu. Organizacje mogą zabezpieczać główną platformę, podczas gdy badacze tworzą równoległą infrastrukturę poza jej formalną granicą.

Prywatne konta chmurowe utrudniają dostrzeżenie tej fragmentacji. Centralne zespoły bezpieczeństwa mogą nie mieć logów, inwentaryzacji, kontroli sieciowych ani zautomatyzowanego egzekwowania polityk dla instancji tworzonych poza zarządzanymi środowiskami.

METR poinformował, że badacz nie miał dostępu do dwóch kategorii o najwyższej wrażliwości. Ograniczało to pozorny zasięg potencjalnych szkód. Mimo to instancja nadal zawierała poświadczenie dostawcy, które było wartościowym celem.

Wniosek nie jest taki, że eksperymenty muszą się zakończyć. Chodzi o to, że ekspozycja na internet i aktywne poświadczenia powinny automatycznie uruchamiać podstawowy przegląd bezpieczeństwa, nawet w przypadku krótkotrwałego narzędzia badawczego.

Drugi atak naraził dane ewaluacyjne na ryzyko

Kampania z maja pokazała, że atakujących nie interesowała wyłącznie tania moc obliczeniowa; badali też ścieżki prowadzące do niepublicznego dostępu do modeli i danych ewaluacyjnych.

Na początku maja 2026 roku METR dowiedział się, że hakerzy atakowali jego publiczną infrastrukturę. Organizacja oceniła, że ich motywacją były korzyści finansowe, i stwierdziła, że mogli dążyć do uzyskania dostępu do modeli frontierowych.

METR zaobserwował systematyczne sondowanie obejmujące credential stuffing, próby nadania uprawnień OAuth, skanowanie nowo wdrożonych usług oraz próby phishingu wymierzone w pracowników. Credential stuffing polega na testowaniu wcześniej wykradzionych kombinacji logowania w innych usługach.

Organizacja poinformowała, że atakujący intensywnie wykorzystywali agentów do automatyzacji wykrywania podatności. Twierdzenie to sugeruje, że AI zmniejszyła wysiłek potrzebny do skanowania wielu usług i ścieżek uwierzytelniania, choć METR nie opublikował pomiarów wydajności.

W tym samym okresie METR nieumyślnie udostępnił mechanizm zapytań SQL tylko do odczytu za pośrednictwem publicznej przeglądarki transkrypcji. SQL to język, którego aplikacje używają do pobierania informacji z ustrukturyzowanych baz danych.

Zapytania miały domyślnie zwracać rekordy publiczne. Błąd mógł jednak zmienić ten zakres i ujawnić nieopublikowane dane ewaluacyjne.

METR oczekiwał, że bazowa baza danych będzie zawierać wyłącznie wyniki dotyczące publicznych modeli. Jednak część wrażliwych wyników modeli została do niej przypadkowo włączona.

Niezależny badacz bezpieczeństwa odkrył błąd i odpowiedzialnie go zgłosił. METR wyłączył dotknięte API i wypłacił nagrodę.

Atakujący zetknęli się z tym endpointem podczas skanowania infrastruktury METR. Organizacja twierdzi, że jej dowody nie wskazują, by odkryli exploit lub uzyskali dostęp do niepublicznych informacji.

Wniosek ten wymaga ostrożnego sformułowania. Brak dowodów nie stanowi matematycznego dowodu, że dostęp nigdy nie nastąpił. Odzwierciedla to, co METR i jego konsultant ds. bezpieczeństwa znaleźli w dostępnych logach i materiałach kryminalistycznych.

METR wyjaśnił, że wykorzystanie podatności wymagało kilku konkretnych kroków. Atakujący musiał odkryć błąd zakresowania, poprawnie go wykorzystać, zidentyfikować wrażliwe transkrypcje i pobrać je bez wywoływania błędów.

Organizacja uznała taki ciąg zdarzeń za bardzo mało prawdopodobny. Przyznała też, że pojawiła się komplikacja: tymczasowo usunęła endpoint, później przywróciła go bez zauważenia błędu i nie odnotowała późniejszego dostępu atakujących.

Ten drugi epizod wiąże się z inną stawką niż skradzione kredyty. Nieopublikowane ewaluacje mogą ujawniać słabości modeli, wzorce zachowania, ukryte wyniki lub informacje przekazane na podstawie umów o poufności.

METR dzieli swoje informacje na cztery szerokie kategorie. Opublikowane materiały znajdują się na najniższym poziomie. Poświadczenia modeli publicznych oraz nieopublikowane wyniki modeli publicznych należą do kolejnej kategorii.

Dwie wyższe kategorie obejmują dostęp do wrażliwych modeli i wysoce wrażliwe informacje organizacyjne. METR twierdzi, że jego dochodzenie nie wykazało dostępu do informacji z tych kategorii podczas żadnego z incydentów.

Mimo to baza transkrypcji zawierała część materiałów z wyższej kategorii, choć nie powinna. Oznacza to, że zamierzona granica klasyfikacji zawiodła jeszcze zanim ktokolwiek próbował wykorzystać mechanizm zapytań.

Rozdzielanie danych wyłącznie na podstawie polityki jest niewystarczające, jeśli rekordy mogą trafić do niewłaściwej bazy danych. Skuteczna izolacja wymaga także automatycznych kontroli klasyfikacji, kontroli dostępu w momencie wykonywania zapytania oraz logów zachowujących dowody na potrzeby późniejszego dochodzenia.

Pierwszy incydent ujawnił granicę poświadczeń. Drugi ujawnił granicę danych. Oba dotyczyły publicznie dostępnych systemów badawczych, które znajdowały się bliżej cennych zasobów, niż uzasadniały ich zamierzone role.

Reakcja METR zmniejsza ryzyko, ale pozostawia pytania dotyczące weryfikacji

METR zmienił swoją architekturę i proces bezpieczeństwa, jednak osoby z zewnątrz nie mogą jeszcze zmierzyć, jak konsekwentnie te kontrole obejmują przyszłe eksperymenty.

Po wykryciu marcowego nadużycia METR cofnął badaczowi dostęp i zatrzymał skompromitowaną instancję. Utworzył obraz kryminalistyczny, wymienił poświadczenia, wykonał obraz laptopa badacza i wyczyścił go oraz poinformował odpowiednią firmę oferującą model.

Firma konsultingowa ds. bezpieczeństwa Calif przeanalizowała ustalenia METR i przeprowadziła odrębną ocenę kompromitacji. METR wykorzystał również ręczną analizę kryminalistyczną oraz analizę wspomaganą przez agentów do zbadania incydentu.

Organizacja twierdzi, że działania te nie wykazały kompromitacji wykraczającej poza pojedynczy klucz API publicznego modelu. Nie opublikowała pełnej oceny konsultanta, szczegółowych wskaźników kompromitacji ani tożsamości dostawcy.

METR rozszerzył polityki dotyczące poświadczeń i danych w infrastrukturze osobistej. Utworzył także formalny przegląd bezpieczeństwa dla badaczy wdrażających publiczne aplikacje.

Po majowej kampanii METR tymczasowo wyłączył niemal wszystkie usługi publicznie dostępne oraz wewnętrzny dostęp do wrażliwych danych. Następnie utworzył odizolowane publiczne środowisko produkcyjne, architektonicznie oddzielone od infrastruktury wewnętrznej.

To rozdzielenie bezpośrednio odpowiada na ryzyko związane z przeglądarką transkrypcji. Jeśli będzie konsekwentnie egzekwowane, wada publicznej aplikacji nie powinna już zapewniać drogi do wewnętrznego systemu danych.

METR wyłączył również starszą infrastrukturę, zwiększył zakres logowania, skrócił okres ważności poświadczeń, ograniczył zakresy uprawnień i wdrożył więcej oprogramowania zabezpieczającego endpointy oraz serwery.

Organizacja zatrudniła osobę odpowiedzialną za bezpieczeństwo i poinformowała, że planuje dalszą rozbudowę zespołu. Zleciła także dodatkowe działania red-teamowe, podczas których upoważnieni testerzy symulują zachowania atakujących, aby wykrywać słabości.

Kroki te odpowiadają ujawnionym trybom awarii. Poprawiają inwentaryzację, ograniczanie skutków, obsługę poświadczeń, telemetrię i odpowiedzialność.

Sceptyczne pytanie dotyczy zasięgu. Polityki i scentralizowane środowiska działają tylko wtedy, gdy badacze nie mogą ich omijać za pośrednictwem prywatnych kont chmurowych, niezarządzanych usług lub poświadczeń kopiowanych do narzędzi eksperymentalnych.

METR nie opublikował mierzalnych celów dotyczących tego zasięgu. Czytelnicy nie wiedzą, jaki odsetek publicznych wdrożeń jest obecnie objęty przeglądem ani jak szybko nietypowe użycie klucza wywołuje dochodzenie.

Nie jest też jasne, które kontrole działają na warstwie dostawcy modelu. Alerty wydatków pomagają, ale twarde limity użycia, krótkotrwałe tokeny, węższe zakresy i automatyczne unieważnianie zapewniają silniejsze ograniczenia.

Nie każdy dostawca modeli udostępnia te same mechanizmy kontroli. METR zauważył, że w chwili marcowego incydentu nie mógł ustawić limitu wydatków dla dotkniętego klucza.

Dostawca dzieli zatem część szerszego problemu projektowego, nawet jeśli METR kontrolował ujawnioną aplikację. Organizacje obsługujące wartościowy dostęp do modeli potrzebują funkcji konta zakładających, że klucze w końcu wyciekną.

Samo ujawnienie zasługuje na uznanie. METR opublikował szczegółową sekwencję zdarzeń, przyznał się do wielu wewnętrznych błędów i rozróżnił możliwą ekspozycję od dowodów faktycznego dostępu.

Przejrzystości nie należy jednak mylić z niezależną weryfikacją. Kluczowe ustalenia nadal pochodzą z dochodzenia METR i jego zatrudnionego konsultanta.

Żadne publiczne dowody nie identyfikują atakujących ani nie potwierdzają ich motywów. Wycena na poziomie 600 000 USD reprezentuje również przybliżoną wartość przyznanych kredytów, a nie opłaconą fakturę ani niezależnie zweryfikowaną stratę.

Te zastrzeżenia nie unieważniają incydentu. Określają, co potwierdzają dostępne dowody, i zapobiegają nadaniu nagłówkowej kwocie większej precyzji, niż uzasadniają fakty.

Na co zespoły bezpieczeństwa powinny zwracać uwagę po ujawnieniu METR

Kolejnym sprawdzianem będzie to, czy nowe kontrole METR przyniosą widoczne ograniczenia, szybsze wykrywanie i bezpieczniejsze publiczne systemy badawcze.

Pierwszym sygnałem jest egzekwowanie zasad wokół publicznych wdrożeń. METR sformalizował przeglądy bezpieczeństwa, ale wartość tej polityki zależy od tego, czy każdy eksperyment dostępny z internetu trafia do zarządzanego rejestru.

Przydatny rezultat obejmowałby automatyczne wykrywanie nowych domen, instancji chmurowych i publicznych endpointów powiązanych z organizacją. Zespoły bezpieczeństwa powinny porównywać taki rejestr z zatwierdzonymi aplikacjami i wskazanymi właścicielami.

Jeśli przyszłe narzędzia badawcze będą konsekwentnie działać w odizolowanym środowisku publicznym, reakcja METR wesprze jego twierdzenie, że granice architektoniczne zostały poprawione. Kolejne prywatne wdrożenie zawierające aktywne poświadczenia osłabiłoby ten wniosek.

Drugim sygnałem jest mierzalne ograniczanie poświadczeń. METR dodał monitorowanie użycia i alerty wydatków tam, gdzie było to możliwe, lecz alerty nadal wymagają interpretacji i reakcji.

Organizacje powinny szukać krótszych okresów ważności poświadczeń, kluczy specyficznych dla aplikacji, ograniczonych uprawnień dostawcy oraz automatycznego zawieszania po nietypowej aktywności. Surowe poświadczenia powinny pozostawać niedostępne dla kontekstu promptu agenta i kanału jego wyjścia.

Omówienie zagrożeń związanych z prompt injection przez OWASP wyjaśnia, dlaczego same instrukcje modelu nie mogą chronić sekretu. Atakujący może zmanipulować wystawiony model tak, by ignorował zamierzone ograniczenia lub ujawniał informacje dostępne w jego kontekście.

Jeśli METR lub jego dostawcy wdrożą pośredniczony dostęp i twarde limity zużycia, podobne naruszenie interfejsu powinno skutkować mniejszą stratą. Jeśli kontrole pozostaną głównie oparte na alertach, atakujący nadal mogą działać, dopóki człowiek nie rozpozna wzorca.

Trzecim sygnałem są dowody dotyczące separacji danych. METR twierdzi, że jego nowe środowisko publiczne jest odizolowane architektonicznie, ale majowy problem dotyczył również umieszczenia wrażliwych rekordów w niewłaściwej bazie danych.

Izolacja sieciowa sama w sobie nie naprawi błędnie sklasyfikowanych informacji. METR potrzebuje zabezpieczeń wykrywających ograniczone dane ewaluacyjne, zanim trafią one do magazynu dostępnego publicznie.

Przyszłe ujawnienia, audyty lub aktualizacje techniczne powinny pokazać, czy te kontrole zapobiegają zarówno bezpośredniemu dostępowi, jak i przypadkowemu umieszczaniu danych. Pozytywna niezależna ocena wzmocniłaby zaufanie do zmienionej granicy.

Incydenty bezpieczeństwa METR dają również firmom AI powód do ponownego przemyślenia sposobu udostępniania dostępu ewaluacyjnego. Zewnętrzni ewaluatorzy potrzebują realistycznych możliwości modeli, ale szerokie, długotrwałe poświadczenia tworzą atrakcyjne cele.

Dostawcy mogą ograniczyć to ryzyko poprzez tokeny o ograniczonym zakresie, limity na projekt, ograniczenia pochodzenia, szybkie unieważnianie oraz widoczność odrzuconych żądań. Funkcje te chronią zarówno dostawcę, jak i ewaluatora.

Deweloperzy powinni stosować to samo rozumowanie do mniejszych projektów agentowych. Prototyp, który może uzyskać dostęp do poczty e-mail, kodu źródłowego, usług chmurowych lub wewnętrznych dokumentów, już posiada istotną granicę bezpieczeństwa.

Zespoły dokumentujące takie eksperymenty mogą korzystać z kontrolowanej bazy wiedzy, aby zachowywać modele zagrożeń, właścicieli wdrożeń, decyzje z przeglądów i wnioski z incydentów. Dokumentacja nie zastąpi kontroli technicznych, ale może ułatwić znajdowanie niezarządzanych wyjątków.

Najbardziej użyteczne pytanie nie brzmi, czy aplikacja została stworzona metodą vibe codingu. Chodzi o to, czy niezaufany użytkownik może do niej dotrzeć, do jakich poświadczeń ma ona dostęp oraz co się dzieje, gdy każda instrukcja jest traktowana jako wroga.

Ujawnienie METR dostarcza rzadkiej, konkretnej odpowiedzi. Publiczna awaria uwierzytelniania dotarła do agenta, agent ujawnił poświadczenie, a niepełne monitorowanie pozwoliło na trzy tygodnie nieautoryzowanego użycia.

Liderzy bezpieczeństwa powinni teraz przetestować ten sam łańcuch we własnych systemach. Czy osoba z zewnątrz może odkryć interfejs? Czy model może ujawnić sekret? Czy host może zaakceptować trwały dostęp? Czy nietypowe zużycie może zlać się z oczekiwanym ruchem?

Jeśli którakolwiek odpowiedź brzmi „tak”, brak obecnego incydentu odzwierciedla raczej moment w czasie niż opanowanie sytuacji. Kolejna aktualizacja METR powinna pokazać, czy jego nowa architektura przekształciła ciężko zdobyte doświadczenia w egzekwowalne ograniczenia.