Fyra kodagenter tog sig ut utan att bryta sig ut

Tre forskare lade månader på att inte angripa sandlådan

Eilon Cohen, Dan Lisichkin och Ariel Fogel på Pillar Security ställde en snäv fråga om de sandlådor som följer med AI-kodagenter. Inte om murarna håller, utan om murarna står på rätt ställe. Den 20 juli 2026 började de publicera svaret som en serie de kallar Week of Sandbox Escapes, ett inlägg om dagen, om Cursor, OpenAI Codex CLI, Google Gemini CLI och Google Antigravity.

I samtliga fall skötte sig agenten. Den höll sig inom den arbetsyta den tilldelats och bröt inte mot någon regel som sandlådan upprätthåller. Den skrev en fil. En process utanför sandlådan läste sedan filen, litade på den och körde det som stod där. Utbrytningen skedde utan att agenten någonsin nuddade gränsen.

Pillar sammanfattar fyndet på en rad: en agents skadeverkan är inte agentprocessen, den är allt som agenten kan skriva och som värden sedan litar på. Den meningen är nyheten, och den är skälet till att frågan inte är avklarad bara för att de enskilda buggarna rättas.

En socket förklarar tre av de fyra produkterna

Det tydligaste fyndet är också det minst uppseendeväckande. Codex CLI, Cursor och Gemini CLI kunde alla nå den lokala Docker-socketen inifrån sina sandlådor. En privilegierad daemon på värden startar villigt en container åt var och en som kan tala med den, och den containern körs helt utanför sandlådan. En enda säkerhetsnotis, GHSA-v4xv-rqh3-w9mc, omfattar tre av de fyra testade produkterna. Den är åtgärdad.

Codex hade ytterligare ett problem av annan sort. Dess vitlista över säkra kommandon litade på kommandon utifrån namnet. Den släppte igenom git show som en ren läsoperation utan att ta höjd för vad farliga argument till git show faktiskt kan uträtta. Det är rättat i version 0.95.0, och rapporten gav en bounty i allvarlighetsgraden hög.

Läser man de två sida vid sida framträder mönstret. Båda är listor över det tillåtna. Båda skrevs mot det som en driftansvarig kan se, en sökväg till en socket och ett kommandonamn, i stället för mot vad saken förmår när den väl har nåtts.

Utbrytningarna kom via filer som din editor redan litar på

Cursor gav tre fynd. En agent kunde skriva om tolken inuti en virtuell Python-miljö och vänta på att editorns eget Python-tillägg, som körs utan sandlåda, skulle köra den. Den kunde skapa en Git-katalog under ett namn som avvek från standard, så att sökvägsbaserade sandlåderegler inte slog till, och sedan låta fsmonitor fånga upp den. Och den kunde lägga en hook-konfiguration i arbetsytan som verktygen körde utan sandlåda. Det sista fyndet har CVE-2026-48124 och säkerhetsnotisen GHSA-pc9j-3qc2-95wv, och alla tre är rättade i Cursor 3.0.0.

Googles två fynd hör till samma familj. Seatbelt-profilen för macOS bakom Antigravity var skriven som en blockeringslista, vilket innebär att allt som inte uttryckligen är namngivet släpps igenom, och en .vscode-uppgiftskonfiguration kunde ta sig förbi skydden i Secure Mode. Google sade till forskarna att rapporten höll enastående kvalitet, klassade sedan fynden som svåra att utnyttja eftersom de kräver social manipulation, och nedgraderade dem på den grunden.

Klassningen går att försvara på sina egna premisser och saknar betydelse för den som kör verktygen i drift. Social manipulation innebär för en agent en mening i en README, en kommentar i ett ärende eller ett stycke i dokumentationen till ett beroende. Att läsa text som inte går att lita på är agentens helt vanliga arbetsdag.

Gränsen du köpte är inte den gräns du har

Var och en av produkterna framställer sandlådan som den kontroll som gör autonom programmering godtagbar. Det är det svar en säkerhetsgranskning får, och det är skälet till att godkännandena gavs. Forskningen visar att sandlådan styr en enda sak, agentprocessen. Den utlovade aldrig något om arbetsytan.

Arbetsytan är den verkliga angreppsytan, eftersom den läses av en lång rad processer som konstruerades långt innan agenterna fanns och som alla utgår från att en människa har skrivit det de läser. Python-tillägget. Git-daemonen. Docker-socketen. Pre-commit-hooken. Installationsverktyget för beroenden. CI-runnern som klonar grenen. Ingen av dem byggdes för att behandla innehållet i ett kodförråd som fientlig indata, och nu gör de alla precis det.

Alltså är det fel sak som styrs. Ägarna har godkänt agenter. Det som behöver en policy är arbetsytan, och regeln är kort: ett kodförråd som en AI-agent kan skriva i är indata som inte går att lita på för varje process längre ned i kedjan, på samma villkor som en fil uppladdad av en främling.

Vad du bör ändra den här veckan

Börja med socketen, eftersom en enda säkerhetsnotis omfattade tre av de fyra produkterna. Ingen kodagent behöver åtkomst till en Docker-socket, och att ta bort den är en konfigurationsändring, inte ett projekt. Uppgradera sedan versionerna. Cursor 3.0.0 och Codex CLI 0.95.0 är de rättade spåren, och utvecklingsverktyg uppdateras per användare snarare än per maskinpark, så att en leverantör har släppt en rättelse är inte samma sak som att dina utvecklare har den.

Den varaktiga ändringen gäller var agenterna körs. En gren som en agent har varit inne i bör nå CI utan förtroende, vilket i praktiken betyder att kedjan inte kör hookar, uppgifter eller tolkar som kommer från grenen förrän en människa har godkänt ändringarna. Det är ett beslut om kedjan snarare än om verktygen, och det håller även för nästa avslöjande.

Enligt NIS2 är en incident som börjar i en utvecklares editor och slutar i din produktionskedja anmälningspliktig inom samma tidsfrister som vilken annan som helst. Skyldigheten skiljer inte på en angripare som nätfiskat en utvecklare och en agent som läst en förgiftad README, så kontrollen måste sitta där kedjan kan upprätthålla den.

Läs vidare: nginx-fixen är ute, exploiten kommer i augusti  |  ServiceNow patchade sitt eget moln först, dig 103 dagar senare