Testujemy chatboty, wyszukiwarki po dokumentach wewnętrznych i agentów z dostępem do narzędzi. Najgroźniejsze podatności zwykle nie siedzą w modelu, tylko w tym, co aplikacja robi z jego odpowiedzią.
Bezpośrednie w rozmowie i pośrednie - przez dokument w bazie wiedzy, stronę odwiedzaną przez asystenta albo treść maila, który ma streścić.
Gdzie trafia wygenerowany tekst: do HTML, do zapytania, do wywołania narzędzia. Odpowiedź modelu trzeba traktować jak dane od niezaufanego użytkownika.
Czym dysponuje agent i czyimi uprawnieniami działa. Brak potwierdzeń przy operacjach nieodwracalnych, konta techniczne z prawami szerszymi niż potrzebne.
Bazy wektorowe wspólne dla wielu klientów, filtrowanie uprawnień dopiero po pobraniu wyników, dostęp do cudzych dokumentów przez odpowiednio zadane pytanie.
Instrukcja jako mapa systemu: nazwy narzędzi, reguły biznesowe, a zaskakująco często klucze i adresy usług wewnętrznych.
Zapytania generujące rachunek nieproporcjonalny do wysiłku atakującego, limity na użytkownika, monitorowanie nagłych wzrostów.
Model językowy sam w sobie rzadko jest problemem. Dostarcza go OpenAI, Anthropic albo inny dostawca i to on odpowiada za jego zachowanie. Problem powstaje w warstwie, którą zbudowaliście wokół niego: jakie dane do niego trafiają, jakie ma uprawnienia i co system robi z tym, co zwróci.
U podstaw leży cecha konstrukcyjna, nie błąd. Instrukcja systemowa, historia rozmowy, treść pobranego dokumentu i pytanie użytkownika trafiają do jednego okna kontekstu jako ten sam tekst. Model nie ma niezawodnego sposobu, żeby odróżnić polecenie od treści do przetworzenia. Dlatego wstrzykiwania promptu nie da się wyeliminować tak, jak eliminuje się wstrzyknięcia SQL.
Groźniejsza od wersji bezpośredniej jest postać pośrednia: instrukcja ukryta w dokumencie, który sami wgraliście do bazy wiedzy, na stronie odwiedzanej przez asystenta albo w treści maila, który ma streścić. Atakujący nie potrzebuje wtedy dostępu do aplikacji - wystarczy, że umieści tekst tam, skąd system czerpie dane.
Testowanie takich systemów wygląda inaczej, bo model jest probabilistyczny: ten sam scenariusz raz przejdzie, a raz nie. Każdą technikę powtarzamy wielokrotnie i oceniamy skuteczność statystycznie. Znalezisko w postaci "ta technika działa w jednej trzeciej prób" jest tu w pełni sensowne i wystarczające, żeby uznać zabezpieczenie za nieskuteczne.
Szerzej opisaliśmy to na blogu: jak testuje się aplikacje oparte na LLM - z przykładem znaleziska z realnego testu.
Definiujemy, co testujemy, w jakim trybie i w jakich godzinach. Doprecyzowujemy, co jest poza zakresem.
Pełna poufność na każdym etapie. Znalezione podatności zostają między nami.
Testy manualne wsparte narzędziami. Krytyczne znaleziska zgłaszamy od razu, nie czekamy z nimi do raportu.
Raport z oceną ryzyka, krokami reprodukcji i rekomendacjami. Po wdrożeniu poprawek sprawdzamy je ponownie.
Opisz, co zbudowaliście i do czego model ma dostęp - odezwiemy się w 24 h z wyceną.
Zapytaj o wycenęPozostałe rodzaje testów