Incydenty AI: playbook reagowania dla systemów LLM
Incydenty AI wymagają innych dowodów niż klasyczne włamania. Przygotuj playbook dla prompt injection, wycieków, zatruć i nadużyć agentów.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 1 lipca 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Bezpieczeństwo AI
Incydenty AI obejmują nie tylko kompromitację infrastruktury. System może ujawnić dane przez prompt injection, wykonać nieautoryzowane działanie narzędziem, wykorzystać zatruty dokument RAG, generować szkodliwe treści albo nagle zmienić zachowanie po aktualizacji modelu.
Klasyczny proces reagowania nadal obowiązuje, ale wymaga nowych artefaktów, ownerów i możliwości odtworzenia decyzji modelu.
Zdefiniuj, co jest incydentem
Ustal progi dla poufności, integralności, dostępności, bezpieczeństwa użytkownika i zgodności. Pojedyncza halucynacja może być błędem jakości, ale systematyczna odpowiedź prowadząca do szkody powinna uruchomić procedurę.
Przykładowe klasy:
- ujawnienie danych lub promptu systemowego;
- wykonanie działania bez prawidłowej autoryzacji;
- zatrucie zbioru, indeksu lub pamięci agenta;
- obejście zabezpieczeń i nadużycie modelu;
- kompromitacja dostawcy, klucza API lub pluginu;
- niebezpieczny drift jakości albo zachowania.
Każda klasa potrzebuje severity, ownera i kanału eskalacji.
Telemetria potrzebna do dochodzenia
Zapisuj identyfikator żądania, wersję modelu, szablon promptu, wersje guardrails, źródła RAG, wywołania narzędzi, decyzje polityk i wynik filtrów. Stosuj pseudonimizację, kontrolę dostępu i retencję — log nie może kopiować wszystkich danych użytkownika bez ograniczeń.
W przypadku modelu zewnętrznego zapisz region, wersję endpointu i identyfikator odpowiedzi dostawcy. Bez tego późniejsze odtworzenie wyniku może być niemożliwe.
Ograniczenie skutków
Przygotuj przełączniki pozwalające wyłączyć konkretne narzędzie, źródło RAG, pamięć, automatyczne wykonywanie albo cały model. Zmniejszenie autonomii jest często bezpieczniejsze niż całkowite wyłączenie usługi.
Rotuj skompromitowane klucze, blokuj dokumenty, zamrażaj wersję modelu i ogranicz role kont usługowych. Zachowaj dowody przed przebudową indeksu lub usunięciem pamięci.
Analiza przyczyny
Oddziel błąd modelu od błędu architektury. Prompt injection staje się incydentem o dużym wpływie wtedy, gdy system pozwala niezaufanej treści wywołać uprzywilejowane narzędzie bez niezależnej autoryzacji.
Analizuj pełny łańcuch: źródło danych, retrieval, prompt, model, parser, politykę narzędzia i efekt w systemie docelowym. Wykorzystaj model zagrożeń AI, aby znaleźć podobne ścieżki.
Odzyskanie i test regresji
Poprawkę weryfikuj na zapisanym przypadku oraz wariantach: innym języku, kodowaniu, pliku i kolejności narzędzi. Dodaj scenariusz do zestawu ewaluacji. Monitoruj wzrost odmów i false positives, bo zbyt szeroka blokada może zniszczyć funkcję produktu.
Po incydencie aktualizuj klasyfikację danych, uprawnienia, runbook dostawcy i kryteria wdrożenia. Plan powinien łączyć się z ogólnym incident response, komunikacją prawną i ochroną danych.
Minimalna karta playbooka
- Klasa incydentu i poziom wpływu.
- Źródła telemetrii oraz wymagane dowody.
- Owner techniczny, biznesowy, prawny i dostawca.
- Bezpieczne przełączniki ograniczające autonomię.
- Procedura ochrony danych i rotacji sekretów.
- Test odtworzenia, poprawki i regresji.
- Kryteria powrotu do normalnego działania.
Gotowość do incydentu AI nie polega na zapisaniu wszystkich promptów. Polega na zdolności szybkiego ograniczenia skutku, zachowania właściwych dowodów i udowodnienia, że ta sama ścieżka została zamknięta.
Artefakty potrzebne do rekonstrukcji
Zachowuj wersję modelu, prompt systemowy, konfigurację narzędzi, identyfikatory pobranych dokumentów, decyzje polityk, wynik i działania wykonane w systemach zewnętrznych. Dane muszą mieć wspólny czas i identyfikator żądania. Loguj tyle, ile potrzeba do bezpieczeństwa, ale maskuj sekrety i stosuj ustaloną retencję.
Containment zależy od warstwy: można wyłączyć narzędzie, cofnąć token agenta, zamrozić wersję modelu, odłączyć źródło RAG albo skierować ruch do bezpiecznego trybu. Nie usuwaj od razu indeksu czy rozmów, jeśli są dowodem. Po naprawie odtwórz przypadek na kopii, dodaj go do zestawu ewaluacyjnego i sprawdź, czy kontrola nie blokuje prawidłowych zadań.
Źródła: NIST GenAI Profile, NIST SP 800-61 Rev. 3, OWASP LLM Top 10.


