Prompt injection: jak chronić firmowe chatboty przed atakiem

Czym jest prompt injection i skąd bierze się w firmowych systemach?

Prompt injection to atak, w którym złośliwa instrukcja trafia do kontekstu modelu razem z treścią, którą system przetwarza. NIST w raporcie z 25 lipca 2024 r. wymienia dwie odmiany: bezpośrednią, wpisaną przez użytkownika, oraz pośrednią, ukrytą w dokumencie, e-mailu albo odpowiedzi API [1]. Skutki obejmują ujawnienie danych, phishing, nadużycie narzędzi i nieautoryzowane działania [1][2].

Polski poradnik opisuje to samo zjawisko krótko: to sytuacja, w której złośliwe instrukcje trafiają do kontekstu modelu językowego [3]. W firmie źródłem takiej treści bywa zgłoszenie klienta, załącznik do reklamacji, wiadomość e-mail albo strona pobrana przez agenta. System łączy model z bazą wiedzy i pocztą, więc każda z tych treści trafia do tego samego okna kontekstu.

Podstawy budowania poleceń, w tym różnicę między instrukcją a danymi, opisuje nasz słownik promptów. Bez tego rozróżnienia ochrona sprowadza się do listy zakazanych słów, którą atakujący łatwo omija.

Prompt injection a phishing — czym się różnią?

Phishing to podszywanie się pod instytucję, a prompt injection to manipulacja modelem. 20 marca 2024 r. CSIRT KNF ostrzegł przed domeną pkobp.info służącą do wyłudzania danych logowania [4]. To klasyczny phishing: fałszywa strona i fałszywy komunikat, nie atak na model językowy.

PKO BP opisywało kampanię phishingową także 7 grudnia 2024 r. Bank przypomniał wtedy, że nie wysyła linków w e-mailach i SMS-ach [5]. Wcześniej, 11 stycznia 2024 r., pojawiło się ostrzeżenie przed fałszywymi wiadomościami i stronami logowania podszywającymi się pod bank [6].

Połączenie obu zjawisk w jednej historii brzmi wiarygodnie, ale wymaga dowodu. W dostępnych źródłach nie ma potwierdzenia, że phishing przeciwko klientom PKO powstał z użyciem prompt injection. Mechanizmy są różne: phishing wykorzystuje zaufanie do marki, a prompt injection lukę w sposobie łączenia poleceń z danymi.

Dlaczego prompt systemowy nie wystarcza do ochrony danych?

Prompt systemowy to instrukcja dla modelu, a nie mechanizm autoryzacji. OWASP w rankingu LLM01:2025 stawia prompt injection na pierwszym miejscu zagrożeń aplikacji opartych na modelach językowych [7][8]. Problem wynika z trudności w niezawodnym odróżnieniu danych od poleceń w tym samym strumieniu tekstu.

NIST zaznacza, że dostępne zabezpieczenia nie zapewniają pełnej ochrony [1][9]. Model może więc wykonać polecenie ukryte w treści, nawet jeśli prompt systemowy mówi „nie ujawniaj danych”. Zakaz w prompcie jest sugestią, a nie barierą techniczną.

Uprawnienia trzeba egzekwować poza modelem: przez kontrolę dostępu, zakres tokenów i walidację wywołań narzędzi. Model może zaproponować przelew, zmianę limitu karty albo odpowiedź z danymi klienta. Wykonanie takiej operacji powinno zależeć od niezależnej autoryzacji, nie od treści wygenerowanej odpowiedzi [7].

Które zabezpieczenia najlepiej ograniczają ryzyko w praktyce?

Największy efekt daje połączenie kilku warstw: separacji niezaufanych treści, ograniczenia uprawnień narzędzi, walidacji wejścia i wyjścia oraz zatwierdzania operacji nieodwracalnych przez człowieka. Pojedyncza technika nie wystarcza, bo każda działa na innym etapie przetwarzania [1][2].

Separacja danych i poleceń polega na tym, że treść zewnętrzna trafia do modelu jako wyraźnie oznaczony blok, a nie jako kolejne zdanie rozmowy. To ogranicza ryzyko, ale nie usuwa go całkowicie, bo model nadal przetwarza oba elementy w jednym kontekście.

Ograniczenie uprawnień działa niezależnie od jakości promptu. Token API powinien mieć dostęp tylko do tych zasobów, które są potrzebne do zadania. Operacja spoza zakresu musi zostać odrzucona przez system, nawet jeśli model ją zaproponuje.

Jak wdrożyć obronę warstwową krok po kroku?

Wdrożenie zaczyna się od inwentaryzacji: gdzie model czyta treści z zewnątrz i jakie narzędzia może wywołać. Dopiero potem ustala się uprawnienia, walidację i punkty zatwierdzania. Kolejność ma znaczenie, bo kontrola dostępu ogranicza skutki błędu w każdej kolejnej warstwie [1].

