Nowości
Badacze Pillar Security: agenty kodujące AI wydostają się z piaskownicy bez łamania jej reguł
Pillar Security opisała serię ucieczek z piaskownicy w czterech popularnych agentach kodujących AI - Cursor, Codex, Gemini CLI i Antigravity. Agent nie musiał łamać żadnej reguły, wystarczyło że zapisał plik, który zaufany program poza piaskownicą sam uruchomił.
Spis treści
Badacze z Pillar Security pokazali, że cztery najpopularniejsze agenty kodujące oparte na AI da się skłonić do działania poza wyznaczoną im piaskownicą bezpieczeństwa, mimo że żadna z jej reguł formalnie nie zostaje złamana. Wystarczy, że agent zapisze odpowiedni plik, a zaufany program działający poza piaskownicą sam go uruchomi, wczyta lub przeskanuje.
Cztery sposoby na ominięcie reguł
Zespół Pillar Research pracował nad tematem kilka miesięcy i opisał wyniki w serii artykułów zatytułowanej "The Week of Sandbox Escapes", publikowanej dzień po dniu na DevOps.com i innych serwisach branżowych. Kluczowy wniosek: w niemal każdym przypadku agent nie musiał bezpośrednio przełamywać piaskownicy, bo wystarczyło że napisał coś, co zaufany element systemu poza piaskownicą później uruchomił.
W niemal każdym przypadku agent nie musiał bezpośrednio łamać piaskownicy. Wystarczyło, że napisał coś, co zaufany komponent poza piaskownicą później uruchomił - Eilon Cohen, Dan Lisichkin, Ariel Fogel, Pillar Security
Badacze skatalogowali cztery powtarzające się wzorce błędów. Pierwszy to piaskownice oparte na czarnych listach, które nie nadążają za rosnącą złożonością systemów operacyjnych. Drugi to konfiguracje projektu, na przykład pliki ustawień workspace'u, które w praktyce są wykonywalnym kodem, choć nikt ich tak nie traktuje. Trzeci to listy dozwolonych poleceń, które sprawdzają tylko nazwę komendy, a nie jej pełne wywołanie z argumentami. Czwarty to uprzywilejowane usługi lokalne, takie jak demony systemowe, które działają całkowicie poza zasięgiem piaskownicy, choć agent może z nimi swobodnie się komunikować.
Jak wyglądały konkretne ataki
W przypadku Google Antigravity badacze wykorzystali słabości profilu Seatbelt w macOS oraz konfiguracje zadań VS Code, by wyprowadzić działanie poza granice piaskownicy. Cursor okazał się podatny na aż trzy niezależne techniki: manipulację interpreterem w wirtualnych środowiskach Pythona, obejście metadanych Gita przez mechanizm fsmonitor oraz wykonanie kodu przez konfigurację hooków katalogu .claude, które Cursor łatał w wersji 3.0.0 pod numerem CVE-2026-48124.
Codex CLI od OpenAI miał z kolei problem z tak zwaną bezpieczną allowlistą poleceń Git - agent mógł zmienić konfigurację repozytorium tak, by pozornie nieszkodliwa komenda w rzeczywistości uruchamiała dowolny kod. OpenAI naprawił ten błąd w wersji 0.95.0 i wypłacił za jego zgłoszenie wysoką nagrodę w programie bug bounty. Najbardziej uniwersalny okazał się problem z gniazdem Dockera: Cursor, Codex CLI i Gemini CLI dzieliły ten sam wektor ataku przez uprzywilejowany demon Docker Desktop, dostępny spoza granic piaskownicy każdego z narzędzi.
Prompt injection jako punkt wejścia
Mechanizm, który uruchamia całą sekwencję, to zwykle wstrzyknięcie polecenia, czyli prompt injection - złośliwa instrukcja ukryta w pliku README, zgłoszeniu błędu, zależności projektu albo w różnicy kodu (diff), którą agent czyta w ramach normalnej pracy. Agent, wykonując polecenie zgodnie z regułami swojej piaskownicy, zapisuje plik, który później - już poza jej granicami - zostaje uruchomiony, wczytany lub przeskanowany przez inny, zaufany proces na tym samym komputerze.
Google zareagował na dwa zgłoszenia dotyczące Antigravity, ale sklasyfikował je jako trudne do wykorzystania w praktyce. Zespół bezpieczeństwa firmy docenił jednak jakość zgłoszenia badaczy. Nie jest to pierwszy raz, gdy ktoś opisuje ten wzorzec - firma Cymulate udokumentowała podobny mechanizm już w kwietniu, nazywając go "ucieczką z piaskownicy opartą na konfiguracji". Powtarzalność problemu u różnych dostawców sugeruje, że to nie pojedynczy błąd, tylko systemowa luka w projektowaniu zabezpieczeń agentów kodujących.
Co to oznacza dla firm i programistów
Dla zespołów programistycznych w Polsce, które coraz częściej korzystają z agentów kodujących w codziennej pracy, wnioski z badania Pillar Security są konkretne. Piaskownica sama w sobie nie chroni przed skutkami, jeśli agent może zapisać plik odczytywany później przez proces działający z pełnymi uprawnieniami na tym samym komputerze. Konfiguracje projektu, hooki, ustawienia workspace'u i pliki środowiskowe trzeba traktować jak potencjalnie wykonywalny kod, a nie jak nieszkodliwe dane.
Badacze rekomendują, by organizacje wymagały jawnej zgody na zmiany w plikach konfiguracyjnych projektu, dbały o to, by procesy pomocnicze działały pod tymi samymi politykami bezpieczeństwa co sam agent, zachowywały informację o pochodzeniu plików, modelowały polityki względem efektów ubocznych poleceń, ograniczały dostęp do uprzywilejowanych usług lokalnych oraz monitorowały momenty, w których zaufanie przechodzi z agenta na inny proces.
To kolejny głos w rosnącej liście badań pokazujących, że popularność agentów kodujących wyprzedza tempo, w jakim producenci są w stanie zabezpieczyć towarzyszącą im infrastrukturę. Cursor, Codex, Gemini CLI i Antigravity to dziś jedne z najczęściej wybieranych narzędzi tego typu, a odkryte luki dotyczyły mechanizmów obecnych w domyślnej konfiguracji, nie w jakimś rzadko używanym trybie eksperymentalnym.
