Alapértelmezett homokozót kapott a Zed ügynökpanelje

Alapértelmezett korlátozások az ügynökpanelben

A Zed 2026. augusztus 5-i bejelentése szerint a sandboxolás a 1.14-es kiadástól minden felhasználónál alapértelmezett. A védelem az ügynökpanel terminál- és lekérőeszközeit érinti. A szabályokat az operációs rendszer érvényesíti, ezért azok nem az ügynök utasításkövetésére épülnek.

Az alapértelmezett sandbox megtiltja az ügynöknek, hogy a projektkönyvtárakon kívül írjon, a .git mappába írjon vagy hálózati kéréseket indítson. Ha egy feladathoz ennél több jogosultság kell, az ügynök ideiglenes jogosultságemelést kérhet. A felhasználó látja, milyen jogosultságokat kér az ügynök, és azt is, miért van rájuk szüksége.

A kérés engedélyezhető egyetlen alkalomra, az aktuális beszélgetés hátralévő részére vagy véglegesen. A .git mappához az ügynök nem kérhet írási hozzáférést, mivel ez lehetővé tenné olyan hookok írását, amelyek a sandboxon kívül futnak.

Miért nem elég egy utasítás vagy tiltólista?

A Zed szerint sok esetben elegendő lehet azt mondani az ügynöknek, hogy ne módosítson bizonyos fájlokat. A modern nagy nyelvi modellek általában jól követik az utasításokat, ez azonban nem garancia, és a promptinjekciók ellen sem nyújt megfelelő védelmet.

A fejlesztők egy nyílt forráskódú projekt példáját hozzák: egy módosított AGENTS.md arra utasíthatja az ügynököt, hogy egy titkos API-kulcsot küldjön el a támadó szerverére. A sandbox ezzel szemben egyszerűen megtagadja bizonyos erőforrások elérését.

A Zed már korábban is támogatott finomhangolt terminálszabályokat, például a git .* mintára illeszkedő parancsok tiltását. A cég szerint ezek jól működnek iránymutatásként egy megfelelően viselkedő ügynöknél, de egy támadó megkerülheti őket többek között héjparancsokkal, környezeti változókkal, átnevezett futtatható fájlokkal vagy Pythonnal.

Az operációs rendszerre támaszkodik, de nem teljes védelem

A Zed sandboxjai operációs rendszerhez kötött megoldásokat használnak. A macOS Seatbeltet alkalmaz, Linuxon a Bubblewrapon keresztüli névtereket, Windowson pedig a WSL-t. A WSL-en kívüli Windows-héjak nem támogatják a sandboxolást. Linuxon működő, setuid bit nélküli bwrap binárisra van szükség a PATH útvonalon, WSL esetén pedig a WSL-környezetben.

A Zed részletesen bemutat egy szimbolikus linkekkel végrehajtható, úgynevezett symlink swap támadást is. A támadás egy időzítési rést használhatna ki a felhasználói engedélykérés jóváhagyása és a könyvtár sandboxba csatolása között. A Zed közlése szerint a saját sandboxa ezt a támadást felismeri, és biztonsági okból nem futtatja le a megbízhatatlan parancsot.

A sandbox csak a terminál- és lekérőeszközöket védi. Nem terjed ki az ügynök más eszközeire, az ACP-n, LSP-n vagy MCP-szervereken keresztül csatlakozó ügynökökre, a beépített terminálon kívüli terminálokra és külső programokra, például a ghosttyra vagy a VSCode-ra. Egy rosszindulatú ügynök közvetetten olyan fájlokat is létrehozhat, amelyek később a sandboxon kívül futtatnak kódot, például build.rs-t, Git-hookot vagy rosszindulatú procedurális makrót.

A Zed ezért a sandboxolást többrétegű biztonsági stratégia egyik elemeként írja le. A megoldás az ügynök közvetlen műveleteit érdemben korlátozza, de a projekt és a fejlesztői környezet teljes védelméhez önmagában nem elegendő.