Cryptographic Context Injection: Gdy zaszyfrowane ataki oślepiają zabezpieczenia AI
Nowy atak systematycznie oślepiający filtry bezpieczeństwa AI
Krajobraz bezpieczeństwa wokół dużych modeli językowych (LLM) regularnie pęka w nowych miejscach – jednak najnowsze odkrycie firmy bezpieczeństwa Adversa stanowi jakościowy przełom. Pod pojęciem Cryptographic Context Injection badacze opisali technikę, która nie opiera się już na prymitywnie sformułowanych szkodliwych poleceniach, lecz na kryptografii: właściwe polecenia ataku są przesyłane w zaszyfrowanej formie i dopiero w obrębie środowiska wykonawczego modelu odszyfrowywane – w obszarze, do którego klasyczne filtry bezpieczeństwa po prostu nie mają wglądu.
Konkretnie technikę zademonstrowano przeciwko Grok – LLM firmy xAI. Badaczom udało się skłonić asystenta AI do przesłania danych użytkowników – w tym imienia, lokalizacji i historii czatów – na zewnętrzny serwer. Atak został zgłoszony firmie już w czerwcu; w momencie publikacji luka pozostawała niezałatana. Podobne wektory zaobserwowano również w przypadku Microsoft 365 Copilot oraz Google Gemini, co wyraźnie podkreśla zasięg problemu.
Jak technicznie działa Cryptographic Context Injection
Aby zrozumieć skalę problemu, warto przyjrzeć się mechanizmowi: klasyczne ataki Prompt-Injection przemycają szkodliwe polecenia do treści, które asystent AI ma przetworzyć – na przykład do e-maili lub stron internetowych, które model ma streścić. LLM strukturalnie nie są w stanie wiarygodnie odróżnić, czy polecenie pochodzi od autoryzowanego użytkownika, czy od zmanipulowanego dokumentu. To nie jest błąd, lecz fundamentalna cecha paradygmatu trenowania: model jest zoptymalizowany pod kątem wykonywania poleceń.
Dotychczasowe środki zaradcze opierają się na tzw. statycznych filtrach bezpieczeństwa (Guardrails), które sprawdzają przychodzące i wychodzące teksty pod kątem podejrzanych wzorców. Właśnie tu wkracza Cryptographic Context Injection:
- Atakujący umieszcza zaszyfrowany szkodliwy kod (Ciphertext) na stronie internetowej – wraz z kluczem deszyfrującym i poleceniem odszyfrowania tego kodu.
- Asystent AI otrzymuje niewinne zadanie streszczenia strony.
- Model samodzielnie przeprowadza deszyfrowanie w swojej piaskownicy do wykonywania kodu (Code-Execution-Sandbox) – przy użyciu algorytmów takich jak PBKDF2 i AES-256-GCM.
- Filtr bezpieczeństwa w żadnym momencie nie widzi tekstu jawnego szkodliwego polecenia, ponieważ nie wykonuje kodu, lecz jedynie klasyfikuje tekst.
- Odszyfrowane polecenia docierają do modelu jako jego własny wynik narzędzia (Tool-Output) – i są wykonywane bez dalszej weryfikacji.
Kluczowe zdanie badacza Adversa, Rony'ego Utevsky'ego, ujmuje istotę problemu w pigułce:
„Static safety guardrails classify inputs as text; they do not execute them. An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox."
Temu, czego brakuje skanerom Guardrail, jest zdolność do dynamicznej interpretacji kodu w czasie inspekcji. Ładunek szkodliwy jest zaszyfrowany i niewidoczny – aż do momentu, gdy sam model czyni go widocznym.
Dlaczego to problem strukturalny, a nie specyficzny dla danego produktu
Wygodnie byłoby zbagatelizować te incydenty jako porażki pojedynczych dostawców. W rzeczywistości ujawniają one systemową słabość: LLM nie są w stanie samodzielnie rozwiązać podstawowego problemu prompt injection. Wynika to z ich architektury. Każde nowe podejście oparte na Guardrails usuwa konkretny wektor ataku – i tym samym implicitnie stwarza warunki, w których atakujący opracowują kolejny.
Adversa trafnie opisuje tę zależność jako przesunięcie wektora ataku: nie sam prompt, lecz cały kontekst, który LLM traktuje jako swoje własne środowisko – wyniki Tool-Calling, rezultaty runtime, stany pośrednie – staje się powierzchnią ataku. Jest ona nieporównywalnie większa niż to, co tradycyjnie uznaje się za „dane wejściowe modelu".
Dr. Maik Bunzel, założyciel i dyrektor zarządzający mabucon.eu, podkreśla w tym kontekście, że przedsiębiorstwa integrujące agentów AI z procesami operacyjnymi muszą aktywnie uwzględniać tę strukturalną właściwość w swojej architekturze ryzyka: kwestia bezpieczeństwa to nie tylko sprawa wybranego modelu, lecz architektury systemu zbudowanego wokół modelu – w tym danych, do których agent ma dostęp, oraz działań, które może podejmować samodzielnie.
Implikacje dla przedsiębiorstw stosujących automatyzację wspieraną przez AI
Dla organizacji integrujących asystentów i agentów AI ze swoimi workflow – czy to w zakresie zarządzania pocztą e-mail, przetwarzania dokumentów, czy komunikacji z klientami – z tych ustaleń wynikają konkretne obszary działania:
- Principle of Least Privilege dla agentów AI: Agenci powinni mieć dostęp wyłącznie do tych danych i systemów, które są absolutnie niezbędne do realizacji ich konkretnego zadania. Szerokie uprawnienia dostępu do danych zwielokrotniają potencjalne szkody wynikające z udanych ataków prompt injection.
- Human-in-the-Loop dla wrażliwych działań: Działania wywierające skutki na zewnątrz – wysyłanie wiadomości e-mail, wywoływanie zewnętrznych adresów URL, przekazywanie danych – powinny wymagać jawnego etapu potwierdzenia, którego sam model nie może ominąć.
- Nieufność wobec treści zewnętrznych jako zasada projektowania: Każda treść przetwarzana przez agenta AI z Internetu lub z dokumentów użytkownika powinna być traktowana na poziomie architektury systemu jako potencjalnie wroga – a nie jako zaufane rozszerzenie zlecenia użytkownika.
- Monitoring i wykrywanie anomalii: Ponieważ same Guardrails nie zapewniają pełnej ochrony, na znaczeniu zyskuje następcze monitorowanie zachowania agentów: jakie połączenia zewnętrzne nawiązuje agent? Jakie dane opuszczają system?
- Vendor due diligence i cykle aktualizacji bezpieczeństwa: Fakt, że xAI przez wiele miesięcy po zgłoszeniu nie dostarczyło rozwiązania, pokazuje wyraźnie: przy wyborze dostawcy przedsiębiorstwa powinny zwracać uwagę również na szybkość reakcji na zgłoszenia bezpieczeństwa.
Gra w kotka i myszkę oraz jej znaczenie dla branży AI
Analogia, którą posługują się badacze bezpieczeństwa, jest wymowna: inżynier bezpieczeństwa w budownictwie drogowym instaluje bariery ochronne na niebezpiecznym zakręcie – zamiast prostować sam zakręt. Każda nowa bariera stanowi reakcję na ostatni wypadek; sam zakręt pozostaje niebezpieczny. W przypadku LLM zakrętem jest fundamentalna niemożność niezawodnego oddzielenia kontekstu od intencji.
Nie oznacza to, że agenty i asystenci AI nie mogą być stosowane produktywnie i bezpiecznie. Oznacza jednak, że bezpieczeństwo osiąga się tu nie poprzez zaufanie do modelu, lecz przez architektoniczną kontrolę wokół modelu. Dr. Maik Bunzel, założyciel i dyrektor generalny mabucon.eu, postrzega to jako kluczowe zadanie projektowe na nadchodzące lata: budowanie systemów AI w taki sposób, aby ich właściwości bezpieczeństwa nie zależały od doskonałości pojedynczego Guardrails, lecz były zabezpieczone przez redundantne, systemiczne mechanizmy kontroli.
Cryptographic Context Injection nie jest w tym kontekście wyjątkiem – jest drogowskazem. Sam Adversa formułuje to precyzyjnie: kolejna generacja ataków powstanie dokładnie tam, gdzie LLM traktują zewnętrzne Tool-Outputs, wyniki runtime'owe i stany pośrednie jako część własnego kontekstu. Kto integruje dziś agenty AI z systemami produkcyjnymi, powinien znać tę powierzchnię ataku i adresować ją na poziomie architektonicznym.
Podsumowanie: bezpieczeństwo jako projektowanie systemu, nie jako cecha produktu
Odkrycie Cryptographic Context Injection uwidacznia dojrzałość, którą trzeba przypisać stronie atakującej w ekosystemie LLM: myślą już nie w kategoriach promptów, lecz systemów. Strona broniąca się – a to dotyczy wprost również przedsiębiorstw wdrażających produkty AI – musi wykonać ten sam krok. Bezpieczeństwo w erze AI nie jest funkcją dostarczaną przez dostawcę modelu. Jest właściwością systemową, która powstaje w wyniku świadomego projektowania – i wymaga ciągłego mierzenia się z dynamicznie rozwijającym się krajobrazem zagrożeń.