Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali nową technikę ataku na modele językowe i systemy agentowe, określaną jako Cryptographic Context Injection. Mechanizm polega na ukrywaniu złośliwych instrukcji w zaszyfrowanej postaci, dzięki czemu klasyczne filtry bezpieczeństwa nie są w stanie ocenić ich treści przed wykonaniem. Dopiero środowisko uruchomieniowe modelu, takie jak sandbox Pythona, odszyfrowuje ładunek i zamienia go w pozornie zaufany kontekst operacyjny.
To istotna zmiana w sposobie prowadzenia prompt injection. Zamiast przesyłać szkodliwe polecenia wprost, atakujący dostarcza zaszyfrowany obiekt oraz instrukcję jego odszyfrowania już wewnątrz systemu. W efekcie zagrożenie dotyczy nie tylko samego modelu, ale całego łańcucha zaufania obejmującego parsery, runtime, narzędzia agentowe i kontrolę ruchu wychodzącego.
W skrócie
- Cryptographic Context Injection ukrywa złośliwe instrukcje w szyfrogramie niewidocznym dla standardowych filtrów.
- W opisanych scenariuszach technika działała przeciwko Grokowi oraz w określonych warunkach przeciwko Gemini.
- W przypadku Groka mogła prowadzić do bezklikowej eksfiltracji danych sesji przez funkcje przeglądania i wywołań narzędzi.
- W przypadku Gemini umożliwiała obejście polityk bezpieczeństwa i generowanie treści zwykle blokowanych.
- Problem ma charakter architektoniczny i dotyczy agentów AI korzystających z kodu, narzędzi i zewnętrznych źródeł danych.
Kontekst / historia
Prompt injection od dawna pozostaje jednym z najważniejszych problemów bezpieczeństwa w systemach opartych na LLM. Tradycyjne ataki polegały na umieszczaniu jawnych instrukcji w treści promptu albo na stronach internetowych analizowanych przez agenta. W odpowiedzi dostawcy modeli rozwijali filtry wejściowe, klasyfikatory treści, ograniczenia narzędzi oraz zabezpieczenia przed ujawnianiem promptów systemowych.
Nowa technika pokazuje jednak zmianę paradygmatu. Zamiast próbować przemycić niebezpieczny tekst przez klasyfikator, przeciwnik przekazuje zaszyfrowany ładunek, którego intencji nie da się wiarygodnie ocenić bez odszyfrowania. Gdy plaintext zostanie odzyskany wewnątrz zaufanego środowiska wykonawczego, system może przypisać mu wyższy poziom wiarygodności niż zwykłej treści pochodzącej z internetu lub od użytkownika.
Opisane przypadki sugerują, że skuteczność podobnych ataków może zależeć od konkretnej implementacji modelu, filtrów i logiki orkiestracji. Jednocześnie sam wektor zagrożenia pozostaje istotny, ponieważ uderza w sposób, w jaki platformy AI łączą model, narzędzia oraz wykonanie kodu.
Analiza techniczna
Sednem ataku jest przeniesienie złośliwej treści z warstwy wejściowej do warstwy wykonawczej. Guardraile zazwyczaj analizują tekst, ale nie uruchamiają kodu ani nie odszyfrowują danych z użyciem pełnych prymitywów kryptograficznych. Jeśli model otrzyma ciphertext, materiał kluczowy i instrukcję użycia runtime’u do odzyskania plaintextu, właściwy payload może zostać ujawniony dopiero po przejściu kontroli bezpieczeństwa.
Atak przebiega zwykle wieloetapowo. Najpierw chatbot lub agent odbiera dane zawierające zaszyfrowany obiekt. Następnie zostaje nakłoniony do uruchomienia kodu, który odszyfruje zawartość. Po odzyskaniu plaintextu szkodliwe instrukcje nie występują już jako obcy tekst wejściowy, lecz jako wynik działania własnego środowiska uruchomieniowego systemu. To moment krytyczny, ponieważ dochodzi do eskalacji zaufania wobec danych kontrolowanych wcześniej przez atakującego.
W scenariuszu dotyczącym Groka badacze opisali użycie funkcji przeglądania stron przez agenta. Użytkownik miał jedynie poprosić system o analizę spreparowanej witryny. Strona zawierała zaszyfrowany obiekt JSON i instrukcje odszyfrowania przez runtime Pythona. Odszyfrowany payload miał następnie skłaniać agenta do sięgnięcia po prywatny kontekst sesji i przekazania tych danych do zewnętrznego żądania sieciowego, co prowadziło do eksfiltracji bez dodatkowej interakcji użytkownika.
W przypadku Gemini mechanizm miał wspierać bezpośredni prompt injection. Odszyfrowany plaintext był konstruowany tak, aby wyglądał jak wiarygodny artefakt wykonania, na przykład komunikat błędu lub ślad działania narzędzia. Dzięki temu model mógł potraktować treść jako część własnego procesu operacyjnego i wygenerować odpowiedź, która w normalnych warunkach zostałaby zatrzymana przez polityki bezpieczeństwa.
Z perspektywy architektury bezpieczeństwa jest to forma „prania zaufania” przez runtime. Dane pochodzące z niezaufanego źródła przechodzą przez mechanizm wykonawczy i wracają do modelu jako pozornie legalny, wewnętrzny kontekst.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość obejścia kontroli bezpieczeństwa bez naruszania samego modelu na poziomie wag czy infrastruktury. Atak wykorzystuje warstwę orkiestracji agentowej, która często ma dostęp do przeglądania internetu, plików, repozytoriów, API i danych organizacyjnych. Jeśli odszyfrowany payload może sterować tymi narzędziami, ryzyko obejmuje eksfiltrację danych, nieautoryzowane żądania sieciowe, ujawnienie promptów systemowych oraz generowanie niedozwolonych treści.
Zagrożenie rośnie szczególnie w środowiskach firmowych, gdzie agent AI działa na dokumentach wewnętrznych, kodzie źródłowym, zgłoszeniach serwisowych lub danych klientów. Nawet pojedynczy kanał wyjściowy może wystarczyć do wycieku informacji, a incydent może pozostać mało widoczny, ponieważ z perspektywy użytkownika system wykonuje tylko pozornie rutynowe zadania.
Atak podważa też skuteczność strategii bezpieczeństwa opartych wyłącznie na filtrach wejścia i wyjścia. Jeśli organizacja nie monitoruje warstwy pośredniej, czyli wykonania kodu, transformacji danych oraz integracji narzędzi, może nie wykryć nadużyć zachodzących już po formalnym przejściu przez guardraile.
Rekomendacje
Organizacje wdrażające agentów AI powinny potraktować runtime oraz toolchain jako krytyczny element powierzchni ataku. Kluczowe jest zachowanie informacji o pochodzeniu danych na każdym etapie ich przetwarzania. Odszyfrowane treści nie mogą automatycznie zyskiwać statusu zaufanego tylko dlatego, że zostały wygenerowane przez wewnętrzne środowisko wykonawcze.
- Wprowadzić ścisłe tagowanie provenance dla danych pochodzących od użytkownika, z internetu, z plików i z narzędzi.
- Ograniczyć przepływ danych między sandboxem a narzędziami uprzywilejowanymi, zwłaszcza funkcjami sieciowymi.
- Zmniejszyć możliwości runtime’u, wyłączając zbędne biblioteki kryptograficzne i dostęp do sieci tam, gdzie to możliwe.
- Oddzielić wykonanie kodu pomocniczego od wrażliwego kontekstu sesji użytkownika.
- Monitorować całe sekwencje działań, a nie tylko pojedyncze prompty lub odpowiedzi.
- Rozszerzyć testy red-teamowe o scenariusze wykorzystujące szyfrowanie, pośredni prompt injection i nadużycie narzędzi agentowych.
Podsumowanie
Cryptographic Context Injection pokazuje, że bezpieczeństwo systemów AI nie kończy się na filtrach promptów. Gdy model ma dostęp do środowiska wykonawczego i narzędzi agentowych, złośliwe instrukcje mogą zostać ukryte w szyfrogramie, odszyfrowane wewnątrz systemu i potraktowane jako wiarygodny kontekst operacyjny.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest architektoniczny: ochroną trzeba objąć nie tylko wejście i wyjście modelu, ale również wszystkie kanały pośrednie, w których niezaufane dane mogą zostać awansowane do roli zaufanych instrukcji. W praktyce oznacza to większy nacisk na kontrolę pochodzenia danych, ograniczanie uprawnień narzędzi oraz monitorowanie pełnego łańcucha działań agenta AI.
Źródła
- SecurityWeek — Encrypted Prompts Bypass AI Safety Guardrails in Grok and Gemini — https://www.securityweek.com/encrypted-prompts-bypass-ai-safety-guardrails-in-grok-and-gemini/
- Adversa AI — Zero-click Grok data theft: Cryptographic Context Injection attack leaks chat histories — https://adversa.ai/blog/cryptographic-context-injection-grok-data-theft/