SAFE ma uczyć branżę na incydentach agentów AI. Na razie to projekt RFC

Branża AI chce uczyć się nie tylko na podatnościach, ale też na incydentach i zdarzeniach, które niemal zakończyły się szkodą. Taki jest cel Shared AI Findings Exchange (SAFE) — propozycji poufnego systemu zgłaszania, analizy i przekładania błędów agentów AI na wspólne zabezpieczenia. Projekt opublikowano 4 sierpnia 2026 r. jako Request for Comments. To ważne zastrzeżenie: SAFE nie jest jeszcze gotowym standardem, działającą instytucją ani produktem jednego dostawcy.

Propozycja powstała w środowisku Open Secure AI Alliance. Według Linux Foundation początkowy projekt przygotowali współtwórcy z Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat i innych organizacji sojuszu. Dokument próbuje wypełnić lukę między klasycznym zgłoszeniem podatności a pełnym incydentem operacyjnym, w którym model, narzędzia, uprawnienia, środowisko i człowiek tworzą jeden łańcuch przyczyn.

Dlaczego zwykły raport podatności może nie wystarczyć

Klasyczny program CVE porządkuje publicznie ujawnione podatności. Każdy rekord identyfikuje konkretną lukę, dzięki czemu producenci, administratorzy i narzędzia mogą mówić o tym samym problemie. To fundament zarządzania podatnościami, ale nie opisuje automatycznie całego przebiegu incydentu z agentem AI.

Agent może wykonać serię poprawnych technicznie operacji, które razem prowadzą poza zatwierdzony zakres. Przyczyną nie musi być jedna luka w kodzie. Problem może powstać z połączenia niejasnej instrukcji, zbyt szerokich poświadczeń, braku izolacji sieciowej, niepełnego monitoringu i błędnego przekonania operatora, że cel jest środowiskiem testowym. AIOAI.pl wyjaśnia podstawy takich systemów w haśle agenci AI, a praktyczny kontekst ofensywny pokazuje analiza, jak AI znalazła krytyczną lukę w WordPressie.

Projekt RFC SAFE koncentruje się właśnie na tej warstwie operacyjnej. Proponuje analizować nie tylko rezultat, lecz także model, instrukcje, zabezpieczenia, narzędzia, środowisko, monitoring, decyzje ludzi i zależności w łańcuchu dostaw.

Co miałoby podlegać zgłoszeniu

Projektowy „Reporting Compact” zakłada, że przyszli członkowie SAFE zgłaszaliby zdarzenie, gdy system AI, którym operują, bez upoważnienia uzyska dostęp do systemu strony trzeciej, wykorzysta go, zakłóci, zmodyfikuje albo użyje niezgodnie z zakresem. Raport miałby być wymagany również wtedy, gdy agent ominie granicę sandboxa, sieci, tożsamości, polityki lub narzędzia i wywoła skutek u strony trzeciej.

Zakres obejmuje też dostęp do cudzych poufnych danych bez zgody oraz kontynuowanie prób, dostępu lub modyfikacji celu produkcyjnego, kiedy operator wie albo ma uzasadnione podejrzenie, że działanie jest nieautoryzowane. RFC podkreśla, że intencja nie rozstrzyga o obowiązku raportowania. Przekonanie, że środowisko było symulacją, może wyjaśnić błąd, ale nie usuwa jego skutków.

To ambitny próg. SAFE nie ograniczałoby się do „udanych ataków”. Projekt nakazuje uwzględniać także near missy. Takie dane są cenne, bo pokazują słabą kontrolę zanim podobne zdarzenie spowoduje realną szkodę, ale jednocześnie są trudne do raportowania: firmy mogą obawiać się odpowiedzialności, utraty reputacji lub ujawnienia metod obronnych.

Projektowane terminy powiadomień

RFC proponuje konkretny rytm działań. Nie jest to dziś wiążący harmonogram prawny, lecz punkt wyjścia do dyskusji nad przyszłym mechanizmem.

Autorzy projektu zastrzegają, że te terminy nie zastępują obowiązków dostawcy wobec poszkodowanych, klientów, regulatorów czy organów ścigania. Mają też współistnieć z praktykami Coordinated Vulnerability Disclosure. To konieczne, ponieważ ten sam incydent może uruchamiać kilka różnych ścieżek prawnych i kontraktowych w różnych państwach.

Od promptu do pełnej osi zdarzeń

Najbardziej praktyczna część RFC dotyczy materiału dowodowego. Organizacja miałaby zachować prompty, ślady wykonania, wywołania narzędzi, logi, konfiguracje, wersje modelu i zabezpieczeń oraz zależności zewnętrzne. Do tego dochodzą tożsamości agenta i workloadu, dostępne uprawnienia i poświadczenia, akceptacje człowieka, zmodyfikowane pliki, momenty wykrycia i ograniczenia incydentu oraz pełna oś czasu.

Taki zestaw pozwala rozdzielić symptom od przyczyny. Jeśli agent opublikował poufny plik, sam wynik nie odpowie, czy zawiódł model, polityka narzędzia, limit uprawnień, monitoring czy ręczna akceptacja. SAFE zakłada przegląd każdej z tych warstw i przygotowanie rekomendacji, które zawierają wymagany rezultat obronny, minimalną kontrolę, alternatywy, powtarzalną metodę weryfikacji, właściciela oraz termin wdrożenia.

W miarę możliwości zalecenia miałyby przyjmować postać ponownie używalnych testów, polityk maszynowych, reguł detekcji, konfiguracji referencyjnych i instrukcji reagowania. To odróżnia projekt od samego archiwum opisów incydentów. Ambicją jest zamiana zdarzenia w kontrolę, którą inna organizacja może wdrożyć i sprawdzić.

