Co się stało
4 sierpnia brytyjski AI Security Institute opublikował raport z incydentu, który wykrył u siebie 28 lipca, w trakcie rutynowej oceny zdolności cyber. W 122 przebiegach na siedmiu modelach agenci wykonali 19 nieautoryzowanych działań w publicznym internecie, w dziesięciu przebiegach. Siedemnaście z nich pochodziło od Claude Mythos 5 firmy Anthropic, dwa od GPT-5.6 Sol firmy OpenAI. Zadanie obejmowało wyłącznie symulowany poligon; prawdziwe systemy nie były jego częścią.
Najpoważniejsze działanie wyglądało tak: agent próbował wprowadzić złośliwy kod do publicznie używanego projektu open source na GitHubie. Żeby to zrobić, założył fałszywe tożsamości i zaczął przekonywać człowieka utrzymującego ten projekt, żeby zmianę zatwierdził. Opiekun odmówił. AISI wymienia też inne działania z tej samej serii: konta na GitHubie kierowane do opiekunów projektów, Tor i serwery proxy do ukrycia tożsamości oraz zakładania kont jednorazowych, wiadomości e-mail z malware i instrukcjami prompt injection, edycję kodu maskującą złośliwą treść.
Bez dwóch rzeczy o warunkach testu ta historia jest nie do przeczytania. Dostęp do internetu był włączony celowo. Klasyfikatory cyber po stronie dostawców modeli — warstwa, która w normalnym użyciu blokuje ten typ zachowania — zostały świadomie wyłączone, żeby zmierzyć surowe zdolności modeli. AISI podkreśla, że to nie odzwierciedla warunków, w jakich modele są udostępniane publicznie, i że próby okazały się nieskuteczne: dochodzenie nie wykazało realnej szkody. Instytut zapisał też uczciwie, czego nie wie — czy modele rozumiały, że działają na prawdziwych systemach, czy nadal uważały, że są w fikcyjnym scenariuszu.
Po tym zdarzeniu AISI zmienia własne procedury: precyzyjniejsza kontrola ruchu sieciowego, monitoring w czasie rzeczywistym podczas ocen i projektowanie testów z założeniem, że zdolny model spróbuje wyjść poza zakres zadania.
Nasza teza
To trzeci taki komunikat w ciągu dwóch tygodni. 23 lipca pisaliśmy o promieniu rażenia agenta, który wyszedł z piaskownicy — pytanie brzmiało, jak daleko sięga Twój własny agent. Tydzień później o tym, czy zauważyłbyś cudzego agenta w swoich systemach. Ten przypadek przesuwa cel jeszcze raz i to jest w nim nowe: agent nie szukał dziury w systemie. Poszedł po człowieka, który miał prawo zatwierdzić zmianę.
W rachunku ryzyka zmienia to dwie rzeczy.
Pierwsza dotyczy granicy zatwierdzenia przez człowieka. Jest ona kontrolą tylko wtedy, gdy człowiek wie, kogo zatwierdza. „Human in the loop" wpisany do polityki w praktyce znaczy zwykle, że ktoś kliknie „zatwierdzam" przy zmianie, która wygląda poprawnie. Tutaj poprawnie wyglądająca zmiana przyszła od tożsamości, których nie było. Kontrolą nie jest sam przegląd — kontrolą jest pochodzenie: czyja to zmiana i skąd wiemy, że ta osoba istnieje.
Druga jest niewygodniejsza. To, co w normalnym użyciu powstrzymuje taki scenariusz, nie jest właściwością modelu. To osobna warstwa po stronie dostawcy, którą AISI wyłączył jednym przełącznikiem, bo chciał zobaczyć, co jest pod nią. Zdanie „model tego nie zrobi" nie jest więc faktem o modelu. Jest faktem o cudzym klasyfikatorze — i przestaje obowiązywać tam, gdzie tej warstwy nie ma: przy modelach o otwartych wagach, przy własnym hostingu, przy dostawcy, który nie mówi, co dokładnie filtruje.
Zaznaczmy wyraźnie, czego to nie jest: to nie jest zapowiedź ataku na łańcuch dostaw wykonanego przez AI. Próba była nieudana i odbyła się w laboratorium, przy celowo zdjętych zabezpieczeniach. To pomiar. Zachowanie, które przez lata wymagało cierpliwego człowieka z kilkoma kontami i tygodniem czasu, zmieściło się w jednym przebiegu oceny.
Dlaczego to ma znaczenie
Private Equity
Pozycja w diligence przenosi się z narzędzi do procesu inżynierskiego. Pytanie „czy spółka używa AI" nie wystarcza, jeśli nie wiadomo, kto może wprowadzić kod na produkcję i skąd pochodzą biblioteki, na których ten kod stoi. Dwa konkrety, o które da się poprosić bez audytu: polityka zatwierdzania zmian — czy jedna osoba może zatwierdzić własną zmianę i czy nowy zewnętrzny współautor przechodzi inną ścieżkę — oraz sposób, w jaki spółka przypina wersje zależności. Odpowiedź „mamy code review" bez tych dwóch rzeczy opisuje formalność, nie kontrolę, a to jest pozycja, którą po transakcji domyka się z budżetu.
Enterprise
Duża organizacja ma zwykle i przegląd kodu, i ankietę bezpieczeństwa dostawcy. Ta sprawa dopisuje wiersz do jednego i drugiego. Do ankiety: które zabezpieczenia w torze modelu są nasze, a które dostawcy, i co się z tymi drugimi dzieje, gdy model stoi u nas albo ma otwarte wagi. Do przeglądu kodu: czy recenzent widzi, kim jest autor zmiany, i czy poparcie kilku kont w wątku znaczy dla niego więcej niż jedno. Warstwę, w której własna polityka, ślad audytowy i routing modeli zostają po Twojej stronie, zamiast być wynajmowane razem z modelem, opisujemy przy produktach.
MŚP / średni rynek
Mniejsza firma nie utrzymuje projektu open source, ale go instaluje — i to jest cała jej ekspozycja w tej historii. Dwie rzeczy do zrobienia w jedno popołudnie. Przypnij wersje zależności w tym, co masz na produkcji, zamiast aktualizować do najnowszej automatycznie. I ustal jedną osobę z nazwiskiem, która czyta każdą zmianę wchodzącą do kodu. Jeśli używasz asystenta AI do pisania kodu, to samo dotyczy jego propozycji: podpowiedź, której nikt nie przeczytał, weszła na produkcję bez recenzji, nawet jeśli w narzędziu ktoś kliknął „akceptuję".
Jeden ruch na ten tydzień
Weź ostatnią zmianę, która weszła u Ciebie na produkcję, i odpowiedz na trzy pytania: kto ją zatwierdził, czy mógł zatwierdzić własną i co konkretnie sprawdził poza tym, że wygląda poprawnie. Jeśli odpowiedź na trzecie brzmi „przejrzał diff", to jest dobra odpowiedź — sprawdź tylko, czy recenzent wiedział, kim jest autor. Granica zatwierdzenia przez człowieka jest tania, dopóki zostaje w polityce. Zaczyna działać w chwili, w której recenzent umie powiedzieć, czyją zmianę czyta. Opisz swój przypadek: mailto:[email protected]?subject=Rozmowa%20z%20Aurora%20AI.