Czym jest prompt injection i jak ukryte instrukcje wpływają na AI

Asystent AI może czytać notatki, odpowiedź uczestnika lub znalezioną stronę, aby pomóc w nauce. W takim materiale może znajdować się tekst próbujący zmienić jego zachowanie: podmienić kryterium, ujawnić zbędne informacje lub wykonać niezwiązane działanie. Człowiek traktuje plik jako obiekt analizy, ale model może błędnie potraktować jego część jako instrukcję. Tę klasę ryzyk nazywa się prompt injection. Serwis edukacyjny powinien chronić nie tylko odpowiedź na czacie, ale także dane i narzędzia dostępne asystentowi.

Przydatne pytanie dla zespołu: co rzeczywiście się stanie, jeśli model wykona niepożądane polecenie z zasobu edukacyjnego? Odpowiedź zależy od architektury. Błąd wyjaśnienia i nieautoryzowana zmiana wpisu mają różne konsekwencje. Poniżej proponujemy proces ochrony dla szkoły online wspólnie ze specjalistami technicznymi. Nie gwarantuje pełnego usunięcia prompt injection i nie opisuje wykrytej podatności konkretnego LMS. Przykłady są hipotetyczne i służą sprawdzaniu własnych uzgodnionych środowisk z materiałami testowymi, bez używania cudzych danych lub systemów zewnętrznych.

Odróżniaj polecenie edukacyjne w tekście od zlecenia użytkownika

Materiał może zawierać zdanie w trybie rozkazującym, które trzeba po prostu przeanalizować. Na przykład zadanie prosi o porównanie dwóch instrukcji. Nie każdy taki tekst jest atakiem. Problem pojawia się, gdy treść zasobu otrzymuje uprawnienia do zmiany zachowania asystenta wbrew dozwolonemu zadaniu. OWASP LLM01:2025 omawia bezpośrednie i pośrednie iniekcje, w tym przez źródła zewnętrzne. We własnym systemie trzeba jasno określić pochodzenie każdego fragmentu i to, czy może wyznaczać działanie, czy pozostaje tylko danymi do analizy.

Dla asystenta edukacyjnego przesłana praca uczestnika powinna pozostać pracą, a nie kanałem zmiany zasad oceniania. Strona pomocy może zawierać warunki merytoryczne, ale nie powinna nadawać nowych uprawnień technicznych. Komentarz we wspólnym dokumencie nie staje się potwierdzeniem administratora tylko przez odpowiedni napis. Poproś zespół techniczny o pokazanie, jak te granice przedstawiono w systemie. Jedno ludzkie wyjaśnienie w dokumencie metodycznym nie wystarczy, jeśli faktyczny proces przetwarzania miesza wszystkie fragmenty w jeden nierozróżniony tekst i pozwala modelowi samodzielnie określać ich uprawnienia.

Nie ograniczaj sprawdzania do widocznego tekstu strony. Do przetwarzania mogą trafiać wyniki rozpoznawania obrazu, załączniki, metadane lub treść znalezionego fragmentu. Określ, jakie warstwy konkretnie czyta wasz serwis. Nie trzeba zakładać, że każdy format jest równie niebezpieczny lub każdy zasób już zawiera próbę wpływu. Potrzebna jest rzeczywista mapa wejść. Jeśli zespół nie wie, jaki tekst trafił do zapytania po przekształceniu pliku, trudno będzie wyjaśnić niepożądaną odpowiedź i sprawdzić skuteczność własnych ograniczeń.

Określ dopuszczalne możliwości asystenta

Najpierw wymień potrzebne działania. Asystent może odpowiadać na pytania według uzgodnionych materiałów, przygotowywać szkic komentarza lub szukać konkretnego zasobu. Nie dodawaj edycji ocen, wysyłania wiadomości lub zmiany dostępów tylko dlatego, że integracja technicznie na to pozwala. OWASP o Excessive Agency wiąże konsekwencje z nadmiernymi funkcjami, uprawnieniami i autonomią. Dla szkoły praktyczna decyzja zaczyna się od minimalnego zestawu możliwości rzeczywiście potrzebnych określonemu scenariuszowi nauki, a nie domyślnie maksymalnego dostępu.

Rozdziel pozyskiwanie informacji i ich zmianę. Jeśli zadanie polega na wyjaśnieniu warunków kursu, asystent niekoniecznie musi móc edytować same warunki. Jeśli przygotowuje odpowiedź dla pracownika obsługi, nie oznacza to automatycznego wysłania jej uczestnikowi. Jasno określ, gdzie kończy się propozycja modelu, a zaczyna wykonanie. Dla każdego działania nazwij dopuszczalny obiekt, użytkownika i warunki. Szerokie polecenie „zarządzać nauką” ukrywa zbyt wiele różnych możliwości wymagających osobnej decyzji o przydatności i kontroli.