1. Wypisz wszystkie miejsca, w których model przyjmuje treść od użytkownika lub z zewnętrznego źródła.
2. Przypisz każdemu wywołaniu narzędzia minimalny zakres uprawnień i oddziel operacje odczytu od operacji zapisu.
3. Oznacz treści niezaufane w prompcie i przetestuj, czy model reaguje na instrukcje ukryte w dokumencie.
4. Dodaj walidację wyjścia: sprawdzaj format, adresy URL i pola, które model może wypełnić.
5. Wprowadź zatwierdzenie człowieka dla przelewów, zmian uprawnień i wysyłki danych na zewnątrz.
6. Zapisuj prompty i wywołania narzędzi, żeby incydent dało się odtworzyć.

Każdy z tych kroków da się wdrożyć osobno, ale sens ma dopiero całość. Filtrowanie bez kontroli uprawnień chroni przed znanymi wzorcami, a nie przed nowym wariantem ataku.

Czego uczy przykład chatbotów PKO BP?

PKO BP rozwijało systemy konwersacyjne jako kanał obsługi klienta. W październiku 2024 r. bank informował o 17 botach, 10 mln klientów i ponad 50 mln rozmów [10][11]. Asystent głosowy IKO obsługiwał także przelewy, sprawdzanie salda, analizę wydatków i zmianę limitów kart [10].

Sama funkcjonalność nie dowodzi podatności na prompt injection. Pokazuje natomiast, gdzie trzeba rozdzielić generowanie odpowiedzi od wykonania operacji. Jeśli asystent potrafi zmienić limit karty, to uprawnienie musi przechodzić przez kontrolę dostępu i potwierdzenie użytkownika, a nie przez sam tekst polecenia [1].

W dostępnych źródłach nie ma potwierdzenia incydentu prompt injection w systemach PKO BP. Warto oddzielić dwa fakty: bank realnie używa botów i voicebotów, a phishing podszywający się pod PKO jest dokumentowany. Połączenie tych faktów w jeden atak wymagałoby dowodu, którego nie ma.

Więcej o praktyce budowania poleceń znajdziesz w artykule Inżynieria promptów: jak zacząć bez wydawania złotówki. O łańcuchach promptów i ich testowaniu pisze też tekst Datasette-llm 0.1a8: czy ta poprawka uratuje Twoje łańcuchy promptów?.

Najczęstsze pytania

Czy prompt injection można całkowicie wyeliminować?

Nie. NIST zaznacza, że dostępne zabezpieczenia nie dają pełnej ochrony [1]. Można natomiast ograniczyć skutki: oddzielić treści niezaufane, odebrać modelowi zbędne uprawnienia i wymagać zatwierdzenia przy operacjach nieodwracalnych. Celem nie jest zerowe ryzyko, a sytuacja, w której udany atak nie prowadzi do przelewu, wycieku danych ani zmiany uprawnień.

Jak odróżnić prompt injection od phishingu?

Phishing polega na podszywaniu się pod instytucję i skłonieniu człowieka do kliknięcia lub podania danych. Prompt injection polega na wprowadzeniu instrukcji do treści, którą przetwarza model. 20 marca 2024 r. CSIRT KNF opisywał fałszywą domenę pkobp.info, czyli klasyczny phishing [4]. W prompt injection ofiarą jest system, a nie osoba klikająca w link.

Czy filtrowanie słów kluczowych wystarcza?

Nie wystarcza. Atakujący formułuje polecenia zwykłym językiem, więc lista zakazanych fraz działa tylko na znane warianty. Filtrowanie ma sens jako jedna z warstw, obok separacji danych i kontroli uprawnień. Samo filtrowanie nie zatrzyma polecenia, które nie zawiera żadnego typowego słowa kluczowego, a mimo to zmienia zachowanie modelu.

Od czego zacząć w małej firmie?

Od inwentaryzacji integracji i odebrania zbędnych uprawnień. To najtańszy krok, który ogranicza skutki błędu w modelu. Następnie warto oznaczyć treści niezaufane i dodać zatwierdzenie człowieka przy operacjach nieodwracalnych. Dopiero potem ma sens inwestycja w filtrowanie i monitorowanie promptów, bo bez kontroli dostępu daje ograniczoną ochronę.

Źródła

1. NIST Trustworthy and Responsible AI NIST AI 600-1 (NIST, 2024)
2. NIST Trustworthy and Responsible AI NIST AI 100-2e2025 (NIST, 2025)
3. Prompt injection – czym jest, dlaczego stanowi ryzyko dla organizacji i jak je ograniczyć (Secawa, 2025)
4. PKO BP. Oszuści przygotowali fałszywą stronę bankowości elektronicznej PKO BP - CSIRT KNF ostrzega (TVN24, 2024)
5. Uwaga na fałszywe wiadomości podszywające się pod bank (PKO Bank Polski, 2024)
6. Ostrzeżenie PKO BP: Uważaj na fałszywe wiadomości i phishing (Hack.pl, 2024)
7. OWASP Top 10 for LLM Applications (Aembit, 2025)
8. OWASP Top 10 for LLMs 2025 (Trydeepteam, 2025)
9. NIST releases finalized guidelines on protecting AI from attacks (Nextgov/FCW, 2025)
10. Sztuczna inteligencja w PKO Banku Polskim przeprowadziła już 50 mln rozmów z klientami (Bankomania PKO BP, 2024)
11. PKO BP: Liczba rozmów klientów z voicebotami AI przekroczyła 50 mln (ISBiznes.pl, 2024)