Bezpečnostní výzkumníci prokázali, že sandboxy chránící čtyři široce používané kódovací agenty AI – Cursor, OpenAI’s Codex, Google Gemini CLI a Antigravity – lze uniknout, aniž by kdy došlo k přímému útoku na sandbox. Zjištění zveřejněná 20. července 2026 výzkumným týmem Pillar Security a hlášená BleepingComputer odhalují strukturální slabinu v tom, jak nástroje pro kódování AI izolují kód, který jejich agenti generují z vývojářských strojů, na kterých běží.

Výzkum je významným datovým bodem pro každého, kdo sleduje nejnovější zprávy o AI o bezpečnosti agentů, protože ukazuje, že i dokonale vyhovující agent – ​​takový, který dodržuje všechna pravidla uvnitř své karantény – může stále uniknout. Chyba není v chování agenta, ale v hranici důvěry, kterou sandbox předpokládá.

Jak fungují útěky

Klíčový poznatek je zdánlivě jednoduchý. Moderní kódovací agenti AI běží uvnitř karantény, která kreslí čáru: agent je důvěryhodný uvnitř pracovního prostoru projektu a hostitel venku je chráněn. Předpokladem je, že soubory uvnitř pracovního prostoru jsou inertní – data, nikoli příkazy.

Ale nejsou inertní. Nástroje běžící mimo karanténu tyto soubory neustále čtou a jednají s nimi. Integrovaná vývojová prostředí řeší interprety Pythonu, integrace Git skenují repozitáře, VS Code spouští soubory úloh, spouštěcí příkazy hákových motorů a Docker Desktop zpřístupňuje místní soket. Agent v karanténě se může řídit každým pravidlem, které mu je dáno, a přesto zapisovat soubor, který některý z těchto externích nástrojů později spustí, načte nebo prohledá.

Podle zpráv BleepingComputer se únik „uskuteční sám od sebe“: agent zůstane uvnitř krabice, dodržuje všechna pravidla a pouze zapíše soubor, který následně spustí důvěryhodný nástroj mimo krabici. Agent nikdy nevypukne; prolomení je provedeno jeho jménem softwarem, kterému vývojář již důvěřuje.

Spouštěč: Rychlá injekce

Mechanismus, který uvádí tyto úniky do pohybu, je rychlá injekce – stejná zranitelnost, která sužovala agenty AI napříč doménami. Škodlivá instrukce zasazená do souboru README, problém na GitHubu, závislost na projektu nebo rozdíl v kódu se stane místní akcí na počítači vývojáře, jakmile ji agent zpracuje.

To propojuje výzkum sandboxu s širším vzorem v zabezpečení AI. Agent nemusí být kompromitován nebo jailbreaknut. Jednoduše se potřebuje setkat s otráveným vstupem v průběhu své běžné práce – čtení souboru, kontrola požadavku na stažení, instalace balíčku – a poté provést vloženou instrukci zapsáním správného souboru na správné místo. Sandbox umožňuje zápis, protože zápis souborů je přesně to, co má kódovací agent dělat.

„Týden útěků z pískoviště“

Výzkumný tým Pillar Security – Eilon Cohen, Dan Lisichkin a Ariel Fogel – reprodukoval obchvaty během několika měsíců a publikoval je jako sérii, kterou nazývají „Týden útěků z pískoviště“, přičemž každý den uvolňuje jeden záznam. Vědci seřadili svých sedm zjištění do čtyř odlišných způsobů selhání.

Jednou kategorií je to, co popisují jako sandboxy denylistu – karantény, které se snaží blokovat konkrétní nebezpečné akce spíše než povolovat pouze ty bezpečné. Odmítači jsou notoricky křehcí, protože jsou závislí na předvídání každého možného útoku, a úniky ukazují, jak se agent může obejít kolem zablokované akce tím, že zapojí externí nástroj, který vůbec nebyl na seznamu odmítačů.

Čtyři dotčené nástroje – Cursor, OpenAI’s Codex, Google Gemini CLI a Antigravity – představují široký průřez trhu s kódovacími agenty AI, od spotřebitelských zásuvných modulů IDE po podnikové nástroje příkazového řádku. Tato šíře naznačuje, že problémem není chyba v žádném jednotlivém produktu, ale sdílený architektonický předpoklad, který výzkum vyvrací.

Proč je to důležité pro ekonomiku agentů

Důsledky přesahují jednotlivé vývojáře. Protože jsou kódovací agenti zabudováni do automatizovaných kanálů, systémů kontinuální integrace a autonomních pracovních postupů, stává se únik ze sandboxu potenciální základnou pro útoky na dodavatelský řetězec. Útočník, který může dostat otrávený soubor do úložiště – prostřednictvím závislosti, klonovaného úložiště nebo kompromitovaného přispěvatele – může pravděpodobně proměnit důvěryhodného kódovacího agenta na spouštěcí vektor na vývojářském počítači.

Jedná se o stejnou třídu rizika, která se objevila dříve v roce 2026, kdy výzkumníci zjistili, že otevření škodlivého úložiště v Cursoru by mohlo tiše spustit kód ve Windows. Sandbox úniky tuto hrozbu zobecňují: není to jeden nástroj nebo jedna platforma, ale model interakce mezi izolovanými agenty a důvěryhodnými nástroji, které je obklopují.

Obtížný problém důvěryhodných souborů

Základním problémem je, že sandbox kódovacího agenta nemůže považovat všechny soubory pracovního prostoru za nedůvěryhodné, aniž by to ochromilo užitečnost agenta. Agent musí psát kód, konfiguraci a skripty a tyto soubory je třeba číst a pracovat s nimi pomocí nástrojů vývojáře. Odstraňte tuto důvěru a agent nemůže fungovat; zachovejte jej a únikový vektor zůstane.

Pillarův výzkum nenabízí jedinou opravu drop-in, a proto na zjištěních záleží. Rámcují návrhový problém, který bude muset průmysl vyřešit kolektivně – prostřednictvím silnější izolace mezi pracovním prostorem agenta a prováděcím povrchem hostitele, podepisováním nebo atestací souborů napsaných agentem nebo přehodnocením toho, které nástroje mohou vůbec automaticky spouštět obsah pracovního prostoru.

Pro vývojáře, kteří dnes používají Cursor, Codex, Gemini CLI nebo Antigravity, je praktickým řešením opatrnost s nedůvěryhodnými vstupy: klonovaná úložiště, závislosti třetích stran a přidaný kód by měly být považovány za potenciálně nesoucí rychlou injekci, která cílí nejen na model, ale i na souborový systém kolem něj.

Udržujte si náskok před AI

Pro průběžné pokrytí AI zabezpečení, kódovacích agentů a infrastrukturních rizik, která představují, sledujte naše pokrytí odvětví AI.

Přečtěte si další zprávy o AI