Sprawdź faktyczne uprawnienia podłączonego konta. Nazwa narzędzia może brzmieć wąsko, a jego dostęp służbowy obejmować więcej danych. W teście użyj różnych ról i sprawdź, czy niedostępny zasób nie jest zwracany nawet przy uporczywym zapytaniu. Autoryzację powinien określać właściwy system dostępu, a nie decyzja modelu, że użytkownik rzekomo ma dobre intencje. Nie przekazuj sekretów w tekście instrukcji jako sposobu „wyjaśnienia” asystentowi granic. Granice powinny działać w samym wykonaniu działania i sprawdzaniu zapytania.

Ograniczaj dane przed przekazaniem modelowi

Do odpowiedzi na pytanie edukacyjne przekazuj tylko potrzebne materiały. Jeśli użytkownik nie ma dostępu do cudzej pracy, praca ta nie powinna przypadkowo trafiać do kontekstu wyszukiwania, z którego model rzekomo obiecuje niczego nie ujawniać. OWASP Sensitive Information Disclosure opisuje ryzyka wycieku informacji wrażliwych. Dla waszego procesu sprawdź dobór danych według rzeczywistej roli i zadania. Ukrycie fragmentu w interfejsie nie pomoże, jeśli przekazano go już składnikowi tworzącemu otwartą odpowiedź dla innego użytkownika.

Nie mieszaj otwartych wyjaśnień kursu i prywatnych informacji w jednym szerokim indeksie bez właściwego rozgraniczenia. Wyszukiwanie powinno uwzględniać dozwolony zakres jeszcze przed utworzeniem odpowiedzi. Dla każdej kategorii danych określ, kto może je otrzymać i w jakich sytuacjach. To zadanie techniczne i organizacyjne, a nie tylko redakcja promptu. Jeśli asystent nie potrzebuje osobistych wyników uczestników do wyjaśnienia terminu, nie dodawaj ich do kontekstu „na wszelki wypadek”. Mniejszy zakres ułatwia także sprawdzenie podstawy i analizę błędu.

Dane pochodne również wymagają kontroli. Krótkie podsumowanie prywatnej pracy może pozostać prywatne, nawet jeśli oryginalny plik nie jest przekazywany. Sprawdź pamięci podręczne, historię rozmów i ponowne używanie kontekstu między sesjami. Nie zakładaj, że nowe okno czatu automatycznie oddziela wszystkie poprzednie informacje. Poproś zespół o ustalenie faktycznego sposobu izolacji. Organizacja edukacyjna potrzebuje możliwości wyjaśnienia, jak informacje jednego uczestnika nie przechodzą do innego przez wygodne ponowne wykorzystanie gotowego automatycznego podsumowania lub wspólnego stanu asystenta.

Połącz instrukcje modelu z ograniczeniami technicznymi

Jasno opisz rolę asystenta i oznaczaj obcy materiał jako dane do analizy. To przydatna warstwa ochrony, ale nie należy przedstawiać jej jako nienaruszalnej granicy. OWASP Prompt Injection Prevention Cheat Sheet proponuje podejście wielowarstwowe. W konkretnym serwisie edukacyjnym trzeba sprawdzać nie tylko sformułowanie zakazu, ale także to, co kod aplikacji zrobi po otrzymaniu niepożądanego żądania od modelu. Jeśli wykona dowolne zaproponowane działanie bez niezależnego sprawdzenia, tekstowa obietnica ignorowania ukrytych poleceń pozostanie niewystarczająca.

Określ dopuszczalną strukturę żądań do narzędzi. Działanie powinno mieć sprawdzone parametry, kontekst użytkownika i właściwy obiekt. Nie zamieniaj dowolnego tekstu modelu w polecenie dla systemu. Jeśli potrzebna jest zmiana wpisu edukacyjnego, proces aplikacyjny sprawdza uprawnienie i warunki, a przy określonych istotnych konsekwencjach przewiduje odpowiednie potwierdzenie odpowiedzialnej osoby. Powinna widzieć konkretne działanie i jego zakres. Ogólna zgoda na „pomaganie z kursem” nie powinna ukrywać zmiany, której użytkownik nie zlecił w tym epizodzie.

