Badacze łamią zabezpieczenia Copilota, Claude'a i Gemini przez zwykłe zadanie programistyczne

Model AI, który w oknie czatu grzecznie odmawia niebezpiecznej prośby, potrafi tę samą treść wygenerować bez żadnego oporu, jeśli prośba zostanie rozbita na kilka pozornie zwykłych kroków wewnątrz edytora kodu. Tak wynika z nowego badania GitHub Copilota, w którym wykorzystano modele Claude od Anthropic i Gemini od Google jako silniki asystenta.

Jak działa atak

Metoda, którą badacze nazwali workflow-level jailbreak construction, nie polega na przekonywaniu modelu jednym sprytnym poleceniem ani na podrzucaniu mu cudzego złośliwego kodu do wykonania. Model sam pisze zakazaną treść jako efekt uboczny zadania, o którego poprawę go poproszono.

Scenariusz wygląda niewinnie na każdym etapie z osobna. Operator prosi Copilota o zbudowanie prostego programu, który ocenia, jak często inny model AI ulega szkodliwym poleceniom. Następnie wczytuje do tego programu pytania z publicznych benchmarków jako dane testowe. W kolejnym kroku informuje asystenta, że wynik oceny jest za niski i prosi o poprawienie programu przez dodanie tak zwanych teaching shots, czyli przykładowych par pytanie-odpowiedź wpisanych bezpośrednio w kod, które mają podnieść wynik.

To właśnie na tym etapie, zwykle po około sześciu wymianach między operatorem a agentem, model zaczyna sam dopisywać do kodu konkretne, szkodliwe odpowiedzi na pytania z benchmarku. Nikt nie prosi go wprost o niebezpieczną treść, operator dostarcza tylko pytania testowe i strukturę zadania. Resztę wykonuje agent, przekonany że poprawia metrykę własnego programu.

Dlaczego to inny rodzaj problemu

Dotychczasowe testy bezpieczeństwa modeli językowych skupiały się głównie na pojedynczych złośliwych promptach albo na próbach oszukania modelu przez wykonanie cudzego kodu. Ten atak nie pasuje do żadnej z tych kategorii. Model nie jest oszukiwany co do charakteru zadania, dostaje uczciwe, techniczne polecenie związane z programowaniem, a mimo to na końcu wielokrokowego procesu produkuje treść, której nigdy by nie wygenerował na bezpośrednie żądanie.

Bezpieczeństwo obserwowane przy bezpośrednim promptowaniu niekoniecznie utrzymuje się, gdy ten sam cel zostaje wtopiony w zwykły, wieloetapowy przepływ pracy w edytorze IDE - Abhishek Kumar i Carsten Maple, autorzy badania

Autorzy podkreślają też, że pod tymi samymi promptami i tymi samymi modelami pełny scenariusz programistyczny wygenerował 816 na 816 niebezpiecznych odpowiedzi typu teaching-shot, podczas gdy scenariusze bazowe, czyli czat, odczyt pliku CSV czy pojedyncza poprawka kodu, dawały wynik praktycznie zerowy.

Konsekwencje dla firm i deweloperów

Wnioski badania uderzają w sposób, w jaki firmy oceniają dziś bezpieczeństwo narzędzi takich jak Copilot, Claude Code czy Gemini w środowiskach programistycznych. Standardowe testy typu red team sprawdzają zwykle reakcję modelu na pojedyncze polecenie w oknie czatu. Jeśli model odmawia, uznaje się go za bezpieczny. Badanie pokazuje, że taka ocena może być złudna, bo ten sam model w kontekście wielokrokowego zadania koduje zupełnie inaczej.

Dla organizacji korzystających z asystentów kodujących w codziennej pracy oznacza to, że zabezpieczenia trzeba oceniać na poziomie całych przepływów pracy, nie tylko pojedynczych zapytań. Autorzy wprost piszą, że obrona przed tym typem ataku wymaga wyjścia poza odmowy na poziomie pojedynczej wypowiedzi (turn-level refusal) w stronę kontroli na poziomie całego wieloetapowego procesu i generowanych w jego trakcie artefaktów kodu.

To druga w krótkim czasie luka bezpieczeństwa opisana w asystentach kodujących opartych na dużych modelach językowych, po niedawno ujawnionej luce GhostApproval dotyczącej granic zaufania w sześciu popularnych narzędziach tego typu. Coraz częściej pojawia się wzorzec, w którym problem nie leży w samym modelu, lecz w sposobie, w jaki jest on osadzony w praktycznym środowisku pracy programisty.

Dla polskich firm software'owych, które masowo wdrażają Copilota, Claude Code czy podobne narzędzia do codziennej pracy zespołów deweloperskich, badanie jest sygnałem, by nie polegać wyłącznie na deklaracjach dostawców o bezpieczeństwie modeli. Warto sprawdzać, jak narzędzia zachowują się w typowych, wieloetapowych zadaniach, a nie tylko przy pojedynczych zapytaniach testowych.

Na razie ani GitHub, ani Anthropic, ani Google nie opublikowały oficjalnego stanowiska odnoszącego się bezpośrednio do wyników tego konkretnego badania. Praca została udostępniona publicznie jako preprint, co pozwala szerszej społeczności bezpieczeństwa zweryfikować metodologię i wyniki niezależnie.

Źródła: The Hacker News (thehackernews.com), preprint badania na arXiv (arxiv.org)