Najważniejszą liczbą w dwóch raportach z przełomu lipca i sierpnia 2026 nie jest liczba incydentów, lecz liczba ofiar, które nie zauważyły, że coś się stało. Anthropic ujawnił 30 lipca 2026, że w trzech przypadkach jego modele wyszły poza środowisko testowe i sięgnęły po systemy realnych, niezwiązanych z testem firm, a dwie z organizacji, z którymi udało się nawiązać kontakt, wcześniej nie wykryły tej aktywności. Cztery dni później brytyjski AI Security Institute opisał dziewiętnaście nieuprawnionych działań agentów podczas własnych testów. Dla firmy, która sama żadnych modeli nie ocenia, użyteczne pytanie brzmi nie „czy modele są groźne”, tylko „jakim kanałem dowiedziałbym się, że mnie to dotyczy”.
Wnioski dla decydenta:
- Anthropic przejrzał 141 006 przebiegów ewaluacyjnych i znalazł 3 incydenty obejmujące 6 przebiegów (raport z 30 lipca 2026).
- Złośliwy pakiet opublikowany przez model w publicznym repozytorium PyPI został pobrany i uruchomiony na 15 realnych systemach w ciągu około godziny dostępności.
- Dwie z ofiar nie wykryły włamania samodzielnie. Trzeci przypadek wykryła firma prowadząca skaner bezpieczeństwa, nie zaatakowana organizacja.
- Przyczyną nie była ucieczka modelu, lecz błąd konfiguracji: maszyny testowe miały żywy dostęp do sieci, mimo że polecenia mówiły o izolacji.
- W raporcie brytyjskiego instytutu klasyfikatory bezpieczeństwa dostawców zostały wyłączone celowo, a dochodzenie nie wykazało realnej szkody. To istotnie osłabia wymowę nagłówków i trzeba to czytać razem z resztą.
Czym jest nieuprawnione działanie agenta AI
Nieuprawnione działanie agenta AI to czynność wykonana przez model działający autonomicznie, wykraczająca poza zakres zadania i poza granice środowiska, w którym miał pracować. Nie jest to awaria ani celowy atak zaprogramowany przez człowieka.
Kluczowa cecha opisanych przypadków: nikt nie polecił modelowi wprowadzać ludzi w błąd. Brytyjski instytut odnotował, że wprowadzanie w błąd pojawiło się jako produkt uboczny realizacji zadania, bez konkretnej instrukcji.
To odróżnia te zdarzenia od klasycznego nadużycia narzędzia. Nie mamy tu napastnika posługującego się modelem, tylko model, który realizując zadanie testowe, sięgnął po środki wykraczające poza zamierzony zakres.
Warstwa uprawnień, czyli to, kto i na jakich zasadach nadaje agentowi dostęp, jest osobnym zagadnieniem. Omówiłem ją we wcześniejszym tekście Agenci AI w firmie: produktywność bez nadzoru, a ten artykuł dotyczy tego, co dzieje się po drugiej stronie: u firmy, która o niczym nie wie.
Co dokładnie zrobiły modele w testach Anthropic
Trzy incydenty, trzy różne techniki, wszystkie wymierzone w realne firmy niezwiązane z testem. Anthropic opisał je w komunikacie z 30 lipca 2026 po przejrzeniu 141 006 przebiegów ewaluacyjnych.
Incydent pierwszy. Model Claude Opus 4.7 ustalił rzeczywistą nazwę domeny pewnej firmy, wydobył poświadczenia aplikacyjne i infrastrukturalne oraz uzyskał dostęp do bazy zawierającej kilkaset wierszy danych produkcyjnych.
Incydent drugi. Model Claude Mythos 5 utworzył i opublikował złośliwe oprogramowanie w publicznym repozytorium pakietów PyPI. Pakiet był dostępny około godziny i w tym czasie został pobrany oraz uruchomiony na 15 realnych systemach.
Incydent trzeci. Wewnętrzny model badawczy przeskanował około 9 000 celów i skompromitował jedną firmę technikami elementarnymi: odczytem poświadczeń z odsłoniętej strony diagnostycznej oraz wstrzyknięciem zapytania SQL.
Przyczyną źródłową był błąd konfiguracji między Anthropic a partnerem ewaluacyjnym, firmą Irregular. Maszyny testowe zachowały żywy dostęp do sieci, mimo że polecenia przekazywane modelom mówiły o izolacji. Model działał więc zgodnie z zadaniem; nieprawdziwe było otoczenie, w którym je wykonywał.
Anthropic wstrzymał wszystkie ewaluacje cyberbezpieczeństwa, wprowadził ciągły nadzór nad zapisami przebiegów i zlecił zewnętrzny przegląd zapisów organizacji METR.
Co pokazał raport brytyjskiego instytutu
Dziewiętnaście nieuprawnionych działań w 10 z 122 przebiegów ewaluacyjnych, przy testach prowadzonych na siedmiu modelach. Raport AI Security Institute ukazał się 4 sierpnia 2026.
Odnotowane zachowania układają się w cztery kategorie:
- próba ataku na łańcuch dostaw projektu o otwartym kodzie: model przygotował złośliwe zgłoszenie zmian, a następnie stworzył fikcyjne tożsamości, żeby nakłonić opiekuna projektu do jego zatwierdzenia;
- bezpośrednie próby wprowadzenia realnych osób w błąd, w tym przesyłanie im plików;
- wstrzykiwanie poleceń wymierzone w inne systemy AI;
- koordynacja między agentami: współdzielenie kont, narzędzi i instrukcji.
Instytut podsumował to zdaniem, które warto przeczytać dokładnie: „zachowanie było możliwe, trwałe i nowe; już samo to zasługuje na uwagę”. W innym miejscu raport stwierdza, że po raz pierwszy zaobserwowano ryzyka związane z autonomią i wprowadzaniem w błąd tak wyraźnie, bez konkretnego polecenia, w warunkach rzeczywistych.
Najważniejsze zalecenie brzmi w oryginale: „good containment should not depend on the model choosing not to test its boundaries”. W wolnym przekładzie: skuteczne odizolowanie nie może opierać się na tym, że model sam zrezygnuje ze sprawdzania granic.
Dlaczego dwie ofiary nic nie zauważyły
Ponieważ żaden z zastosowanych sposobów wejścia nie generuje sygnału w miejscu, w którym typowa firma go szuka. To jest sedno tych raportów i część, która przenosi się na organizację niezajmującą się oceną modeli.
Prześledź to po kolei. Odczyt poświadczeń z odsłoniętej strony diagnostycznej nie jest włamaniem w sensie technicznym, tylko pobraniem strony, która sama się wyświetla. Wstrzyknięcie zapytania SQL w aplikacji bez monitoringu zapytań nie zostawia alarmu, tylko wpis w dzienniku, którego nikt nie czyta.
Pobranie pakietu z publicznego repozytorium wygląda z kolei jak zwykła instalacja zależności. Piętnaście systemów, na których uruchomił się złośliwy kod, nie odnotowało zdarzenia nietypowego, bo instalacja pakietu zdarzeniem nietypowym nie jest.
Charakterystyczny jest sposób, w jaki wykryto trzeci przypadek. Zrobiła to firma prowadząca skaner bezpieczeństwa repozytorium, czyli podmiot zewnętrzny obserwujący cudze pakiety, a nie żadna z zaatakowanych organizacji.
Wniosek dla czytelnika jest niewygodny. Brak alarmu nie jest dowodem, że nic się nie stało; jest równie dobrze zgodny z tym, że nie ma czego alarmować.
Czy to dotyczy firmy, która sama modeli nie testuje
Tak, ale w odwróconej roli. Firma na 50 do 500 osób nie prowadzi ewaluacji modeli; jest natomiast po drugiej stronie każdego z trzech opisanych incydentów.
To jej domena zostaje ustalona. To jej strona diagnostyczna zostaje odczytana. To jej zespół instaluje pakiet z publicznego repozytorium i to jej opiekun projektu dostaje zgłoszenie zmian od kogoś, kto może nie istnieć.
Do tego dochodzi kanał, którego w raportach z ewaluacji nie ma, a który obserwują firmy bezpieczeństwa. CrowdStrike podał w raporcie z 3 sierpnia 2026, obejmującym pierwsze półrocze 2026, że jedna kampania przejęcia cudzego dostępu do modeli językowych wygenerowała blisko 200 000 wywołań interfejsu programistycznego w dwie minuty. Ten sam raport odnotowuje, że zgłoszenia wyzwalane przez agentów AI generują 2,5 raza więcej powiadomień o zagrożeniach niż działania uruchamiane ręcznie, co utrudnia odróżnienie zachowania uprawnionego od nadużycia.
Poniższa tabela zestawia cztery kanały wejścia z miejscem, w którym realnie widać ich skutek.
| Rodzaj zdarzenia | Gdzie pojawia się pierwszy ślad | Kto zwykle zauważa | Co trzeba ustawić zawczasu |
|---|---|---|---|
| Przejęcie dostępu do interfejsu modelu | zużycie żetonów i rachunek | dział finansowy albo osoba pilnująca budżetu narzędzia | próg alarmowy na dziennym zużyciu, limit twardy na proces |
| Złośliwy pakiet z publicznego repozytorium | skaner zależności | zespół wytwórczy, o ile skaner działa | blokada instalacji nowych pakietów bez przeglądu |
| Odczyt poświadczeń z odsłoniętej strony diagnostycznej | brak własnego sygnału | zwykle nikt | wyłączenie stron diagnostycznych w środowisku produkcyjnym |
| Zgłoszenie zmian od fikcyjnej tożsamości | proces przeglądu kodu | recenzent, o ile przegląd jest obowiązkowy | wymóg przeglądu przez człowieka przy każdej zmianie z zewnątrz |
Pierwszy wiersz zasługuje na uwagę osobną. Zużycie modelu jest pozycją kosztową, więc anomalia pojawia się w rachunku wcześniej niż w jakimkolwiek narzędziu bezpieczeństwa. Mechanizm kontroli kosztu zużycia opisałem w tekście Ile kosztuje używanie AI? Paradoks Jevonsa w praktyce firm; te same twarde limity wydatków, które chronią budżet przed wzrostem uprawnionym, są jednocześnie jedynym prostym mechanizmem wykrywającym zużycie nieuprawnione.
Czego te raporty nie dowodzą
Trzy zastrzeżenia, każde na tyle mocne, że pominięcie któregokolwiek zmienia wymowę całości w stronę nieuprawnioną.
To nie były ucieczki modeli w sensie, jaki sugerują nagłówki. U Anthropic zawiodła konfiguracja po stronie ludzi. W testach brytyjskiego instytutu dostęp do sieci był celowy, a klasyfikatory bezpieczeństwa dostawców zostały świadomie wyłączone, żeby zbadać zachowanie modelu bez zabezpieczeń. Drzwi zostawiono otwarte umyślnie.
Nie stwierdzono realnej szkody. Brytyjski instytut pisze wprost, że dochodzenie nie wykazało szkody wynikającej z tych działań, a najpoważniejsza próba, czyli złośliwe zgłoszenie zmian, została odrzucona przez ludzkich recenzentów. Przegląd kodu przez człowieka zadziałał dokładnie tak, jak powinien.
Instytut kieruje zalecenia głównie do siebie. Raport odnotowuje, że zdarzenie miało miejsce w kontrolowanej ewaluacji, a nie w zwykłym użyciu, a trzy zapowiedziane zmiany dotyczą jego własnych poligonów testowych: precyzyjnej kontroli sieci, nadzoru w czasie rzeczywistym i przeprojektowania ewaluacji.
Uczciwe podsumowanie tych zastrzeżeń brzmi tak: to nie jest dowód, że agenty wyrywają się na wolność. To jest dowód, że przy otwartym dostępie i wyłączonych zabezpieczeniach zachowanie tego rodzaju występuje, jest trwałe i nie wymaga polecenia. Dyrektor techniczny brytyjskiego NCSC skomentował to zdaniem, że poleganie wyłącznie na wykryciu po fakcie nie wystarczy (za Help Net Security, 5 sierpnia 2026).
Kluczowe pytania i decyzje
Czy powinienem wstrzymać wdrożenia agentów w firmie?
Nie, jeśli agenty pracują na kontach o wąskim zakresie uprawnień, a ich działania trafiają do dziennika, który ktoś przegląda.
Tak, do czasu ustawienia obu tych rzeczy, jeśli agent działa dziś na poświadczeniach człowieka i nikt nie potrafi odtworzyć, co zrobił w zeszłym tygodniu.
Czy powinienem traktować limit wydatków jako mechanizm bezpieczeństwa?
Tak, jeśli korzystasz z modeli przez interfejs programistyczny rozliczany za zużycie. Twardy limit dzienny ogranicza wtedy nie tylko rachunek, lecz również skalę ewentualnego nadużycia.
Nie polegaj wyłącznie na nim. Limit ograniczy szkodę kosztową i może posłużyć jako sygnał, ale nie zatrzyma działań, które nie generują nietypowego zużycia.
Czy powinienem zmienić zasady instalowania pakietów?
Tak, jeśli zespół może dziś dodać nową zależność bez przeglądu. Incydent z PyPI pokazuje, że okno około godziny wystarczyło, żeby pakiet trafił na 15 systemów.
Nie zaczynaj od zakazu, bo zablokuje pracę. Zacznij od skanera zależności i od wymogu przeglądu przy pakietach nowych, a nie przy każdej aktualizacji.
Kiedy ta analiza się nie sprawdzi
Gdy okaże się, że opisane zdarzenia były wyłącznie skutkiem jednego błędu konfiguracji. Anthropic wskazał konkretną przyczynę po stronie partnera ewaluacyjnego. Jeśli kolejne miesiące nie przyniosą przypadków o innym mechanizmie, właściwym wnioskiem będzie „popraw konfigurację”, a nie „zmień model zagrożeń”.
Gdy twoja organizacja nie korzysta z modeli rozliczanych za zużycie ani nie wytwarza oprogramowania. Wtedy dwa z czterech kanałów z tabeli po prostu nie występują, a ekspozycja jest istotnie mniejsza niż sugeruje ten tekst.
Gdy dostawcy wprowadzą nadzór w czasie rzeczywistym po swojej stronie. Zarówno Anthropic, jak i brytyjski instytut zapowiedziały takie zmiany. Jeśli okażą się skuteczne, ryzyko przesunie się z ewaluacji na wdrożenia produkcyjne, czyli w inne miejsce, niż opisuje ta analiza.
Gdy liczby okażą się nieporównywalne. Anthropic przejrzał 141 006 przebiegów i znalazł 3 incydenty; brytyjski instytut przy 122 przebiegach odnotował 19 działań. Te dwa zbiory powstały w innych warunkach, więc zestawianie ich wskaźników byłoby nadużyciem i tekst tego nie robi.
Podsumowanie
Dwa raporty z przełomu lipca i sierpnia 2026 dokumentują coś, czego wcześniej nie było w materiale publicznym: agenty AI podejmujące wobec realnych, postronnych organizacji działania wykraczające poza zadanie, bez polecenia w tym kierunku. Warunki były sztuczne, bo w jednym przypadku zawiodła konfiguracja, a w drugim zabezpieczenia wyłączono celowo, i tej okoliczności nie można pomijać.
Dla firmy spoza świata ewaluacji modeli najbardziej użyteczna jest jednak nie ocena samego zjawiska, lecz jego strona odbiorcza. Trzy zaatakowane organizacje nie prowadziły żadnych testów. Dwie z nich dowiedziały się o zdarzeniu od dostawcy modelu, a nie z własnych systemów.
Praktyczne pytanie do zadania u siebie nie brzmi więc „czy agent AI może mnie zaatakować”, bo na to pytanie nie da się odpowiedzieć z góry. Brzmi: gdyby ktoś przepuścił przez nasz dostęp dwieście tysięcy wywołań albo zainstalował u nas pakiet, którego nikt nie przeglądał, to w którym miejscu i po jakim czasie ktokolwiek by to zobaczył. Odpowiedź na to pytanie firma może ustalić sama, bez czekania na kolejny raport.
O autorze
Remigiusz Pruszczak: ekspert GenAI i trener AI. Od 17 lat prowadzi szkolenia, a od 2025 roku również z generatywnej AI, między innymi dla banków, instytucji finansowych, kancelarii oraz firm z sektorów regulowanych i produkcji. Szkolenia realizuje we współpracy z EY Academy of Business Polska, Warszawskim Instytutem Bankowości, Bankowym Ośrodkiem Doradztwa i Edukacji oraz CFA Society Poland. Więcej na stronie „O mnie”.
Źródła
- Anthropic, Investigating three real-world incidents in our cybersecurity evaluations, 30 lipca 2026: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
- UK AI Security Institute, Incident Report: unsanctioned agent behaviour during cyber testing, 4 sierpnia 2026: https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing
- CrowdStrike, 2026 Threat Hunting Report, 3 sierpnia 2026 (dane za styczeń do czerwca 2026): https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-threat-hunting-report/
- Help Net Security, AI agent deception moves from theory to reality in UK cyber tests, 5 sierpnia 2026: https://www.helpnetsecurity.com/2026/08/05/ai-agent-deception-in-cyber-tests/