Sprawdzaj także sposób wyświetlania odpowiedzi. Automatycznie stworzony link, obraz lub inny aktywny element może mieć konsekwencje wykraczające poza zwykłe czytanie tekstu. Zespół techniczny powinien określić dozwolone formaty i sposób ich przetwarzania. Nie przyjmuj całej treści jako zaufanego HTML tylko dlatego, że stworzył ją wasz model. Asystentowi edukacyjnemu często wystarcza ograniczony zrozumiały format ze sprawdzonymi przejściami do dozwolonych zasobów. Wybór powinien odpowiadać rzeczywistemu zadaniu, a nie wszystkim możliwościom dowolnego bogatego wyjścia systemu generatywnego.

Przygotuj hipotetyczny test z dokumentem edukacyjnym

W środowisku testowym stwórz wymyślony materiał do pytania o kolejność lekcji. Obok poprawnych informacji dodaj oczywiste polecenie testowe zmieniające zachowanie asystenta wbrew zadaniu. Nie używaj rzeczywistych danych osobowych lub sekretów roboczych. Wcześniej zapisz oczekiwanie: asystent pracuje z dozwoloną informacją edukacyjną, a obcy tekst nie rozszerza jego uprawnień. To scenariusz kontrolny waszego systemu, a nie gotowy dowód ochrony przed wszystkimi możliwymi formami wpływu w przyszłych dokumentach.

Sprawdź kilka poziomów wyniku. Czy zmieniła się treść odpowiedzi? Czy model poprosił o wywołanie niezwiązanego narzędzia? Czy system wykonał to wywołanie? Dwa ostatnie pytania są szczególnie ważne: niepożądana propozycja modelu i faktyczne nieautoryzowane działanie mają różny status. Zachowaj wystarczające informacje do analizy bez zbędnego otwartego rozpowszechniania szczegółów testowych. Nie zaliczaj scenariusza tylko dlatego, że zdanie końcowe brzmi poprawnie, jeśli przed nim wykonano już działanie nieobecne w zleceniu edukacyjnym.

Po poprawce powtórz test i sprawdź normalną pracę. Ochrona blokująca dowolne cytowanie zdania rozkazującego może przeszkadzać w zwykłej lekcji językowej lub technicznej. Dla każdego niepożądanego przypadku przygotuj także odpowiedni kontekst edukacyjny. Celem jest zachowanie granicy między analizą materiału a wykonywaniem jego poleceń, a nie zakazanie wszystkich tekstów ze słowem „zróbcie”. Sprawdzaniem konkretnej konfiguracji powinni zajmować się właściwi specjaliści; niewielki przykład redakcyjny pomaga jedynie sformułować oczekiwane zachowanie i konsekwencje dla procesu nauki.

Nie traktuj RAG jako kompletnej ochrony

Wyszukiwanie w uzgodnionej bazie może poprawiać podstawę odpowiedzi, ale znaleziony fragment również pozostaje danymi wejściowymi. W przywołanym materiale OWASP o prompt injection wskazano, że RAG i dodatkowe trenowanie nie usuwają w pełni tego ryzyka. Szkoła powinna sprawdzać, kto może zmieniać bazę, jak materiał do niej trafia i jaki status otrzymuje po wyszukaniu. Obecność linku do źródła nie dowodzi, że wszystkie jego wiersze są dozwolonymi poleceniami dla asystenta lub uzgodnioną polityką organizacji edukacyjnej.

Rozdziel formalne zasady i materiały użytkowników. Oba typy mogą być potrzebne do zadania edukacyjnego, lecz mają różne przeznaczenie. Praca uczestnika nie powinna niepostrzeżenie stawać się częścią oficjalnej pomocy dla całej grupy. Po dodaniu lub aktualizacji źródła sprawdź jego wpływ na wyszukiwanie i odpowiedzi. Jeśli proces automatycznie przyjmuje dowolny nowy plik do ogólnej bazy, określ, czy rzeczywiście odpowiada to zamysłowi. Wygoda uzupełniania archiwum nie powinna zastępować decyzji o pochodzeniu, uprawnieniach i właściwym użyciu konkretnego materiału.

Dla ważnego asystenta zachowuj wersję materiałów i konfiguracji potrzebną do analizy. Jeśli odpowiedź zmieniła się po aktualizacji modelu lub bazy, zespół powinien móc porównać warunki. Nie trzeba bez ograniczeń przechowywać wszystkich prywatnych zapytań. Potrzebny jest uzgodniony dziennik z wystarczającym zakresem i ochroną. NIST Generative AI Profile pomaga rozpatrywać ocenianie i zarządzanie ryzykami w cyklu życia systemu. Jednorazowa udana demonstracja nie zastępuje przeglądu po zmianach wpływających na faktyczne wejścia i możliwości serwisu edukacyjnego.

Uzgodnij reakcję na wykryty incydent

