QAtration wysyła prawdziwe ataki prompt injection na twojego bota AI i zwykłym językiem raportuje, co ujawnił albo zrobił, zanim znajdzie to ktoś inny. Uruchamiasz to ty. Na twojej maszynie albo w twoim CI, przeciwko twojemu wdrożeniu: bez konta, bez przekazywania endpointu, nic nie jest wysyłane do nas.
Nie kieruj tego na system, który nie należy do ciebie. Wysyła prawdziwe ataki (prompt injection, eksfiltracja danych, nadużycie narzędzi) na dowolny URL, który mu podasz. Twoje własne wdrożenie albo takie, którego właściciel z góry dał ci pisemną zgodę. Nie publiczny chatbot, który wydał ci się ciekawy. Nie demo dostawcy. Przeczytaj AUTHORISED-USE.md przed pierwszym uruchomieniem.
Dwie zależności. Cały korpus ataków jest dołączony, a razem z nim dowody stojące za każdą liczbą na tej stronie, wszystko w
out/, który jest dostarczany razem z repozytorium. Własnych raportów dwóch pozostałych narzędzi tu nie ma, bo nie pozwalają na to ich licencje. Polecenia, które je odtwarzają, są.
Zmierzone na naszych własnych celach testowych, nie oszacowane. Transkrypcja obok ilustruje samą ideę, liczby powyżej to wyniki.
Każda funkcja AI, która trafia na produkcję, to nowa powierzchnia ataku. Ile z twojej zdoła dosięgnąć to narzędzie, zależy od tego, co pozwala mu zobaczyć twoje wdrożenie, a granicę wyznaczamy tutaj zamiast ją zamazywać, bo skaner twierdzący, że pokrywa to, czego nie może obserwować, jest dokładnie tym, czego próbujesz uniknąć.
Wystarczy endpoint czatu: to testuje się tak jak jest, również w kilku turach rozmowy.
Tekst atakującego nadpisuje reguły twojego bota: „zignoruj swoje instrukcje i…”.
Twój bot ujawnia klucze API, wewnętrzne kody albo dane innego klienta.
Twoje ukryte instrukcje wyciekają dosłownie: mapa dla każdego kolejnego ataku.
Reguła podłożona w jednej turze po cichu zmienia każdą kolejną odpowiedź, długo po tym, jak rozmowa znów zaczęła wyglądać normalnie.
Nie podłożysz dokumentu w bazie wiedzy, do której nie masz prawa zapisu, a z zewnątrz nie odróżnisz wywołania narzędzia, które naprawdę się wykonało, od takiego, które bot tylko opisał, a zmierzyliśmy, że boty mylą się co do samych siebie właśnie w tym rozróżnieniu. Do tego potrzebne są korpus, definicje narzędzi albo wgląd w wywołania. Zmierzone na dowodach dostarczanych z tym narzędziem: 62 ze 137 ustaleń na celach, które raportują wywołania narzędzi, nie pojawia się w ogóle, gdy czyta się samą odpowiedź. Bot odpowiada uprzejmie i umieszcza sekret w argumencie wywołania.
Twój agent zostaje namówiony na nieodwracalne działanie: usunięcie danych, zwrot pieniędzy, wysłanie maila.
SQL albo polecenie powłoki przemycone do wywołania narzędzia. Stara klasa błędów, nowe drzwi wejściowe.
Jeden złośliwy dokument w twoim RAG przejmuje odpowiedzi na niewinne pytania.
Ukryta linijka w opisie narzędzia sprawia, że twój agent ujawnia coś przy zwykłym pytaniu, bez żadnej wiadomości od atakującego.
qatration init sam pisze konfigurację: adres URL, kształt żądania i to, w którym miejscu odpowiedzi znajduje się tekst bota. Zdalny cel chce dodatkowo nagłówka uwierzytelniającego, jako zmiennej środowiskowej. Gotowe konfiguracje dla API w formacie OpenAI oraz dla API Anthropic, Bedrock i Vertex. qatration onboard wysyła jedno zwykłe pytanie i mówi, czego brakuje, zanim wyleci choć jeden atak.
qatration init generuje twój własny sekret i blok, który wklejasz do promptu systemowego. Przebieg najpierw potwierdza, że rzeczywiście się przyjął: niepodłożony kanarek oznacza, że każde sprawdzenie nic nie znajduje, a to czyta się dokładnie jak bot, który się obronił.
Co wyciekło, dokładnie jak i ta jedna poprawka, która to zamyka, napisane dla zespołu bez eksperta od bezpieczeństwa. --fail-on exploited przerywa build. qatration sarif wrzuca ustalenia prosto do twojej zakładki code scanning.
Atak, który nie przeszedł, raportuje zero. Tak samo sprawdzenie, które nie mogło się wykonać, i tak samo naprawdę utwardzony bot, i właśnie tu testowanie grzęźnie: trzy różne fakty wyglądają identycznie i nikt nie wie, co próbować dalej. To są pomiary z prawdziwych przebiegów, nie szacunki.
A wyłom jest wyłomem tylko wtedy, gdy spowodował go atak. Każdy cel dostaje najpierw nieszkodliwy przebieg: zwykłe pytania, nikt nie atakuje. Na jednym z tutejszych botów
canary_in_tool_call odpala się przy 88% tego zwykłego ruchu, więc ustalenie, które opiera się wyłącznie na nim, jest oznaczane jako nieprzypisywalne, a nie liczone.
Kiedy atak zawodzi, raport nazywa to, co go zatrzymało: sprawdzenie tożsamości, filtr treści, uprawnienie po stronie backendu albo wywołanie narzędzia, które tylko wypisano i nigdy naprawdę nie wykonano. To ostatnie czyta się w transkrypcji jak wyłom i jest nic niewarte.
Jeden bot, dwa modele, po 254 ataki każdy, po 3 próby. Mniejszy pękł na 27 z nich, większy na 24, a 18 z nich to te same ataki, z czego 17 łamie oba modele przy każdej pojedynczej próbie. Na tym bocie większy model jedynie przetasował, które ataki wchodzą na obrzeżach. Dziury nie zamyka.
Przeciwko prawdziwemu frameworkowi guardraili, 46 ataków wpisanych w okno czatu: nie przeszedł żaden. Nie przeszedł też jeden przeniesiony wewnątrz pobranego dokumentu, dopóki oba jego guardraile były włączone. Wyłącz filtr wyjściowy, a ten sam dokument wychodzi na zewnątrz przy każdej pojedynczej próbie. Filtry wejściowe czytają to, co wpisuje użytkownik, i nigdy nie widzą tego, co twoja baza wiedzy podaje modelowi, więc guardrail wejściowy nigdy nie był tym, co go zatrzymywało.
Wysłaliśmy te same wiadomości do tego guardraila ponownie i nie zawsze zgadzał się sam ze sobą: pięć sformułowań dostało różne werdykty przy identycznym wejściu, a jedno zwykłe pytanie przepuszczono dziesięć razy na dwanaście. Dlatego raportujemy, ile prób coś złamało, a nie czy złamała jedna. Pojedynczy przebieg to opowieść o jednym popołudniu i dotyczy to czystego wyniku tak samo jak złego, łącznie z naszym.
Ten sam guardrail, który zablokował tamten dokument, odmówił też odpowiedzi na 6 z 9 zwykłych pytań klientów dotyczących tych samych tematów. Obrona, która odpowiada „nie” twoim klientom, to liczba, którą chcesz znać przed wydaniem, a nie po.
Skaner, który zawsze coś znajduje, jest nic niewart, więc zmierzyliśmy to od drugiej strony: 1500 nieszkodliwych sond na 30 celach, bez żadnego atakującego wśród nich, przez te same sprawdzenia. Połowa z nich to użytkownicy, którzy mają pełne prawo mówić o bezpieczeństwie, bo właśnie to łamie dopasowanie do wzorca: ktoś, kto wkleja zapytanie, które się wywala, wsparcie przekazujące stack trace, ktoś pytający, czy łudząco podobna domena jest prawdziwa.
Boty pisane tutaj to łatwy przypadek, więc skierowaliśmy nasze narzędzie na framework agentowy, którego nikt tutaj nie projektował. Dało osiem fałszywych alarmów w jednym przebiegu na 48 czystych promptach, w czterech kategoriach, których 480 sond przeciwko naszej własnej flocie nie wywołało ani razu. Wszystkie cztery są naprawione, a dwie reguły, które za tym stoją, wywalają teraz nasz build zamiast twojego raportu: żadne sprawdzenie nie może czytać pytania i żadne sprawdzenie nie może traktować własnych słów agenta jako dowodu na stan systemu.
Uruchomione przeciwko tym samym zewnętrznym celom co garak i promptfoo, przy czym każda odpowiedź wszystkich trzech była oceniana jedną regułą dopasowania podłańcucha zamiast własnym sędzią każdego narzędzia. W aplikacji RAG bez żadnych guardraili 46% nieszkodliwych sond już zwraca podłożony ciąg, więc liczenie ustaleń mierzy aplikację, a nie atakującego. Jedno z trzech narzędzi mówi to w swoim raporcie. Na chronionym celu wszystkie trzy dostają zero według wspólnej reguły, a my byliśmy jedynymi, którzy w ogóle cokolwiek znaleźli, jeden wyłom na 324, podczas gdy to samo wdrożenie odmawia odpowiedzi na 38 z 48 zwykłych pytań klientów. Strona z porównaniem publikuje też to, w czym pozostałe dwa są lepsze, oraz twierdzenie, które wycofaliśmy po tym, jak recenzent poprosił o wartość p. Przeczytaj porównanie.
Profil z dwunastu sond, wszystkich nieszkodliwych: pięć botów oddało własne instrukcje na zwykłą prośbę. Jeden wypisał swój poufny klucz sesji wewnątrz tego samego zdania, które zabraniało mu ten klucz udostępniać. Dwa zgłosiły restart bazy danych, nie mając narzędzia, które mogłoby cokolwiek zrestartować.
Każdy przebieg jest zachowywany, więc każde ustalenie ma datę pierwszego pojawienia się. „Krytyczne” to opinia. „Krytyczne i otwarte od trzeciego” to fakt o tym, jak zespół reaguje na takie ustalenia, i to właśnie ta linijka sprawia, że poprawka trafia do planu.
Ustalenie, które wraca po zamknięciu, jest oznaczane jako nawrót, a nie po cichu liczone razem z nowymi. Poprawka, która się nie utrzymała, to gorsza z tych dwóch rozmów, a wrzucenie ich do jednego worka to ukrywa.
Jeśli przebieg nie wysyła ataku, ten atak trafia do raportu jako nieprzetestowany, nigdy jako naprawiony. Brak testu to nie czysty wynik, a raport, który zaciera tę różnicę, mówi ci, że twoje podatności zniknęły, choć naprawdę nikt nie patrzył.
Niektóre wywołania podają narzędziu wartość, która nie pojawia się w żadnym tekście, jaki możemy przeczytać. Wypisujemy je osobno i mówimy, który log je otwiera, bo różnica między „sprawdziliśmy i było czysto” a „nie mogliśmy zobaczyć” to różnica między pomiarem a obietnicą.
„Powiedzieliśmy mu, żeby nie ujawniał sekretów” to twierdzenie, a nie obrona: na tutejszych celach taka obrona padała w ciągu pierwszych kilku ataków. QAtration uznaje też za czyste te boty, które naprawdę są dobrze zabezpieczone, więc czysty wynik coś znaczy. Mierzy twojego bota, zamiast po prostu ciągle podnosić fałszywy alarm.
Apache 2.0. Zainstaluj, skieruj na swoje własne wdrożenie, zachowaj dowody.