Testy z pozycji atakującego dla aplikacji LLM, agentów AI i integracji MCP: prompt injection, wycieki danych, nadużycie narzędzi i wyjście poza zamierzone zadanie.
Aplikacja zbudowana na modelu językowym przyjmuje polecenia ze wszystkiego, co czyta: od użytkownika, z pobranego dokumentu, z treści strony internetowej, z wyniku działania narzędzia. Nie potrafi niezawodnie odróżnić polecenia od danych. Gdy model może wywoływać narzędzia, wysyłać wiadomości lub zapisywać dane w bazie, zdanie ukryte w dokumencie staje się działaniem w Twoich systemach.
Testujemy całą aplikację, a nie tylko model: prompty, potok wyszukiwania dokumentów, narzędzia i ich uprawnienia, agentów i protokoły, które ich łączą. Pytanie brzmi: do czego atakujący może zmusić system, co może przez niego odczytać lub ujawnić i czy zabezpieczenia wokół modelu wytrzymują, gdy sam model zawodzi.
01Zakres
Co testujemy
Bezpośrednie i pośrednie ataki prompt injection przez każde źródło danych, które czyta model
Ujawnienie promptów systemowych, sekretów i danych innych użytkowników lub tenantów
Retrieval-augmented generation (RAG): zatruwanie danych, kontrola dostępu do bazy dokumentów
Narzędzia i wywoływanie funkcji: nadmierne uprawnienia, niebezpieczne parametry, problem confused deputy
Agenci: przejmowanie celu, zatruwanie pamięci, niebezpieczna autonomia, zaufanie między agentami
Serwery Model Context Protocol: uwierzytelnianie, zatruwanie narzędzi, wykonywanie poleceń
Obsługa odpowiedzi modelu: wstrzykiwanie do przeglądarek, powłok, zapytań i dalszych systemów
Mechanizmy ochronne i filtry: obchodzenie przez kodowanie, zmianę języka, odgrywanie ról i ataki wieloetapowe
Zużycie zasobów i nadużycia generujące koszty
02Podejście
Jak przebiega praca
01
Przegląd architektury
Ustalamy, co model czyta, co może wywołać i z czyimi uprawnieniami. Większość krytycznych znalezisk widać już na tym etapie jako brakującą granicę zaufania.
02
Testy z pozycji atakującego
Dane wejściowe przygotowujemy ręcznie i generujemy na dużą skalę dla każdego kanału prowadzącego do modelu. Udany atak sprowadzamy do najkrótszego wejścia, które go odtwarza.
03
Nadużycie narzędzi i agentów
Za pomocą wstrzykniętych poleceń sterujemy narzędziami i agentami: odczytujemy to, co powinno być niedostępne, działamy w imieniu innego użytkownika, przechodzimy z jednego systemu do kolejnego.
04
Testy zabezpieczeń
Filtry, mechanizmy ochronne i kroki zatwierdzania testujemy osobno. Raport podaje, które zabezpieczenie zatrzymało który atak, a które nie zatrzymało żadnego.
Aplikację. Za bezpieczeństwo modelu bazowego odpowiada jego dostawca. To, co kontrolujesz i co wykorzystują atakujący, to sposób, w jaki model jest połączony z Twoimi danymi i narzędziami.
Podatności na prompt injection nie da się całkowicie usunąć. Po co jej szukać?
Po to, by wiedzieć, co z niej wynika. Jeśli wstrzyknięcie prowadzi do błędnej odpowiedzi, to problem jakości. Jeśli prowadzi do e-maila wysłanego w imieniu użytkownika, to podatność w uprawnieniach wokół modelu, a tę można usunąć.
Czy używacie naszych danych do trenowania zewnętrznych usług AI lub w promptach do nich?
Nie. Danych klientów, promptów ani znalezisk nie przesyłamy do publicznych usług AI i nie używamy ich do trenowania. Narzędzia oparte na modelach językowych działają w środowiskach, które kontrolujemy.
Czy usługa obejmuje wymagania unijnego aktu w sprawie sztucznej inteligencji (AI Act)?
Testy z pozycji atakującego to jeden ze środków, o których akt mówi w odniesieniu do niektórych systemów i modeli. Raport dokumentuje metodę, zakres i wyniki w formie, która może posłużyć jako dowód. To, czy i jak akt ma zastosowanie do Twojego systemu, jest kwestią prawną, na którą nie odpowiadamy.