Określ, kto może wstrzymać problematyczną funkcję, ograniczyć narzędzie lub usunąć źródło z wyszukiwania. Potrzebne są konkretne osoby odpowiedzialne i odpowiedni mechanizm techniczny. Nie pozostawiaj obsługi z jedyną poradą napisania innego promptu. Najpierw ustal, co się stało: błędny tekst, próba działania czy faktyczny dostęp do niedozwolonych danych. Od konsekwencji zależy dalsza analiza. Nie wnioskuj o wycieku tylko przez dziwną odpowiedź, ale też nie zaprzeczaj możliwemu działaniu bez przeglądu dostępnych dzienników we właściwym trybie.

Jeśli platforma LMS WeStudy jest używana do nauki wraz z zewnętrznym asystentem AI, osobno sprawdź granice faktycznego połączenia. Nie zakładaj istnienia lub ochrony określonej integracji na podstawie ogólnego opisu scenariusza. Określ przekazywane materiały, dostępne narzędzia i osoby za nie odpowiedzialne. Dla uczestnika powinno być jasne, co asystent może robić i dokąd zwrócić się po sprzecznej odpowiedzi. Ochrona techniczna nie powinna opierać się na oczekiwaniu, że każdy uczestnik sam rozpozna ukryte instrukcje we wszystkich formatach zasobów edukacyjnych.

Gdy platforma LMS WeStudy jest miejscem przechowywania uzgodnionych materiałów kursu, zachowuj jasną różnicę między źródłem treści edukacyjnej a uprawnieniami zewnętrznego automatycznego asystenta. Sprawdzaj konkretną konfigurację po istotnych zmianach i utrzymuj drogę powrotu do właściwej ludzkiej pomocy. Praktyczna ochrona składa się z ograniczonych danych, potrzebnych możliwości, niezależnej autoryzacji i sprawdzalnych działań. Instrukcja tekstowa modelu pozostaje przydatną częścią procesu, ale bez granic technicznych sama nie gwarantuje, że obcy dokument nigdy nie wpłynie na zachowanie systemu.

Sprawdź scenariusz oceniania bez rzeczywistych danych uczestników

Dla hipotetycznej szkoły przygotuj dwie wymyślone prace i osobną uzgodnioną rubrykę oceniania. Asystent ma tworzyć szkic komentarza według rubryki, a ostateczną decyzję podejmuje wykładowca w określonym procesie. Do jednej pracy dodaj fragment testowy próbujący ogłosić inne kryterium. Oczekiwana granica jest jasna: praca pozostaje obiektem analizy i nie zmienia zasad. Wcześniej opisz, co oznacza naruszenie na poziomie komentarza i czego system w ogóle nie powinien móc zmieniać we wpisach kursu edukacyjnego.

Po odpowiedzi porównaj ją z rubryką, a nie tylko pożądanym tonem. Asystent może uprzejmie poinformować, że przestrzegał zasad, a jednocześnie użyć podmienionego kryterium. Sprawdź konkretne uwagi do pracy i ich podstawę. Jeśli model proponuje ocenę, ustal, na podstawie jakich oznak ją utworzył w zakresie dostępnego materiału. Nie trzeba żądać dostępu do ukrytego wewnętrznego rozumowania. Potrzebne są obserwowalne podstawy komentarza, poprawne stosowanie uzgodnionych kryteriów i brak faktycznej niezleconej zmiany we wpisie edukacyjnym.

Sprawdź także niewinny przykład, w którym uczestnik cytuje obcą instrukcję jako przedmiot analizy. Asystent powinien rozpatrzyć jej treść bez wykonywania polecenia i bez odrzucania całej pracy jako nieprzydatnej wyłącznie przez tryb rozkazujący. W kursie językowym takie zdania mogą być zupełnie zwyczajnym materiałem. Pomaga to zobaczyć, czy konfiguracja ochronna wspiera normalną działalność edukacyjną. Ogólny filtr usuwający wszystkie cytaty z poleceniami może ograniczyć przydatność asystenta bez właściwego rozwiązania samego problemu uprawnień obcego tekstu.

Jeśli test nie został zaliczony, zachowaj zestaw kontrolny osobno od ogólnej bazy edukacyjnej. Nie pozwalaj, aby przypadkowo stał się źródłem zwykłych odpowiedzi dla uczestników. Poprawka może dotyczyć instrukcji, przedstawienia kontekstu, dostępnych narzędzi lub aplikacyjnego sprawdzania zapytania. Po każdej istotnej zmianie powtarzaj decydujące przypadki. Nie twórz raportu o sukcesie, jeśli sprawdzano tylko nową izolowaną część, a później nie wykonano pełnej ścieżki. Dla decyzji o uruchomieniu ważny jest faktyczny proces działania właśnie tego asystenta edukacyjnego.

