Badacze cyberbezpieczeństwa zwracają uwagę, że nawet najnowocześniejsze agentowe narzędzia do kodowania oparte na AI nie są tak bezpieczne, jak mogłoby się wydawać. W praktyce okazuje się, że ich mechanizmy izolacji można stosunkowo łatwo obejść, a to otwiera drogę do ataków na systemy, z których korzystają programiści.
Jak działa taki atak
Zespół Pillar pokazał kilka sposobów na przełamanie granicy sandboxa w popularnych narzędziach, takich jak Cursor, Codex CLI, Gemini CLI i Antigravity. W uproszczeniu scenariusz wygląda tak: atakujący przygotowuje pozornie niewinny repozytorium z ukrytymi złośliwymi instrukcjami, na przykład w pliku README, zależnościach albo innych elementach projektu. Następnie zachęca programistę, by uruchomił je z pomocą asystenta AI.
Agent wykonuje polecenia w obrębie własnego środowiska i modyfikuje plik konfiguracyjny projektu. Problem w tym, że później ten zmieniony plik może zostać odczytany przez komponent działający już poza sandboxem, na przykład integrację Git, rozszerzenie IDE albo lokalny demon systemowy.
W efekcie złośliwe komendy są uruchamiane z uprawnieniami zaufanego hosta, a nie ograniczonego agenta. To oznacza, że zabezpieczenie, które miało oddzielać AI od reszty systemu, przestaje spełniać swoją rolę.
Warto pamiętać, że podobne ataki często wykorzystują nie tyle błąd w samym modelu AI, ile zaufanie do otoczenia, w którym model działa. To właśnie integracje, automatyzacje i dostęp do plików stanowią najczęściej najsłabsze ogniwo. Dlatego w praktyce bezpieczeństwo agentów trzeba projektować od podstaw, a nie traktować jako dodatek.
Dlaczego to jest niebezpieczne
Taki rodzaj podatności jest szczególnie groźny, bo nie wymaga klasycznego włamania „z zewnątrz”. Wystarczy, że użytkownik zaufa zainfekowanemu repozytorium albo plikowi przygotowanemu pod kątem manipulacji agentem. Sam fakt, że akcje dzieją się w obrębie workspace’u, może uśpić czujność i sprawić, że nic nie wzbudzi podejrzeń.
To pokazuje też szerszy problem związany z agentami AI. Są one projektowane tak, by działać autonomicznie, analizować pliki, tworzyć konfiguracje i wykonywać kolejne kroki bez większej ingerencji człowieka. Im więcej swobody dostają, tym większe ryzyko, że ich działania zostaną wykorzystane przeciwko użytkownikowi.
W podobnym kontekście warto przeczytać także: Five Eyes ostrzega przed wykorzystywaniem AI do cyberataków — to kolejny sygnał, że bezpieczeństwo narzędzi AI staje się coraz ważniejszym tematem.
Które narzędzia zostały poprawione
Według raportu Pillar trzy z czterech opisanych platform usunęły już wykryte błędy. Cursor załatał kilka podatności w wersji 3.0.0, w tym jedną oznaczoną jako CVE-2026-48124. Codex CLI naprawił problem w wersji 0.95.0, choć nadal czeka na formalny numer CVE.
W przypadku Gemini CLI źródłem problemu był Docker daemon, a poprawka została udostępniona w ramach opublikowanego advisory. Najciekawiej wygląda sytuacja z Antigravity, ponieważ Google uznało zgłoszone problemy za prawdziwe, ale sklasyfikowało je jako mniej poważne, sugerując, że ich wykorzystanie jest trudniejsze.
Co wynika z tych testów
Najważniejszy wniosek jest dość prosty: bezpieczeństwa agentów AI nie można oceniać tak samo jak tradycyjnych aplikacji. Jeśli narzędzie potrafi tworzyć lub zmieniać przyszłe dane wejściowe systemów, to granica sandboxa staje się bardziej iluzoryczna niż realna.
Pillar podsumowuje to bardzo dosadnie — zdaniem badaczy agentowa AI wymaga własnego modelu zagrożeń. I trudno się z tym nie zgodzić. Obecne rozwiązania pokazują, że wygoda i automatyzacja wciąż wyprzedzają dojrzałość zabezpieczeń, a to w świecie cyberbezpieczeństwa zawsze powinno budzić niepokój.
Co to oznacza dla programistów i firm
Dla zespołów developerskich to sygnał, że korzystanie z agentów kodujących wymaga większej ostrożności niż dotychczas. Nie wystarczy zakładać, że narzędzie działające w „piaskownicy” jest odseparowane od reszty środowiska. Trzeba brać pod uwagę, że jego działania mogą mieć skutki poza widocznym oknem aplikacji.
Firmy powinny więc dokładniej analizować, jakie uprawnienia mają ich AI-asystenci, jakie pliki mogą modyfikować i jakie komponenty odczytują te zmiany później. W przeciwnym razie agent, który miał przyspieszać pracę, może stać się dodatkowym wektorem ataku.
Czekałem na jakąś analizę bezpieczeństwa asystentów AI, bo to, co robi się z tych narzędzi w devie, jest przerażające. Znam kilka osób, które korzystają z tego typu aplikacji i pewnie nawet nie zdają sobie sprawy, że mogą być tak podatne na ataki. Dobrze, że te podatności zostały wykryte, ale czy na pewno wszystkie firmy zareagują na to odpowiednio?
Jeszcze niedawno byłem fanem tych narzędzi, ale teraz? Nieufność rośnie. Obejdeń piaskownicy to tylko jedna strona medalu. Czy ktoś myśli, co się dzieje z danymi, które AI analizuje? Nie wiem, czy warto ryzykować. Może czekam na kolejne generacje, bo to będzie bardziej bezpieczne.
W artykule brakuje głębszej analizy tego, co dokładnie się dzieje w sandboxach. Znam temat od podszewki, a niektóre techniki wykorzystywane do obejścia zabezpieczeń są bardziej złożone niż przedstawione w tym raporcie. Warto by było dodać konkretną terminologię, zamiast ogólników.
Pracuję w firmie, która intensywnie korzysta z AI do kodowania i obawiam się o bezpieczeństwo. Mamy kilka projektów, w których nie stosujemy jeszcze tych narzędzi, ale to może się zmienić. Dzięki za informacje o poprawkach, bo muszę o tym powiadomić szefa.
Korzystam z Codex CLI i już mialem problemy z integracją z Git. Ciekawi mnie, jak często takie usterki się wydarzały, czy to jest powszechny problem? Chciałbym wiedzieć, co z tym zrobić, bo nie możemy sobie pozwolić na ryzyko.
Nie rozumiem, czemu ludzie tak ufają AI w pracy. Zawsze były i będą luki w zabezpieczeniach, a teraz, gdy mówimy o agentach AI, to tylko się nasila. Po tym, co przeczytałam, to nie mam zamiaru korzystać z takich narzędzi. Lepiej dopasować te technologię do naszych potrzeb samodzielnie.
Fajnie, że są poprawki, ale co z tymi, którzy już używają tych narzędzi? Przez ich działania możliwe że wszyscy mogą być narażeni. Szybko się nie zaufam takim asystentom, bo wolę drobne usterki w moim kodzie, niż atak na całą bazę. Zmiany są konieczne.