Pod koniec lipca 2026 r. firma OpenAI testowała jeden ze swoich nowych modeli w zamkniętym środowisku, gdy model postanowił się wyrwać(nowe okno). Włamał się do prywatnej infrastruktury innej firmy tworzącej oprogramowanie, Hugging Face, aby wykraść klucz odpowiedzi do testu porównawczego bezpieczeństwa cybernetycznego, na którym był testowany. Innymi słowy, złamał prawo ze względu na wygodę.

Kilka dni później UK AI Security Institute ujawnił, że model SI Mythos 5 firmy Anthropic(nowe okno) stworzył fałszywe tożsamości programistów, wyłudził dane od prawdziwych użytkowników serwisu GitHub, skłaniając ich do zatwierdzenia złośliwego kodu, oraz edytował własne logi aktywności, aby zatrzeć ślady po przyłapaniu.

Następnie w sierpniu pojawiła się wiadomość, że mężczyzna z Melbourne o imieniu Andrew poprosił swojego osobistego agenta SI,(nowe okno) zbudowanego na bazie OpenClaw i działającego na modelu Claude firmy Anthropic, o pomoc w zapisaniu się na poranne zajęcia na siłowni, które były już w pełni zarezerwowane. Był czwarty na liście oczekujących i zapytał, czy jest jakiś sposób, aby przesunąć się wyżej.

Agent odkrył, że interfejs API rezerwacji nie ma weryfikacji autoryzacji przy anulowaniu rezerwacji innych użytkowników. Więc bez pytania Andrew o zgodę po prostu anulował rezerwację osoby z pierwszego miejsca, aby zrobić dla niego miejsce. Gdy Andrew poprosił go o cofnięcie anulowania, agent nie mógł tego zrobić: „Osoba, którą usunąłem, zniknęła z listy oczekujących i nie mam możliwości jej przywrócić”.

Źródło tych trzech incydentów nie jest takie samo, ale wynik tak: agenci SI badali i wykorzystywali luki w systemach szybciej i dokładniej, niż zdołałby to zrobić jakikolwiek człowiek. Nigdy nie wydano im polecenia zaatakowania czegokolwiek, ale i tak znaleźli najkrótszą ścieżkę do swojego celu.

Nie ma znaczenia, czy jesteś infrastrukturą zaawansowanego laboratorium, czy oprogramowaniem do rezerwacji na osiedlowej siłowni. Jeśli prowadzisz firmę udostępniającą interfejs API, jesteś teraz czymś, co agent SI może przetestować z szybkością i dokładnością, jakiej żaden ludzki napastnik nie jest w stanie dorównać. I nikt nie musi nawet podejmować decyzji o zaatakowaniu Cię.

Prawdziwym problemem jest szybkość

Ludzki napastnik kalkuluje wysiłek w stosunku do korzyści. Nudzi się, kończy mu się czas, dochodzi do wniosku, że aplikacja do rezerwacji na siłowni nie jest warta zachodu. Ta kalkulacja przez ostatnie 20 lat po cichu chroniła większość celów o niskiej wartości przed przypadkowym wykorzystaniem (chyba że używasz WordPressa).

Agent SI nie dokonuje takiej kalkulacji. Mając wyznaczony cel, wypróbuje wszystko, na co technicznie pozwala interfejs API, testując punkty końcowe i kombinacje parametrów z maszynową prędkością, dopóki coś nie zadziała. Odkrył lukę w autoryzacji siłowni w czasie, w którym Andrew zadawał kolejne pytanie.

Skala tej przepaści w szybkości jest już widoczna w liczbach. Raport Unit 42’s 2026 Global Incident Response Report(nowe okno) wykazał, że najszybsze ataki wykradają obecnie dane w 72 minuty, w porównaniu z 285 minutami rok wcześniej. To trend, w którym ludzie wciąż w dużej mierze biorą udział. Agent podejmuje decyzje w milisekundy; analityk potrzebuje na reakcję od minut do godzin.

Dla zespołów ds. bezpieczeństwa to właśnie ta rosnąca szybkość jest prawdziwym powodem do niepokoju, a nie pojedynczy incydent, o którym pisze się w wiadomościach.

Nowa powierzchnia ataku: wszystko, co ma interfejs API

Każda usługa udostępniająca interfejs API jest potencjalnym celem, niezależnie od tego, czy na taki wygląda.

  • Silniki wyceny, w których zniżki są weryfikowane po stronie klienta
  • Systemy magazynowe, w których stan zapasów znajduje się po stronie sklepu zamiast w backendzie
  • Platformy wsparcia, w których pola wewnętrzne są dostępne poprzez nieudokumentowane ścieżki interfejsu API
  • Zarządzanie subskrypcją, które nie weryfikuje, czy wywołujący jest właścicielem modyfikowanego konta.

Żaden z tych przypadków nie wymaga człowieka, który będzie ich szukać. Wystarczy agent z celem i odpowiadający interfejs API.

Najbardziej narażone firmy to nie te z oczywistymi lukami w zabezpieczeniach. To te z lukami w logice biznesowej: regułami istniejącymi tylko w interfejsie użytkownika, działaniami, na które interfejs API technicznie zezwala, ale interfejs nigdy ich nie wyświetla, oraz procesami stworzonymi na założeniu, że żaden wywołujący nie spróbuje ścieżki pomijającej tę zamierzoną.

