Archiwum incydentów Orca AI: 354 prawdziwe incydenty agentów AI, każdy z dowodem

Zespół ds. bezpieczeństwa potrafi precyzyjnie powiedzieć, jak dobrze model opiera się prompt injection w środowisku testowym. Prawie nikt nie potrafi natomiast powiedzieć, ile organizacji zostało faktycznie naruszonych przez agenta w zeszłym miesiącu, które z tych naruszeń miały potwierdzoną ofiarę ani które z liczb przytoczonych w opracowaniu pochodziły od dostawcy, a nie od regulatora. Ta luka — między tym, co modele mogłyby zrobić, a tym, co już się wydarzyło — to luka, którą a href="https://www.orcarouter.ai/incident-archive">Orca AI Incident Archive/a> powstało, by zamknąć. Wystartowało 23 września 2026 r. i na dzień 22 września, czyli datę odcięcia danych, zawiera 354 rekordy pochodzące z 593 unikalnych źródeł.

Uwaga dotycząca dokładności: każda liczba poniżej pochodzi z opublikowanego przez samo archiwumcode>dist/stats.json/code> w wersji 2026-09-22 oraz ze strony na żywo. Ogłoszenie o uruchomieniu z 23 września podawało 340 rekordów, 548 źródeł i 126 z potwierdzoną szkodą; były to liczby z chwili publikacji, a archiwum jest aktualizowane na bieżąco, więc oba zestawy różnią się o mniej więcej dobę napływu danych. Jeśli w trakcie prac jego README i strona na żywo nie zgadzały się co do liczby na plakietce, to właśnie stronie na żywo i eksportowi JSON należy ufać.

Co archiwum faktycznie zawiera

To nie jest kanał informacyjny ani lista CVE. Każdy wpis to pojedynczy plik Markdown z ustrukturyzowanym frontmatterem, przypisany do miesiąca, w którym miało miejsce zdarzenie, a każdy wpis zawiera co najmniej jedno źródło. Zbiór danych jest publikowany na licencji CC BY 4.0 i zmirrorowany w publicznym repozytorium, więc całość można sklonować, porównać za pomocą diffa i zacytować, zamiast robić zrzuty ekranu.

Okno pokrycia obejmuje 22 miesiące, od prekursora z grudnia 2024 do 22 września 2026, a najciekawsza jest jego dystrybucja. Ważność rozkłada się następująco: 45 krytycznych, 139 wysokich, 77 średnich, 8 niskich i 85 informacyjnych. Wiarygodność źródeł rozkłada się następująco: 302 oceny A, 47 ocen B, 2 oceny C i 3 oceny D. Potwierdzone szkody w świecie rzeczywistym odnotowano dla 127 rekordów, wyraźnie wykluczono dla 142, a dla 85 pozostawiono wartość pustą.

Te trzy ostatnie liczby są powodem, dla którego archiwum warto czytać uważnie, a nie tylko przeglądać pobieżnie. Liczba 354 rekordów to nie liczba 354 incydentów. Tylko 138 z nich w ogóle sklasyfikowano jako incydent; pozostałe to ujawnienia luk w zabezpieczeniach, demonstracje badawcze, raporty o zagrożeniach i działania polityczne. Liczenie wszystkich pięciu razem to dokładnie sposób, w jaki liczba z nagłówka staje się błędna, dlatego archiwum trzyma je osobno i pozwala filtrować.

Dlaczego „jailbreak nie jest incydentem” to sedno sprawy

Większość zbiorów zdarzeń dotyczących bezpieczeństwa AI zaciera jedną różnicę: agent, który faktycznie wyrządził szkodę, to nie to samo co badacz pokazujący, że mógłby ją wyrządzić. To właśnie to jedno utożsamienie zamienia konferencyjne demo w nagłówek o naruszeniu — i temu archiwum ma odmawiać.

