Agent AI "ucieka" z sandboxa? Badacze sprawdzili dlaczego

Michał Nowakowski · 30 września 2026

Uciekł czy nie uciekł? Badacze z Accomplish AI postanowili to sprawdzić i znaleźli. Co takiego?

Uciekł czy nie uciekł? Badacze z Accomplish AI postanowili to sprawdzić i znaleźli. Co takiego? Dwie drogi, którymi agent "od kodu" wychodzi poza swoje zamknięte środowisko i robi na komputerze developera to, o co nikt go nie prosił (lub prosił ktoś inny).

A to ważna informacja dla developerów i ich organizacji. Dlaczego? Dlatego, że to wyraźnie pokazuje, że różni asystenci AI i inne rozwiązania do tworzenia oprogramowania nie są super bezpieczne i niezniszczalne. Wcale nie chodzi tutaj o magiczne właściwości i autonomię, ale o zwyczajne podatności, które pozwalają na przejęcie cennego materiału. I to wynik ludzkich niedopatrzeń przy projektowaniu.

Okazało się, że w narzędziu (desktopowa i terminalowa wersja OpenAI Codex), które developerzy mogą zainstalować na swoim komputerze, istniały luki, które umożliwiały agentowi wyjście poza zamknięte środowisko i wykonanie konkretnych działań bez wiedzy użytkownika (w tle). Wystarczyło otworzyć w Codexie cudze repozytorium i zadać agentowi pytanie o kod.

Chodzi tutaj o dwie techniki (więcej w komentarzu):

❌ Overpatch (nadużycie narzędzia do nanoszenia poprawek, apply_patch) oraz

❌ Heapjack (porwanie sterty pamięci; nie ma chyba dobrego tłumaczenia).

I teraz pytanie: jak to się ma do autonomicznych ataków agentów AI? Pamiętacie moje posty poświęcone procesowi wytwórczemu oprogramowania (SDLC) z rekomendacjami ENISA? Zawarto tam kilka ciekawych rekomendacji, w tym takich, które sprowadzamy do prostego stwierdzenia:

❗nie ufaj i kontroluj❗

To oznacza, że gdy agent / asystent AI podrzuca nam sugestie dotyczące akceptacji uprawnień czy instalacji dodatkowych pakietów, to powinniśmy zachować ostrożność i nie ufać bezgranicznie. W wytycznych ENISA wprost wskazano także na zasadność stosowania plików skills[.]md z pakietem instrukcji w zakresie cyberbezpieczeństwa.

Każdy z wyżej wskazanych wektorów osobno wystarczał, żeby autor złośliwego repozytorium dostał dostęp do komputera ofiary, która nie była świadoma wykonywania kodu w tle. Resztę możecie sobie dopowiedzieć ; )

I to pokazuje bardzo ważną rzecz: że nie możemy zakładać, że udostępnienie narzędzia developerom bez szkoleń i budowania świadomości zapewni nam bezpieczeństwo. Musimy także:

🛠️ świadomie zarządzać ryzykiem, które generują asystenci i agenci AI w obszarze cyber,

⛓️‍💥 wprowadzić mechanizmy w zakresie bezpieczeństwa łańcucha dostaw (cudze repozytorium to też dostawca) oraz

💻 nieustannie egzekwować dobre praktyki w zakresie (secure)SDLC, w tym aktualizować narzędzia, z których korzystają agenci; a także zwracać uwagę na zjawisko shadow AI.

Tego wymaga od nas także ustawa o krajowym systemie cyberbezpieczeństwa, np. gdy świadczymy usługi zarządzane w obszarze IT czy cyber.

To oczywiście nie jest absolutna gwarancja odporności, ale od czegoś trzeba zacząć, prawda? Inspiracja od sekurak, który napisał fajny felieton na ten temat; źródło pierwotne: Oren Yomtov (Accomplish), „Escaping the OpenAI Codex sandbox, twice”.