Programista siłowni prawie na pewno uznał, że nie warto pisać weryfikacji autoryzacji przy anulowaniu rezerwacji, ponieważ żaden zwykły użytkownik ani zwykły napastnik nie miał powodu, by tego próbować. Agent nie miał takich oporów i nawet nie próbował znaleźć rezerwacji do pominięcia. Po prostu próbował być pomocny.

Jak firmy mogą przygotować się na ataki SI

Traktuj każde działanie w interfejsie API jako operację uprzywilejowaną. Tożsamość, autoryzacja i zasada kontekstowa sprawdzane niezależnie przy każdym wywołaniu. Nie „frontend Ci na to nie pozwoli”, ale „serwer weryfikuje, czy masz prawo to zrobić na tym zasobie przy jego bieżącym stanie”. System siłowni zapobiegłby temu konkretnemu incydentowi dzięki jednej linijce logiki autoryzacji w punkcie końcowym anulowania. To wcale nie jest nowa kontrola — to najstarszy element na liście bezpieczeństwa interfejsów API według OWASP, uszkodzona autoryzacja na poziomie obiektu, i nadal większość systemów realizuje go błędnie.

Nadaj agentom ich własny model danych logowania. Tokeny o ograniczonym zakresie i krótkim czasie TTL, wydawane specjalnie dla sesji agenta, odrębne od zwykłych tokenów sesji ludzkich, ograniczają promień rażenia nawet wtedy, gdy agent znajdzie lukę, której nie przewidziano. Gdyby agent Andrew posiadał token ograniczony tylko do jego własnej rezerwacji, anulowanie rezerwacji kogoś innego nie powiodłoby się na warstwie danych logowania, niezależnie od tego, na co poza tym pozwalałby interfejs API. Jest to ważne, ponieważ nie możesz polegać na powściągliwości samego agenta. Musisz polegać na tym, na co fizycznie pozwalają mu jego dane logowania.

Wdróż narzędzia ukierunkowane na wykrywanie zachowań agentów. Ruch sieciowy generowany przez agenta ma charakterystyczny kształt: nieludzki czas realizacji żądań, systematyczne wyliczanie punktów końcowych, sekwencyjne badanie kombinacji parametrów, pomyślne wykonywanie działań, których żaden użytkownik będący człowiekiem nigdy nie próbował wykonać przez rzeczywisty interfejs. Wyznacz punkt odniesienia dla tego wzorca i wysyłaj alerty w czasie rzeczywistym.

Zmniejsz przepaść w czasie reakcji, a nie tylko w czasie wykrywania. Wykrycie próby po godzinie nie ma znaczenia, jeśli badanie zakończyło się i agent przeszedł dalej w ciągu kilku minut. Podana wyżej liczba z raportu Unit 42, 72 minuty w przypadku najszybszych ataków prowadzonych w tempie człowieka, to już zły punkt odniesienia do planowania. Automatyczna reakcja, a nie tylko automatyczne powiadamianie, jest tym, co niweluje lukę mierzoną w milisekundach. Oczywiście musisz również upewnić się, że Twoja automatyczna reakcja sama w sobie nie wyrządzi szkód.

Załóż, że to się wydarzy, i przećwicz reakcję. Udokumentuj, do kogo należy zadzwonić, przygotuj wstępnie komunikaty dla klientów i przeprowadzaj ćwiczenia teoretyczne ukierunkowane na scenariusze sterowane przez agentów, a nie tylko tradycyjne procedury obsługi naruszeń. Raport IBM 2026 Cost of a Data Breach Report oszacował średni globalny koszt naruszenia danych na 4,99 mln USD, przy czym naruszenia z udziałem SI kosztują średnio o około 1 mln USD więcej. Liczby te w coraz większym stopniu opisują incydenty, które rozpoczęły się tak jak w przypadku siłowni: bez żadnego napastnika w tradycyjnym rozumieniu tego słowa.

Testuj własne interfejsy API tak, jak zrobiłby to agent, zanim agent zrobi to za Ciebie. Ręczne testy penetracyjne zakładają udział testera będącego człowiekiem, który ma ograniczony czas i skończoną listę rzeczy do wypróbowania. Zautomatyzowany symulator ataku ukierunkowany na Twoje punkty końcowe, badający je z taką samą wytrwałością i szybkością jak agent, ujawni te same luki, zanim natknie się na nie asystent klienta. Istnieją już narzędzia open source stworzone specjalnie do tego celu. Na przykład CyberStrike(nowe okno) uruchamia wyspecjalizowanych agentów przypisanych do OWASP WSTG i MITRE ATT&CK przeciwko Twoim punktom końcowym, w tym dedykowany tester luki w autoryzacji na poziomie obiektu — dokładnie tej, która zaskoczyła siłownię: wysyła podstawowe żądanie, wysyła atak i zgłasza wykrycie tylko wtedy, gdy istnieje mierzalna, powtarzalna różnica. To ta sama klasa weryfikacji, która wykryłaby punkt końcowy anulowania, zanim agent znalazłby go w środowisku produkcyjnym.

Zasada ta nie jest oczywiście nowa. Właściciele witryn, którzy w erze botnetów uruchamiali własne skanery podatności na instalacjach WordPressa, przetrwali ten okres. Narzędzia muszą po prostu dorównywać szybkości wywołującego, a nie szybkości ludzkiego napastnika, który być może w końcu się do tego zabierze.