Trzy poziomy ujawnienia zamiast natychmiastowej publikacji

Projekt przewiduje trzy etapy. Najpierw zaufani uczestnicy otrzymywaliby poufny szybki alert z oznakami incydentu, sposobami ograniczenia szkody i wzorcami zagrożenia. Później pojawiałoby się zanonimizowane zalecenie operacyjne dla członków. Dopiero trzeci poziom byłby publicznym raportem z przyczynami źródłowymi, wnioskami, rekomendacjami i — docelowo — danymi o wdrożeniu zabezpieczeń.

Ta kolejność ma ułatwić szczere raportowanie bez przedwczesnego ujawniania danych, które pomogłyby atakującym. Jednocześnie RFC nie daje jeszcze gotowej odpowiedzi, kto będzie decydował o anonimizacji, wyjątkach i momencie publikacji. Poszkodowana organizacja mogłaby poprawiać błędy faktograficzne, lecz według projektu nie powinna mieć prawa weta wobec wniosków i rekomendacji.

SAFE, CVE i skoordynowane ujawnianie podatności

CVE Program kataloguje publicznie ujawnione podatności. SAFE ma szerszy zakres: może dotyczyć zdarzenia, które nie wynika z jednej podatności produktu albo nawet nie doprowadziło do szkody. Dlatego rozsądniej traktować te mechanizmy jako uzupełniające się, a nie konkurencyjne.

Sam pomysł uczenia się na near missach również nie zaczyna się od SAFE. NIST AI RMF Playbook rekomenduje utrzymywanie bazy zgłoszonych błędów, zdarzeń potencjalnie wypadkowych, incydentów i negatywnych skutków. SAFE próbuje przenieść podobną logikę z poziomu pojedynczej organizacji do współdzielonego procesu branżowego.

Największe niewiadome: governance, poufność i skuteczność

Linux Foundation opisuje SAFE jako propozycję niezależnej grupy roboczej. Dokument wymienia dostawców modeli, firmy wdrażające AI, chmury, operatorów infrastruktury krytycznej, badaczy, organizacje społeczne i obserwatorów rządowych. Nie wskazuje jednak gotowego operatora procesu, modelu finansowania, składu organu decyzyjnego ani trybu rozwiązywania konfliktów.

Drugi problem to zachęty. Organizacja ma przekazać bardzo wrażliwe dane o poświadczeniach, błędach kontroli i przebiegu ataku, a jednocześnie zachować obowiązki wobec klientów i regulatorów. Bez jasnych reguł ochrony informacji, dostępu do dowodów i publikacji uczestnicy mogą zgłaszać tylko najbezpieczniejsze przypadki. Z kolei zbyt szeroka poufność osłabi wartość dla poszkodowanych i społeczności.

Trzecia niewiadoma dotyczy wyników. Nie ma jeszcze danych pokazujących, że SAFE skraca czas wykrywania, zmniejsza liczbę podobnych incydentów albo prowadzi do wdrażania zaleceń. NVIDIA jako uczestnik inicjatywy opisuje potencjalne korzyści, ale taki komunikat nie jest niezależnym pomiarem skuteczności. Projekt trzeba oceniać po przyszłej adopcji, jakości raportów i sprawdzalności kontroli.

Co zespoły mogą zrobić już teraz

Firma nie musi czekać na finalizację SAFE, aby poprawić własną gotowość. Pierwszym krokiem jest ustalenie, czy potrafi odtworzyć pełne działanie agenta: wejściowy prompt, decyzje modelu, narzędzia, tożsamość, uprawnienia, zasoby sieciowe, interwencje człowieka i wynik. Jeśli dowody są rozproszone albo szybko znikają, wspólne raportowanie nie będzie możliwe.

Drugim krokiem jest wspólna definicja incydentu i near missu. Zespół powinien z góry ustalić, kiedy agent przekracza zakres, kto może go zatrzymać, kogo trzeba powiadomić i jak zabezpieczyć dowody. Przydatny kontekst stanowi opis programu OpenAI Patch the Planet i cyberobrony z użyciem modeli AI, bo pokazuje, jak szybko narzędzia agentowe wchodzą w realne procesy bezpieczeństwa.

Trzecim krokiem jest przekładanie incydentów na testy regresji. Po zdarzeniu nie wystarczy dodać reguły do dokumentacji. Trzeba przygotować odtwarzalny scenariusz, uruchamiać go po zmianie modelu, promptu, narzędzia lub polityki i przechowywać dowód, że kontrola nadal działa. To dokładnie ten element, na którym SAFE może zyskać największą praktyczną wartość.

Czy SAFE ma szansę stać się branżowym standardem?

Na razie byłoby za wcześnie, by tak je nazywać. Publiczny dokument jest szkicem, a repozytorium nadal zbiera uwagi dotyczące formatu dowodów, identyfikacji systemów AI i sposobów weryfikacji. Zaletą projektu jest konkretny punkt startowy: zdarzenia raportowalne, terminy, zakres dowodów, warstwy analizy i trzy poziomy ujawnienia są opisane na tyle szczegółowo, aby społeczność mogła je krytykować i poprawiać.

Najważniejsza zmiana myślenia polega na potraktowaniu incydentu z agentem jako awarii całego systemu, a nie tylko błędu modelu. Jeśli SAFE zachowa neutralność, stworzy wiarygodne zasady poufności i będzie publikować kontrole możliwe do niezależnego sprawdzenia, może uzupełnić CVE i CVD o brakującą warstwę operacyjnego uczenia się. Jeśli pozostanie zbiorem ogólnych deklaracji bez mechanizmu egzekwowania jakości, jego wpływ będzie ograniczony.