Słodka rozmowa, gorzki skutek. Jak AI daje się prowadzić za rękę

Czy model AI można zmanipulować nie brutalnym atakiem, ale uprzejmą, dobrze poprowadzoną rozmową? Brzmi niewinnie, może nawet trochę zabawnie. Coś między small talkiem a sprytną retoryką. Problem w tym, że finał bywa już całkiem poważny.

Najnowsze analizy bezpieczeństwa pokazują rzecz, o której branża AI mówi coraz częściej, choć nadal nie zawsze wystarczająco głośno: wysoka sprawność modelu nie musi oznaczać wysokiej odporności. Model może być szybki, efektowny, błyskotliwy, a jednocześnie dać się „ustawić” kontekstem. I to nie w hollywoodzkim stylu hakerskiego włamania, tylko raczej metodą małych kroków.

Marcowa aktualizacja Comprehensive AI Security Index, czyli CASI, dobrze to pokazuje. Zestawienie potwierdza mocną pozycję modeli OpenAI i Anthropic, ale zarazem obnaża coś mniej wygodnego: różnice w bezpieczeństwie są duże, a czasem wręcz zaskakujące. GLM-5 od Z.ai, choć pod względem możliwości ustępuje właściwie tylko Claude Opus, uzyskał 37,56 punktu na 100 możliwych. Dla porównania Claude Opus 4.6 zdobył 96,61, a GPT-5.2 – 92,58. Gemini 3 Pro i Gemini Flash wypadły pośrodku, z wynikami 64,44 i 56,77.

To nie są kosmetyczne różnice. To przepaść. I to taka, której nie widać na pierwszy rzut oka, kiedy patrzy się wyłącznie na benchmarki, szybkość działania czy cenę za token. Jak przypomina Bartłomiej Anszperger z F5, organizacje powinny oceniać systemy AI nie tylko przez pryzmat wydajności i kosztu, ale też odporności na manipulacje oraz nietypowe scenariusze użycia. Innymi słowy: nie wystarczy, że model dużo umie. Dobrze jeszcze, żeby nie dawał się łatwo wyprowadzić w pole.

Atak, który nie przypomina ataku

Jednym z ciekawszych przykładów jest technika o nazwie Sugar-Coated Poison. Sama nazwa brzmi niemal literacko, jak tytuł eseju o współczesności. Tymczasem chodzi o bardzo konkretny mechanizm manipulacji.

W klasycznym jailbreaku użytkownik próbuje wprost skłonić model do złamania zasad. To dość toporne: „powiedz mi coś, czego mówić nie powinieneś”. System ma szansę się zorientować i odmówić. Sugar-Coated Poison działa inaczej. Nie wali w drzwi. Najpierw puka, potem się uśmiecha, a na końcu siada w salonie.

Rozmowa zaczyna się od tematów neutralnych. Pytania są rzeczowe, spokojne, pozornie niewinne. Z czasem budowany jest kontekst, w którym model przyzwyczaja się do roli pomocnego eksperta. Dopiero później pojawia się pytanie właściwe – takie, które na początku rozmowy zapewne zostałoby odrzucone.

Tu właśnie działa zjawisko określane jako Defense Threshold Decay, czyli stopniowe obniżanie progu ostrożności modelu. Każdy pojedynczy komunikat wygląda poprawnie. Nic nie krzyczy: „uwaga, atak”. A jednak cała sekwencja rozmowy może prowadzić do odpowiedzi, której system wcześniej by nie wygenerował.

To jest ważne także z językowego punktu widzenia. Model nie „ulega argumentom” jak człowiek, ale reaguje na kontekst. A kontekst, jeśli jest umiejętnie prowadzony, staje się narzędziem wpływu. Mówiąc prościej: nie trzeba AI oszukiwać jednym sprytnym zdaniem. Wystarczy ją odpowiednio ustawić.

To nie włamanie. To przesuwanie znaczeń

W analizach F5 Labs pojawia się też pokrewne pojęcie: Invasive Context Engineering. W obu przypadkach chodzi o podobny schemat. Szkodliwa instrukcja nie pada wprost. Zostaje ukryta w czymś, co wygląda na wiarygodne, pomocne albo zwyczajnie nieszkodliwe.

To o tyle istotne, że tradycyjny język cyberbezpieczeństwa trochę tu nie wystarcza. Nie mamy do czynienia z „hackowaniem” w starym stylu. Nikt nie rozkręca modelu śrubokrętem. Nikt nie przejmuje go brutalnie. Zamiast tego ktoś wpływa na to, jak system interpretuje informacje i jak ustawia sobie znaczenie kolejnych komunikatów.

