Systemy oparte o LLM wprowadzają nowy model działania, ale wiele zagrożeń bezpieczeństwa wynika z dobrze znanych wzorców ryzyka. Zmienia się nie sam cel ataku, lecz sposób, w jaki w jednym przepływie łączą się dane, instrukcje, narzędzia i uprawnienia. To właśnie dlatego prompt injection i inne ataki na systemy AI nie powinny być analizowane wyłącznie jako problem modelu, ale jako problem całej architektury systemu.
W praktyce oznacza to, że ryzyko nie kończy się na złośliwym prompcie, tylko może zacząć się od danych wejściowych, przejść przez kontekst i RAG, wykorzystać narzędzia lub integracje, a na końcu doprowadzić do nadużycia uprawnień, wycieku danych albo wykonania nieautoryzowanych działań.
Dla CISO to nie jest więc temat pojedynczej podatności, ale modelowania zagrożeń warstwa po warstwie.
Skala problemu jest poważna: można zaryzykować stwierdzeniem, że 100% systemów AI jest podatnych na ataki, ponieważ nie istnieje dziś w pełni skuteczna metoda obrony przed prompt injection.
Dlatego systemy AI należy projektować przy założeniu, że pojedyncze zabezpieczenia mogą zostać ominięte, a odporność trzeba budować wielowarstwowo – na poziomie wejścia, kontekstu, RAG, narzędzi, uprawnień, wyjścia i kontroli operacyjnej.
Jak przebiega komunikacja z LLM (Large Language Model)?
Aby dobrze modelować zagrożenia w systemach AI, trzeba najpierw zrozumieć, jak taki system faktycznie działa.
Z perspektywy użytkownika wygląda to prosto: zadajemy pytanie i dostajemy odpowiedź. W praktyce model nie pracuje jednak na pojedynczym zdaniu, tylko na całym kontekście, który został mu przekazany przez aplikację.
W najprostszym ujęciu ten przepływ obejmuje instrukcję systemową, input użytkownika, model oraz odpowiedź lub akcję systemu. To właśnie w tym miejscu pojawia się też główna powierzchnia ataku związana z prompt injection.
Wiadomości i kontekst modelu językowego
Dla modelu językowego kontekst to wszystko, co „wie” o bieżącej interakcji. Obejmuje on nie tylko treść pytania użytkownika, ale też instrukcję systemową, wcześniejsze wiadomości, a w bardziej rozbudowanych architekturach również dane zewnętrzne i wyniki działania narzędzi. To zbiór wiadomości, który dopiero po złożeniu trafia do modelu. To ważne, bo model nie odpowiada wyłącznie na ostatnią wiadomość – działa na podstawie całego kontekstu, jaki dostaje od aplikacji.
Pytanie-odpowiedź
Najprostszy wariant to architektura pytanie-odpowiedź. System przekazuje do modelu instrukcję systemową i jedną wiadomość użytkownika, a następnie odbiera odpowiedź.
Taki przepływ wygląda najczyściej, ale już na tym poziomie widać podstawową logikę bezpieczeństwa: model reaguje na to, co znajduje się w kontekście, a nie na intencję projektanta systemu. Dlatego nawet prosty chatbot nie jest wyłącznie interfejsem rozmowy, tylko systemem, którego zachowanie zależy od tego, jak został zbudowany kontekst wejściowy.
Konwersacja
Sytuacja komplikuje się, gdy przechodzimy do konwersacji wieloturowej. Wtedy do kontekstu trafia nie tylko nowe pytanie użytkownika, ale także wcześniejsze odpowiedzi modelu i historia rozmowy.
Z punktu widzenia funkcjonalności to naturalne – system ma „pamiętać”, o czym była rozmowa.
Z punktu widzenia bezpieczeństwa oznacza to jednak, że każde kolejne wywołanie modelu opiera się na coraz szerszym zestawie treści, które mogą wpływać na logikę odpowiedzi. Im dłuższa i bogatsza rozmowa, tym większe znaczenie ma to, co dokładnie zostało utrwalone w kontekście.
RAG
Kolejny poziom to RAG, czyli wzbogacanie kontekstu o zewnętrzne źródła wiedzy. Do okna kontekstowego mogą trafiać dokumenty, rekordy z bazy danych, treści stron internetowych czy inne materiały, które mają pomóc modelowi udzielić pełniejszej odpowiedzi.
Pozwala to połączyć model z wiedzą organizacji lub zewnętrznymi danymi. Jednak z perspektywy bezpieczeństwa oznacza to, że do modelu zaczynają trafiać treści spoza bezpośredniej rozmowy z użytkownikiem – a więc także treści, które mogą być błędne, niezweryfikowane albo złośliwe.
Użycie narzędzi
Najbardziej rozbudowany wariant to system AI, w którym model nie tylko odpowiada, ale także korzysta z narzędzi. W takim scenariuszu model może najpierw wywołać określoną funkcję, API albo automatyzację, a dopiero potem – po otrzymaniu wyniku – wygenerować odpowiedź końcową. Wynik działania narzędzia również wraca do kontekstu i wpływa na dalszy przebieg zadania.
To kluczowy moment z perspektywy CISO, bo system AI przestaje być wtedy wyłącznie warstwą odpowiedzi, a zaczyna realnie oddziaływać na dane, procesy i operacje. Im więcej narzędzi, integracji i kroków pośrednich, tym większa powierzchnia ryzyka.
To właśnie dlatego komunikacji z modelem LLM nie należy sprowadzać do prostego schematu „pytanie-odpowiedź”. W praktyce jest to przepływ, w którym kontekst może być budowany z wielu źródeł, rozszerzany o historię rozmowy, zasilany danymi zewnętrznymi i uzupełniany wynikami działania narzędzi. A skoro tak, to bezpieczeństwo systemu AI trzeba oceniać nie tylko na poziomie modelu, ale całej architektury, która ten kontekst tworzy.
Czym jest prompt injection?
Prompt injection to atak polegający na wprowadzeniu specjalnie przygotowanej instrukcji, która nakłania model AI do działania w sposób niezgodny z jego przeznaczeniem. Złośliwy prompt nie musi „zepsuć” samego modelu – wystarczy, że wpłynie na to, jak model interpretuje kontekst i jakie działania uzna za właściwe. Właśnie dlatego ataki typu Prompt Injection są dziś traktowane jako główna powierzchnia ataku w systemach opartych o LLM.
Oznacza to, że w przypadku takiego ataku model otrzymuje nie tylko właściwe pytanie czy zadanie, ale również dodatkową, złośliwą instrukcję, która ma zmienić sposób jego działania. Jeżeli system nie oddziela wystarczająco dobrze danych od instrukcji, model może potraktować złośliwą treść jako instrukcję sterującą i odpowiedzieć lub zadziałać wbrew intencji projektanta systemu.
Skutki prompt injection
Atak typu prompt injection dla organizacji może oznaczać:
- ujawnienie poufnych informacji,
- wykonanie nieautoryzowanych działań,
- manipulację odpowiedziami systemu AI,
- utratę zaufania klientów i partnerów.
Więcej o prompt injection, rodzajach i konsekwencjach pisaliśmy w tym artykule: http://secawa.com/blog/prompt-injection-czym-jest-dlaczego-stanowi-ryzyko-dla-organizacji-i-jak-je-ograniczyc/
Jak modelować zagrożenia w systemach AI?
Dla CISO kluczowe nie jest wyłącznie pytanie, czy system jest odporny na prompt injection, ale jak ocenić ryzyko osobno dla każdej warstwy systemu AI – od wejścia i kontekstu, przez RAG oraz narzędzia, po uprawnienia, wyjście i kontrolę operacyjną.
W praktyce modelowanie zagrożeń w systemach AI warto rozłożyć na 7 obszarów: wejścia, kontekst, RAG, narzędzia i integracje, uprawnienia, wyjście oraz telemetrię i kontrolę.
01 Dane wejściowe
To pierwszy i najbardziej oczywisty obszar modelowania zagrożeń. Do systemu AI mogą trafiać:
- dane od użytkownika,
- pliki,
- strony internetowe,
- e-maile,
- tickety,
- repozytoria.
To właśnie te wejścia materiały wskazują jako główne punkty wejścia dla prompt injection. Problem polega na tym, że system nie zawsze odróżnia zwykłą treść od złośliwej instrukcji. Im więcej źródeł wejściowych i formatów danych, tym większe ryzyko, że złośliwy prompt zostanie potraktowany jak część legalnego kontekstu.
02 Kontekst
Druga warstwa to sam kontekst modelu, czyli:
- system prompt,
- pamięć,
- polityki.
To tutaj dochodzi do prób przejęcia logiki działania systemu lub ujawnienia ukrytych instrukcji. Z perspektywy bezpieczeństwa jest to krytyczne, ponieważ manipulacja kontekstem może prowadzić do zmiany logiki działania systemu albo ujawnienia instrukcji sterujących modelem.
03 RAG
Kolejna warstwa to RAG, czyli mechanizm wzbogacania kontekstu modelu o dokumenty i dane z bazy wiedzy. Z perspektywy architektury obejmuje to m.in. bazę wektorową, retriever i ranker.
W tej warstwie główne ryzyka to ekstrakcja danych, manipulacja kontekstem oraz zatrucia danych. Jeśli system pobiera treści z dokumentów, stron WWW, e-maili lub innych źródeł zewnętrznych, pośrednie wstrzyknięcie promptu może nastąpić bez bezpośredniej interakcji użytkownika z atakującym.
04 Narzędzia i integracje
Gdy model ma dostęp do API, funkcji, automatyzacji albo serwerów MCP, przestaje być wyłącznie warstwą generowania odpowiedzi, a zaczyna wpływać na procesy, dane i działania wykonywane poza samym LLM.
To właśnie tutaj pojawia się ryzyko nieautoryzowanych akcji i nadużycia narzędzi. Wystarczy manipulacja promptem, kontekstem lub przebiegiem zadania, by system AI wykonał operację, której nie powinien uruchomić.
05 Uprawnienia
To jedna z najważniejszych warstw z perspektywy CISO. Pytanie nie brzmi tylko, do czego model ma dostęp, ale też na czyich uprawnieniach działa i jaki zakres dostępu mają podłączone narzędzia.
Kluczowa zasada jest prosta: kontrola dostępu musi działać poza LLM, na poziomie aplikacji. Jeżeli system tego nie dopilnuje, asystent AI może wykonywać operacje z większym zakresem uprawnień, niż powinien, albo uruchamiać akcje, do których użytkownik normalnie nie miałby dostępu.
06 Wyjście modelu językowego
Modelowanie zagrożeń nie kończy się na wejściu. Równie ważne jest to, co system zwraca dalej: odpowiedzi, linki, HTML, integracje i dane przekazywane do kolejnych komponentów.
To istotne, bo odpowiedź modelu może być:
- szkodliwa sama w sobie,
- wejściem dla kolejnego systemu,
- nośnikiem wycieku danych,
- punktem uruchomienia dalszych działań w łańcuchu automatyzacji.
Dlatego wyjście modelu trzeba traktować jak element powierzchni ataku, a nie tylko końcowy rezultat działania.
07 Telemetria i kontrola
Ostatnia warstwa to nadzór operacyjny nad systemem AI – logi, limity, alerty, zatwierdzanie akcji i wykrywanie anomalii. Ta część nie blokuje ataku sama z siebie, ale daje organizacji możliwość audytu, wykrywania nadużyć i szybkiej reakcji.
To szczególnie ważne tam, gdzie system wykonuje działania kosztowne, wrażliwe lub trudne do odwrócenia. Bez telemetrii i kontroli organizacja traci widoczność tego, co system AI zrobił, jak zachowywał się podczas wykonywania poleceń oraz czy doszło do nadużyć, anomalii lub kosztownych skutków operacyjnych.
7 pytań, od których CISO powinien zacząć ocenę ryzyka systemów AI
Odporność systemu AI trzeba projektować wielowarstwowo. Dlatego dobrym punktem wyjścia jest przejście przez 7 warstw systemu AI i ocena ryzyka osobno dla każdej z nich – od danych wejściowych i kontekstu, przez RAG oraz narzędzia, po uprawnienia, wyjście i kontrolę operacyjną.
Co może wejść do systemu?
Pierwsze pytanie dotyczy nie modelu, ale kanałów wejściowych. Do systemu AI mogą trafiać nie tylko prompty użytkownika, ale też pliki, strony internetowe, e-maile czy dokumenty. To właśnie tutaj zaczyna się duża część skutecznych ataków, bo model może potraktować niezaufane dane jak instrukcję. Dlatego CISO powinien sprawdzić, które wejścia są filtrowane, czy działa screening wejścia, czy wykrywane są wzorce prompt injection i czy organizacja reaguje na powtarzalne nadużycia użytkowników.
Co trafia do kontekstu modelu?
Drugie pytanie brzmi: co dokładnie model widzi jako kontekst. Dobra praktyka nie polega na „mocniejszym promptcie systemowym”, tylko na rozdzieleniu danych od instrukcji, jasnym oznaczeniu, co jest poleceniem systemowym, a co treścią użytkownika lub dokumentu, oraz na minimalizacji przekazywanego kontekstu do tego, co naprawdę potrzebne do wykonania zadania. CISO powinien też ocenić, czy w kontekście nie lądują sekrety, wrażliwe konfiguracje albo zbędne informacje, które zwiększają ryzyko wycieku.
Jakie źródła wiedzy wzbogacają odpowiedź?
Przy RAG kluczowe jest pytanie nie tylko o to, z czego system korzysta, ale też jak ufa tym źródłom. Dokumenty, strony WWW, PDF-y, e-maile i komentarze mogą zawierać złośliwe instrukcje, dlatego źródła zewnętrzne trzeba traktować jako niezaufane, a treści w RAG filtrować i oznaczać przed włączeniem do kontekstu. Z perspektywy CISO ważne jest także to, czy system zachowuje kontrolę uprawnień do danych źródłowych, czy segmentuje repozytoria oraz czy wykrywa próby masowej ekstrakcji danych.
Jakie narzędzia może wywołać model?
Gdy system AI korzysta z API, funkcji albo automatyzacji, błędna odpowiedź może szybko stać się kosztowną wpadką operacyjną. Dlatego CISO powinien ocenić, jakie narzędzia model może uruchomić, czy ich użycie jest walidowane przed wykonaniem akcji, czy kontrolowany jest output zwracany przez narzędzia i czy model nie może samodzielnie pomijać wymaganych kroków procesu. W praktyce bezpieczeństwo tej warstwy opiera się na walidacji wywołań, kontroli sekwencji działań i ograniczaniu zakresu integracji do minimum niezbędnego dla danego zadania.
Na czyich uprawnieniach działa system?
To pytanie często decyduje o skali incydentu. CISO powinien ustalić, czy agent działa w kontekście użytkownika, aplikacji czy uprzywilejowanego backendu, a także czy autoryzacja odbywa się poza LLM, na poziomie aplikacji. Dobre praktyki są tu jednoznaczne: wszystkie operacje powinny odbywać się z uprawnieniami użytkownika, a nie systemu, zakres narzędzi powinien być minimalny, a tożsamość użytkownika, agenta i backendu powinna być rozdzielona. Bez tego prompt injection może przerodzić się w privilege escalation i nieautoryzowane operacje.
Co wychodzi z modelu i gdzie trafia dalej?
Wyjście modelu to nie tylko odpowiedź dla użytkownika. To także potencjalny nośnik wycieku danych, kolejny krok automatyzacji albo wejście dla innego systemu. Dlatego CISO powinien sprawdzić, czy organizacja kontroluje odpowiedzi modelu, wykrywa próby ujawnienia danych na wyjściu, ogranicza długość odpowiedzi i liczbę kroków oraz nie umieszcza sekretów w promptach i kontekście. W praktyce równie ważne jak blokowanie ataku jest szybkie ograniczanie skutków eksfiltracji i nadużyć kosztowych.
Jak organizacja to loguje, kontroluje i testuje?
Ostatnie pytanie dotyczy tego, czy organizacja ma realny nadzór nad systemem AI po wdrożeniu. Jednorazowe sprawdzenie nie wystarczy. Skuteczny nadzór powinien obejmować telemetrię systemu, alerty, logi, monitoring zachowania agenta, kontrolę kosztów i tokenów oraz regularne testowanie odporności na prompt injection i ataki na RAG. Ważne jest też to, by mierzyć nie tylko skuteczność blokad, ale również jakość odpowiedzi – tak, żeby po wdrożeniu zabezpieczeń system nadal działał poprawnie, trafnie i przewidywalnie.
Podsumowanie
Bezpieczeństwa systemów AI nie da się ocenić jednym testem ani jednym promptem obronnym. W systemach AI ryzyko powstaje w całym przepływie – od danych wejściowych, przez kontekst i RAG, po narzędzia, uprawnienia, wyjście oraz warstwę telemetrii i kontroli. Dlatego ocenę ryzyka warto prowadzić warstwa po warstwie, a nie wyłącznie na poziomie samego modelu.
Z perspektywy CISO najważniejszy wniosek jest prosty: nie istnieje dziś jedna, w pełni skuteczna metoda obrony przed prompt injection. Ale nie oznacza to, że organizacje są bezradne.
Odporność systemów AI trzeba projektować wielowarstwowo – łącząc kontrolę wejścia, bezpieczne budowanie kontekstu, ograniczone zaufanie do źródeł, walidację poza LLM, kontrolę uprawnień, monitoring oraz regularne testowanie odporności na realne scenariusze ataków. Równie ważne jak blokowanie ataku jest ograniczanie jego skutków i szybkie wykrywanie naruszeń.
Jeżeli chcesz zweryfikować, jak Twoje środowisko poradzi sobie z scenariuszami ataków w praktyce, warto oprzeć to na kontrolowanych testach. W SECAWA przeprowadzamy profesjonalne testy penetracyjne, które pomagają odkryć podatności systemów, a następnie przekuć wyniki w konkretne rekomendacje działań naprawczych. Dzięki temu przygotować organizację na realne cyberataki i lepiej chronić dane, reputację oraz ciągłość działania.
Przetestuj zabezpieczenia systemów za pomocą kontrolowanych cyberataków