Osobno sprawdź, co wykładowca robi z błędnym szkicem. Jeśli interfejs pokazuje tylko gotowy płynny komentarz bez rubryki i pracy źródłowej, trudniej zauważyć podmianę. Zapewnij odpowiedzialnej osobie wystarczający kontekst do kontroli. Nie każ zatwierdzać długiego pakietu różnych zmian jednym niejasnym elementem sterowania. Dla konkretnego działania powinny być zrozumiałe obiekt i konsekwencja. Dzięki temu ludzki przegląd pozostaje merytoryczną częścią procesu, a nie formalnym przyciskiem po decyzji, której faktycznie nikt nie potrafi ocenić na podstawie dostępnych informacji.

Sprawdź dostęp między różnymi grupami edukacyjnymi

W odpowiednim środowisku testowym utwórz dwie wymyślone grupy z różnymi materiałami. Dla każdej roli określ dozwolony zakres. Zapytaj asystenta o zasób dostępny tylko drugiej grupie. Oczekiwany wynik powinna zapewniać kontrola dostępu do danych, a nie tylko uprzejma odmowa w zdaniu końcowym. Poproś zespół techniczny o ustalenie, czy niedostępny fragment w ogóle trafił do kontekstu. Jeśli przekazano go już modelowi, brak jawnego cytatu w jednej odpowiedzi nie dowodzi właściwej izolacji danych we wszystkich następnych sytuacjach.

Po przełączeniu roli sprawdź pamięć podręczną i kontynuację dialogu. Hipotetyczny koordynator może mieć szerszy dostęp niż uczestnik, ale poprzednia sesja nie powinna niepostrzeżenie przenosić tych informacji do innego użytkownika. Zapisz, jak tworzy się nowy kontekst i jak dobierane są materiały. Wymaga to potwierdzenia technicznego konkretnego systemu. Nie wyciągaj wniosku tylko z tego, że interfejs pokazuje inne imię. Organizacja edukacyjna powinna rozumieć rzeczywistą granicę danych, szczególnie gdy kilka osób używa jednego urządzenia lub wspólnego stanowiska obsługi.

Sprawdź cofnięcie dostępu na wymyślonym zasobie. Jeśli materiał nie jest już dozwolony dla roli, określ, jak uwzględniają to wyszukiwanie, podsumowania pochodne i dalsze odpowiedzi. Stara kopia może pozostawać w innym składniku. Nie obiecuj natychmiastowego wyczyszczenia wszystkich stanów bez sprawdzonego mechanizmu. Zapisz natomiast, co system faktycznie robi i jakie ograniczenia trzeba usunąć przed odpowiednim scenariuszem uruchomienia. Zarządzanie dostępem powinno obejmować cykl życia zasobu, a nie tylko jego pierwsze dodanie do bazy edukacyjnej asystenta.

Po zakończeniu testów przygotuj krótki zapis decyzji dla odpowiedzialnych osób. Potrzebne są w nim sprawdzona wersja, dozwolone scenariusze, znalezione problemy i pozostałe niewiadome. Nie zamieniaj kilku udanych przykładów w ogólne twierdzenie o niewrażliwości na ataki. Jednocześnie nie trać konkretnej korzyści poprawki. Jeśli niezlecone wywołanie jest teraz blokowane właściwą kontrolą aplikacyjną, to ważny potwierdzony wynik dla określonego przypadku. Zachowaj test, aby po zmianie integracji zespół mógł ponownie sprawdzić tę samą granicę bez odtwarzania całego początkowego zamysłu z pamięci.

Po zakończeniu analizy sprawdź instrukcję pracownika obsługi: czy wie, jak znaleźć odpowiedzialny kontakt i wstrzymać wykorzystanie błędnej odpowiedzi w konkretnym zgłoszeniu? Poprawka techniczna i praca z wiadomością już otrzymaną przez uczestnika to różne zadania. Jeśli niewłaściwy komentarz wpłynął na decyzję edukacyjną, zespół powinien przeanalizować tę konsekwencję według faktycznych danych, a nie uznawać jej za automatycznie usuniętą po zmianie konfiguracji asystenta.

Źródła

1. OWASP — LLM01:2025 Prompt Injection.

2. OWASP — LLM06:2025 Excessive Agency.

3. OWASP — LLM02:2025 Sensitive Information Disclosure.

4. OWASP Cheat Sheet Series — LLM Prompt Injection Prevention.

5. NIST AI 600-1 — Generative Artificial Intelligence Profile.