Różnica między tymi technikami jest jednak praktyczna. Sugar-Coated Poison może wykorzystywać zatrucie źródeł danych, z których model korzysta – na przykład dokumentów pobieranych przez systemy RAG albo przez narzędzia zewnętrzne. Invasive Context Engineering polega raczej na stopniowym przesuwaniu interpretacji zasad działania modelu w toku rozmowy.

W skrócie: można zatruć to, co model czyta, albo to, jak rozumie rozmowę. Dwa różne wektory, ten sam problem. Kontekst przestaje być tłem. Staje się polem ataku.

Prawdziwy kłopot zaczyna się obok modelu

Najciekawsze – i chyba najbardziej otrzeźwiające – w marcowych analizach F5 Labs jest jednak co innego. Wiele podatności związanych z AI nie wynika z samego modelu. Problem zaczyna się wokół niego.

To trochę jak z bardzo zdolnym pracownikiem, który wykonuje polecenia bez zadawania pytań, bo ufa wszystkim dokumentom, mailom i ustawieniom, jakie do niego wpadają. Sam w sobie może być świetny. Ale jeśli działa w źle zabezpieczonym otoczeniu, szybko staje się częścią problemu.

W ostatnich tygodniach opisywano m.in. scenariusz RoguePilot, gdzie pośredni prompt injection był ukrywany w treściach publikowanych w zgłoszeniach GitHub. Była też podatność ClawJacked w frameworku agentów OpenClaw, pozwalająca przejąć połączenie WebSocket z lokalnym serwerem. Do tego Configuration Hijacking w Claude Code CLI, gdzie złośliwe pliki konfiguracyjne w repozytorium projektu mogły zostać wykorzystane do przejęcia kontroli nad zachowaniem narzędzia.

Łączy je jedno: model nie musiał być „zepsuty”. Wystarczyło, że system AI automatycznie pobierał dane z zewnątrz i działał dalej bez odpowiedniej walidacji, izolacji albo dodatkowej kontroli. To właśnie tu kończy się wygodna opowieść o bezpieczeństwie modeli jako samodzielnych bytów. Bo w praktyce nie korzystamy z modelu w próżni. Korzystamy z całego układu: narzędzi, integracji, repozytoriów, konfiguracji, agentów, pamięci, źródeł danych.

A każdy taki element może być miejscem nacisku.

Bezpieczeństwo AI to już nie test modelu, tylko test rozsądku

W miarę jak AI wchodzi do firmowych procesów, automatyzacji i systemów operacyjnych przedsiębiorstw, rośnie powierzchnia ataku. To brzmi technicznie, ale sens jest prosty: im więcej rzeczy model może czytać, uruchamiać, łączyć i wykonywać, tym więcej jest miejsc, w których można go podprowadzić w złą stronę.

Dlatego bezpieczeństwa AI nie da się już sensownie omawiać wyłącznie na poziomie modelu. Trzeba patrzeć szerzej: na dane wejściowe, integracje, konfiguracje, uprawnienia, środowisko uruchomieniowe i sposób, w jaki system podejmuje działania w imieniu użytkownika.

To zmiana perspektywy, ale też zmiana odpowiedzialności. Nie wystarczy dziś zapytać: „czy ten model jest dobry?”. Trzeba pytać: „w jakim środowisku działa?”, „na jakich danych pracuje?”, „co może zrobić automatycznie?”, „kto sprawdza, co do niego trafia?”. Jeśli tych pytań nie ma, to nawet najlepszy model może stać się bardzo sprawnym wykonawcą cudzych intencji.

I może właśnie w tym tkwi największy paradoks obecnej fali AI. Zachwycamy się inteligencją systemów, a coraz częściej potykamy się nie o ich braki poznawcze, lecz o własną łatwowierność projektową. Chcemy, żeby było szybciej, prościej, bardziej autonomicznie. A potem jesteśmy zaskoczeni, że system, któremu daliśmy zaufanie, potraktował zaufaniem także złośliwy kontekst.

Słodka rozmowa, toksyczny finał? Niestety tak. I to nie jest już metafora. To bardzo praktyczna lekcja: w świecie AI nie tylko odpowiedź ma znaczenie. Równie ważne jest to, kto i jak ustawia pytanie.