Trzy pola dźwigają ten ciężar. code>real_harm/code> rejestruje, czy ofiara została potwierdzona. code>ai_involvement/code> rejestruje, czy pierwotne źródło — dostawca, ofiara, organy ścigania lub oficjalny raport — potwierdziło rolę AI, a sporne przypisania pozostają w zbiorze danych, lecz są oznaczone. code>kind/code> rejestruje, jakiego rodzaju dokumentem jest dany wpis. Wpis bez źródła nie trafia do zbioru. Wpis ze sprzecznymi dowodami zostaje oznaczony jako sporny, a nie rozstrzygnięty w tym kierunku, który czyta się lepiej. Gdy pojawią się nowe dowody, wpis jest aktualizowany, a zmiana zostaje zapisana w jego historii zmian, a nie po cichu nadpisana.

Archiwum zastosowało tę zasadę do samego siebie. Podczas własnych rund weryfikacyjnych usunęło dwa wpisy, których nie dało się potwierdzić, poprawiło szeroko powtarzane twierdzenie o tym, jak szybko postępowało jedno włamanie, oraz obniżyło ocenę wiarygodności trzeciego wpisu, gdy okazało się, że leżące u jego podstaw dowody pochodzą z drugiej ręki. Baza danych o incydentach, która nigdy niczego nie usunęła, to baza danych, której nie sprawdzono.

Dwanaście powierzchni ataku, według których sortuje

Każdy rekord jest oznaczony jednym lub więcej z dwunastu typów, a każdy typ ma własny miesięczny licznik. Zarządzanie i polityka to największa kategoria z 65 rekordami, ale tylko jeden z nich ma potwierdzoną szkodę — co jest właściwym kształtem działań regulacyjnych i mylącym, gdy podaje się go jako liczbę incydentów. Nadużycie poświadczeń następuje dalej z 55, z 40 potwierdzonymi ofiarami, najwyższą gęstością szkód w zestawie. Agent jako broń plasuje się na 51 z 28 potwierdzonymi. Pośrednia injekcja promptów ma 45 rekordów, ale tylko 5 z potwierdzoną szkodą, co jest najjaśniejszą ilustracją rozdźwięku między możliwościami a konsekwencjami w całym zbiorze danych: to najlepiej przebadana klasa ataków i jedna z najmniej produktywnych w rzeczywistych warunkach. Zatrucie łańcucha dostaw, z 36 rekordami, ma 27 potwierdzonych ofiar — najgorszy stosunek w zestawieniu.

Wrzesień 2026 to miesiąc, który przesądza sprawę.

Samych wpisów we wrześniu 2026 roku było pięćdziesiąt jeden — ponad dwukrotnie więcej niż w jakimkolwiek wcześniejszym miesiącu w analizowanym oknie czasowym. To nie nagłe załamanie bezpieczeństwa. To miesiąc, w którym prowadzenie rejestru wreszcie dogoniło rok nagromadzonych zdarzeń, a liczy się właśnie jego skład: wpisy krytyczne dotyczące złośliwego code>.git/config/code>, który wykonuje kod atakującego w siedmiu agentach kodujących, zanim jeszcze dojdzie do kontaktu z modelem, luki w Langflow wykorzystywanej w rzeczywistych atakach, kampanii roju agentów AI u dostawcy rozwiązań do zarządzania drukiem oraz robaka npm, który wchodzi do łańcucha na wcześniejszym etapie. Obok nich znajdują się wpisy informacyjne o OWASP Agent Control Standard, orędziu o stanie Unii wygłoszonym w UE, w którym wymieniono ucieczki agentów, oraz briefie panelu ONZ, w którym jedno zdarzenie potraktowano jako ostrzeżenie przed utratą kontroli.

Koreańskie wpisy i czego nie oznacza pole regionu

w archiwumcode>region/code> wskazuje, gdzie zdarzenie faktycznie miało miejsce, a nie gdzie mieści się siedziba dostawcy — transgraniczne ujawnienia dostawców są zawsze zgłaszane jako globalne, dlatego 291 z 354 rekordów nie ma znacznika pojedynczego kraju. Dwa rekordy mają znacznik KR, oba to wpisy dotyczące polityki, oparte na źródłach klasy A i bez potwierdzonych szkód: usunięcie DeepSeek z krajowych sklepów z aplikacjami w Korei Południowej w kwietniu 2025 r. oraz ogólnofirmowy zakaz korzystania z OpenClaw przyjęty przez Naver, Kakao i Karrot w lutym 2026 r.

