Kontrola, która działa poprawnie i mierzy nie to, co trzeba, jest gorsza niż jej brak.

Złośliwe wydanie popularnej biblioteki rozeszło się w pół godziny na ponad czterysta pakietów w dziewięciu organizacjach — z ważną atestacją, poprawnym poświadczeniem pochodzenia i podpisem. Wszystko się zgadzało poza tym, kto w tym momencie kontrolował konto opiekuna. Podpis potwierdza pochodzenie, nie intencję; dopóki konto jest w rękach właściciela, te dwie rzeczy się pokrywają.

Ta sama cisza w dłuższym horyzoncie: marcowa kompromitacja skanera podatności doprowadziła przez bramę AI do sekretów 2488 firm. Zatrute wersje wisiały czterdzieści minut. Pięć miesięcy później część kluczy wciąż działa, a większość organizacji ich nie zrotowała — bo nie wie, że ich to dotyczy. Nikt nie wysłał powiadomienia, zależność zaktualizowała się sama, nic nie przestało działać.

Przy kompromitacji trwającej czterdzieści minut w warstwie zależności brak sygnału jest stanem domyślnym. Nie ma alertu, nie ma incydentu do obsłużenia, jest tylko cicho rosnąca liczba ważnych poświadczeń w cudzych rękach.

Wariant trzeci nie wymagał nawet kompromitacji czegokolwiek: przez siedemnaście miesięcy ktoś odczytywał cudze portale klienckie, nie wykorzystując żadnej podatności — przez konto gościa, którego nie da się usunąć, i uprawnienia przyznane kiedyś przez kogoś innego.

Czwarty ujawnił się w naprawianiu. Z sześciu tysięcy łatek generowanych przez modele tylko około jednej czwartej zamknęło błąd czysto, a ponad jedna trzecia uznanych za udane blokowała zademonstrowany atak wąskim sprawdzeniem, zostawiając podatny kod na miejscu. Łatka czyta się jak łatka, przechodzi testy i w trzech przypadkach na cztery czegoś nie domyka.

Osobną odmianą jest podatność istniejąca wyłącznie w złożeniu poprawnych elementów. Luka w rdzeniu systemu publikacyjnego mieszkała w różnicy między dwoma mechanizmami sanityzującymi — jeden czytał spację po nawiasie jako tekst, drugi jako początek znacznika. Poprawka nie zmieniła żadnego z nich. A najczystszy przypadek pokazało badanie z DEF CON: firewall blokował złośliwe żądanie i zapisywał je w logu, po czym agent czytający ten log wykonywał zawarte w nim polecenia. Im wierniej mechanizm obronny robił swoje, tym czystszy ładunek trafiał do agenta.

Przez rok mierzyliśmy, jak wysoko sięgają zdolności. Liczy się podłoga.

Cztery wydania bezpieczeństwa rdzenia w niecały miesiąc dały konkretny cennik: dziesięć godzin i około dwudziestu pięciu dolarów za pełny łańcuch do wykonania kodu. Te luki były tam wcześniej, część od dekady. Zmieniła się nie jakość kodu, lecz koszt jego przeszukania — a rytm wydań przestał być miarą tego, jak dziurawe jest oprogramowanie, i stał się miarą tego, ile osób może sobie pozwolić, żeby w nim poszukać.

Wspólne ostrzeżenie pięciu amerykańskich agencji o atakach na sterowniki przemysłowe to pierwszy taki dokument potwierdzający użycie kodu generowanego przez AI przeciwko systemom sterowania. Ale sedno nie leży w AI: sterowniki stały wystawione do internetu, na przestarzałym oprogramowaniu albo domyślnych hasłach. Nie zmieniła się powierzchnia ataku, tylko liczba osób zdolnych z niej skorzystać — bo zniknął wymóg znajomości protokołu przemysłowego.

To samo ostatnie ogniwo pojawiło się w ataku na polską elektrociepłownię, gdzie napastnicy przeszli przez rzekomo odseparowaną sieć operatora i znaleźli sterownik z domyślnymi poświadczeniami. Dwa kontynenty, dwie różne drogi dojścia, identyczny finał.

Najmocniejszy dowód przyszedł od napastnika. Afiliant prowadzący włamania do ośmiu organizacji użył starszej wersji asystenta kodującego, bo nowsze mają mocniejsze zabezpieczenia. Wybrał gorsze narzędzie w zamian za mniej odmów.

To jest paradoksalnie dowód, że zabezpieczenia działają — na tyle, że opłaca się je omijać kosztem jakości. Ale pokazuje też, gdzie realnie przebiega linia obrony: reglamentuje się dostęp do najnowszych zdolności, a napastnikowi wystarcza to, co najsłabiej zabezpieczone i musi pozostać dostępne dla klientów.

Po roku upadających barier trzy niezależne realizacje jednej zasady.

Najważniejsza branżowa lista zagrożeń dla aplikacji opartych na modelach otworzyła sierpień zdaniem, które jest naszą lipcową tezą wypowiedzianą przez instytucję: przestańcie próbować zbudować model, którego nie da się oszukać — budujcie system tak, żeby kiedy zostanie oszukany, nic ważnego się nie zepsuło. Lista została przeramowana z doskonałej prewencji na kontrolę promienia rażenia.

Dwa tygodnie później pojawiła się do tej zasady implementacja. W opublikowanej architekturze agent działa jako orkiestrator, a nie strażnik — autoryzację egzekwują usługi znajdujące się niżej, warunek dostępu ocenia mechanizm uprawnień na poziomie polityki, a rola wykonawcza agenta nie ma własnych uprawnień do magazynów danych. Wszystkie cztery bariery, które zawiodły do lipca, wymagały, żeby coś po stronie agenta zachowało się właściwie. Ta nie wymaga niczego.

W tym samym tygodniu producent modeli odpowiedział na to samo pytanie z drugiej strony: zamiast luzować zabezpieczenia silniejszego modelu, zamknął go w wąskim interfejsie. Użytkownik dostaje wynik skanowania, nie pole do wpisywania.

Ta zasada ma jednak niewygodną drugą stronę. Gdy jeden z dostawców uruchomił program zdejmujący zabezpieczenia cyber zweryfikowanym obrońcom, ujawniło się, że guardrail blokował dotąd głównie obrońcę — bo analiza powłamaniowa polega na wysyłaniu modelowi dokładnie tych treści, które zabezpieczenia mają odrzucać. Odpowiedź branży na ten paradoks okazała się nie techniczna, lecz administracyjna: skoro nie potrafimy odróżnić obrońcy od atakującego po treści zapytania, sprawdzimy go po dokumentach.