LLM-y są strukturalnie podatne na ataki: co wyniki badań ICML oznaczają dla firm

Niewygodna prawda z badań nad sztuczną inteligencją

Na tegorocznej International Conference on Machine Learning (ICML), jednej z najbardziej renomowanych konferencji w dziedzinie sztucznej inteligencji, znaczną uwagę wzbudził pewien artykuł naukowy: zespół niezależnych badaczek i badaczy argumentuje w nim, że duże modele językowe – tzw. Large Language Models (LLMs) – ze względu na swoją strukturę nie mogą być w pełni zabezpieczone przed atakami, co jest zasadniczo nierozwiązywalne. Przyczyna nie leży w słabej implementacji ani niedbałym trenowaniu, lecz głęboko w samej architekturze tych modeli. Dla firm, które stosują lub planują procesy wspierane przez AI, jest to wiadomość o strategicznych konsekwencjach.

Problem ról: gdy kontekst staje się słabym punktem

Aby zrozumieć, dlaczego LLMs są tak podatne na ataki, należy przyjrzeć się wewnętrznemu przetwarzaniu danych tekstowych. Nowoczesne chatboty i agenty AI strukturyzują strumienie informacji, z którymi pracują, za pomocą tzw. tagów ról. Treści użytkownika oznaczane są jako tekst <user>, instrukcje systemowe programistów jako <system>, wewnętrzne rozważania modelu jako <think>, a zewnętrzne źródła np. jako <tool>. Ta struktura ról stanowi podstawę dla sposobu, w jaki model decyduje, czyje polecenie wykonać – a czyje zignorować.

Badacze odkryli jednak, że LLMs określają pochodzenie fragmentu tekstu nie przede wszystkim na podstawie tagów, lecz na podstawie stylu i językowych cech samego tekstu. Innymi słowy: jeśli atakujący sformułuje tekst naśladujący wewnętrzny styl „notatnika" modelu – czyli format Chain-of-Thought, w którym model zapisuje własne rozważania – model interpretuje ten zewnętrzny tekst jako własne myśli i odpowiednio postępuje.

Chain-of-Thought-Forgery: najbardziej wyrafinowany atak

Badaczki i badacze określają tę metodę ataku mianem Chain-of-Thought Forgery – celowego fałszowania wewnętrznych rozważań modelu poprzez stylistycznie precyzyjnie dopasowane dane wejściowe. W praktycznych eksperymentach zespołowi udało się skłonić kilka popularnych modeli do generowania treści, które ich własne zasady bezpieczeństwa wprost zabraniają. Technika ataku zdobyła ponadto pierwszą nagrodę w hackathonie Red-Teaming organizowanym przez OpenAI w 2025 roku.

Szczególnie godne uwagi: równolegle wewnętrzny system Red-Teaming OpenAI – GPT-Red – miał samodzielnie odkryć strukturalnie podobną metodę ataku, co podkreśla trafność i odtwarzalność opisywanych wyników.

„It's just one big sheet of tokens" – Jasmine Cui, współautorka artykułu na ICML, opisuje w ten sposób istotę problemu: dla LLM cały tekst wejściowy jest początkowo niezróżnicowaną sekwencją tokenów. Przypisanie ról jest ostatecznie interpretacją, a nie gwarancją techniczną.

Dlaczego sam Red-Teaming nie wystarczy

Typową odpowiedzią branży AI na znane wektory ataków jest Red-Teaming: wyspecjalizowane zespoły – wewnętrzne lub zewnętrzne – systematycznie próbują skompromitować model przed jego wdrożeniem produkcyjnym. Wykryte w ten sposób ataki są uwzględniane w kolejnych cyklach trenowania, dzięki czemu model staje się bardziej odporny na te konkretne wzorce.

Podstawowy problem tej metodyki autorzy ICML trafnie opisują za pomocą przypowieści: to tak, jakby kazać dziecku sto razy przepisywać listę rzeczy, których nie wolno mu robić – i zakładać, że wyklucza to wszelkie przyszłe wykroczenia. Liczba możliwych wariantów ataku jest de facto nieograniczona. Każde nowo wytrenowane zabezpieczenie jest zawsze jedynie odpowiedzią na już znane ataki, nigdy rozwiązaniem strukturalnym.

Dr. Maik Bunzel, założyciel i dyrektor zarządzający mabucon.eu, intensywnie zajmuje się implikacjami takich wyników badań dla zastosowania agentów AI w przedsiębiorstwach. Jego ocena jest zbieżna z tym, co sugeruje badanie ICML: bezpieczeństwo systemów opartych na LLM to nie jednorazowy projekt, lecz ciągły, architekturalny proces projektowania – i zaczyna się on na długo przed wdrożeniem.

Prompt Injection i Jailbreaks: dwie strony tego samego medalu

Badacze rozróżniają zasadniczo dwie klasy ataków, które opierają się na tym samym strukturalnym deficycie:

• Jailbreaks: Użytkownicy skłaniają model do obejścia jego własnych wytycznych, formułując dane wejściowe w taki sposób, że model interpretuje je jako wewnętrzną instrukcję systemową lub własne rozumowanie.
• Prompt Injections: Atakujący przemyca za pośrednictwem zewnętrznych źródeł danych – takich jak strony internetowe, dokumenty lub dane wyjściowe narzędzi (Tool-Outputs) – zmanipulowane instrukcje, które model traktuje jako uprawnione polecenia użytkownika, a nawet polecenia systemowe.

Ten ostatni przypadek jest szczególnie istotny w obszarze Agentic AI: gdy agent AI autonomicznie przeszukuje sieć, analizuje dokumenty lub wywołuje API, zewnętrzne źródła danych są z definicji częścią strumienia wejściowego. Każde z tych źródeł stanowi potencjalny wektor ataku Prompt Injection – a opisane zamieszanie ról sprawia, że odpieranie takich ataków jest strukturalnie trudniejsze, niż dotychczas zakładano.

Co to oznacza dla agentów AI w przedsiębiorstwach

Implikacje dla firm korzystających z automatyzacji opartej na LLM lub agentach AI są znaczące – nie uzasadniają jednak paniki, lecz trzeźwą ponowną ocenę profilu ryzyka. Z wyników badań można wyprowadzić kilka kluczowych zaleceń dotyczących działania:

• Zasada Zero-Trust dla agentów AI: Żaden output systemu LLM nie powinien być traktowany jako z natury godny zaufania – nawet jeśli pochodzi z wewnętrznego łańcucha rozumowania modelu (Chain-of-Thought). Zewnętrzne warstwy walidacji są niezbędne.
• Minimalne uprawnienia i izolacja: Agenci AI powinni mieć dostęp wyłącznie do tych systemów i danych, które są bezwzględnie wymagane do realizacji danego zadania. Skompromitowany agent nie może mieć dostępu do krytycznych danych przedsiębiorstwa.
• Ciągły monitoring zamiast jednorazowego zabezpieczenia: Ponieważ żadne szkolenie nie jest w stanie objąć wszystkich przyszłych wariantów ataków, kluczowe znaczenie ma monitorowanie zachowania modelu w czasie rzeczywistym – szczególnie w przypadku agentów autonomicznie przetwarzających zewnętrzne treści.
• Ocena ryzyka według kontekstu zastosowania: Chatbot LLM obsługujący wewnętrzne zapytania FAQ ma zupełnie inny profil ryzyka niż autonomiczny agent wykonujący rezerwacje, przelewy lub komunikację w czasie rzeczywistym.

Florian Tramèr, informatyk na ETH Zürich specjalizujący się w bezpieczeństwie LLM, ocenia badanie pozytywnie i potwierdza: nawet jeśli wiodące modele stały się znacznie bardziej odporne dzięki kombinacji różnych środków ochrony, w przypadku wysoce wrażliwych zastosowań nadal pozostaje niejasne, czy to wystarczy.

Wymiar ekonomiczny: motywacje atakujących rosną

Jednym z aspektów wyraźnie podkreślanych przez badaczy jest rosnąca ekonomiczna motywacja stojąca za jailbreaks i Prompt Injections. Wraz z rozszerzaniem się systemów wspieranych przez AI na obszary takie jak e-commerce, usługi finansowe, ochrona zdrowia czy infrastruktura państwowa, rosną również potencjalne zyski z udanych ataków – czy to poprzez eksfiltrację danych, manipulację procesami biznesowymi, czy omijanie mechanizmów compliance.

Tę ocenę podziela również Dr. Maik Bunzel z mabucon.eu: „Pytanie nie brzmi już czy, lecz kiedy i w jakim kontekście przedsiębiorstwo zetknie się z atakami wspieranymi przez AI. Kto dziś integruje agentów AI w krytyczne przepływy pracy bez zdefiniowania explicitnego modelu bezpieczeństwa, buduje na strukturalnie niepewnym fundamencie."

Perspektywa: bezpieczeństwo jako zasada projektowania, nie jako poprawka

Badanie ICML nie jest argumentem przeciwko stosowaniu LLM w przedsiębiorstwach. Jest silnym argumentem za tym, by bezpieczeństwo traktować jako architekturalną zasadę projektowania – a nie jako środek zabezpieczający wdrażany po fakcie. Modele stają się lepsze, ataki również stają się lepsze. To nie jest tymczasowy problem, który rozwiąże się wraz z kolejnym wydaniem modelu.

Dla przedsiębiorstw korzystających z agentów AI i zautomatyzowanych przepływów pracy oznacza to konkretnie: wybór technologii i architektura systemu muszą być od samego początku dokonywane z uwzględnieniem realistycznego modelu zagrożeń. Zaufanie do modelu nie jest koncepcją bezpieczeństwa – są nią izolacja, monitoring i jasne ścieżki eskalacji. Dr. Maik Bunzel, założyciel i dyrektor zarządzający mabucon.eu, ujmuje operacyjne konsekwencje zwięźle: kto odpowiedzialnie wdraża agentów AI, planuje nie tylko na przypadek normalny, lecz explicite na przypadek ataku.

Dobra wiadomość: świadome i ustrukturyzowane podejście do tych zagrożeń jest możliwe. Zła wiadomość: wymaga czegoś więcej niż zaufania do obietnic bezpieczeństwa składanych przez dostawców modeli.