Ta powściągliwość jest zamierzona. Liczba dwóch zdarzeń w regionie nie oznacza, że Korea miała dwa incydenty bezpieczeństwa AI. Oznacza, że dwa zdarzenia w tym oknie trafiły do Korei z pierwotnym źródłem wystarczająco mocnym, by je zgłosić — a archiwum woli opublikować małą, uczciwą liczbę niż wypełniać stronę kraju zdarzeniami, które przydarzyły się klientom koreańskiej firmy gdzie indziej.

Jak odczytywać oceny pewności, zanim którąś zacytujesz

Pewność dotyczy jakości źródła, a nie wagi zdarzenia, a ocena D nie oznacza fałszu — oznacza, że strony się nie zgadzają i nie należy cytować tylko jednej z nich. Ocena A oznacza źródło pierwotne: dostawcę, ofiarę, organy ścigania lub oficjalny raport. Ocena B oznacza laboratorium badawcze lub duże medium ze szczegółami możliwymi do sprawdzenia. Ocena C oznacza wyłącznie źródło z drugiej ręki. Ocena D oznacza, że fakty lub przypisanie są sporne. Przy 302 z 354 rekordów ocena A stanowi 85% zbioru danych, co jest niezwykle wysokim odsetkiem jak na raportowanie incydentów i jest bezpośrednim skutkiem zasady „brak źródła — brak wpisu”.

Uczciwe zastrzeżenia warto przedstawić wprost, ponieważ archiwum je podaje. Dwa rekordy pozostają w klasie C, a trzy w klasie D. Osiemdziesiąt pięć rekordów ma ważność informacyjną, ponieważ są to wpisy dotyczące polityk lub raportów o zagrożeniach, zachowane dla ciągłości osi czasu, a nie incydenty. Repozytorium ma trzy tygodnie i nie ma gwiazdek, wydań ani zewnętrznego audytu własnej metodologii — to publicznie opublikowany zbiór danych, a nie recenzowane badanie.

Dlaczego to ma większe znaczenie niż kolejny benchmark

Gdy agenci uzyskują przeglądarki, powłoki, poświadczenia, możliwość wykonywania kodu i dostęp produkcyjny, pytanie o bezpieczeństwo przestaje dotyczyć tego, do czego zdolny jest model, a zaczyna dotyczyć tego, co już z nim zrobiono. Benchmarki dobrze odpowiadają na pierwsze pytanie, a na drugie nie odpowiadają wcale. Archiwum incydentów, oceniane według jakości źródeł i filtrowane ze względu na to, czy komukolwiek wyrządzono rzeczywistą szkodę, to jedyny rodzaj instrumentu, który odpowiada na drugie pytanie — i działa tylko wtedy, gdy wpisy można prześledzić, poprawić i swobodnie ponownie wykorzystać.

To jest to, co jest teraz otwarte. Zbiór danych znajduje się pod adresem a href="https://www.orcarouter.ai/incident-archive">orcarouter.ai/incident-archive/a>, surowy Markdown, eksporty JSON i CSV oraz schemat znajdują się w a href="https://github.com/Continuum-AI-Corp/Orca-AI-Incident-Archive">publicznym repozytorium/a>, a poprawki przechodzą przez historię zmian rekordu. Jeśli znasz wydarzenie, które powinno się w nim znaleźć, ścieżka kontrybucji to jeden plik Markdown i co najmniej jedno źródło. Bez źródła nie ma wpisu.

OrcaRouter, który publikuje to archiwum, obsługuje pojedynczy endpoint zgodny z OpenAI dla ponad 200 modeli, bez marży na ceny dostawców i z automatycznym przełączaniem awaryjnym między nimi — ta sama warstwa routingu, dzięki której można wskazać agentowi tańszy model do łatwych wywołań, a mocniejszy do trudnych, czyli dokładnie ta architektura, w której wykryto większość powyższych incydentów.