Így irányítja a SPACE a kéréseket a megfelelő sandbox-végrehajtáshoz

Amikor valaki arra kér egy MI-ügynököt, hogy elemezzen egy táblázatot vagy teszteljen egy szoftvert, abban bízik, hogy az ügynök biztonságosan bánik a fájljaival és adataival. Az ügynököknek elkülönített környezetekre van szükségük, ahol úgy végezhetik ezt a munkát, hogy közben nem teszik ki más felhasználók adatait, és nem zavarják azok munkaterheléseit.

Ahogy az ügynökök egyre nagyobb önállósággal egyre összetettebb feladatokat vállalnak, ezek a környezetek segítenek a hibák elszigetelésében, és korlátozzák a nem biztonságos vagy rosszindulatú kód által okozható kárt. A sandboxok úgy biztosítják ezt az elkülönítést, hogy közben közösen használják a vezérlősík-szolgáltatásokat, a munkacsomópontokat és az útválasztási infrastruktúrát.

Ennek a megosztott infrastruktúrának minden műveletet ahhoz a végrehajtáshoz kell eljuttatnia, amely jogosult a kezelésére. Egy elavult útvonal egy érvényes kérést egy másik sandboxhoz, vagy a megfelelő sandbox egy régebbi végrehajtásához is eljuttathat. A SPACE, a Perplexity biztonságos sandbox-platformja, minden műveletet egy kiválasztott végrehajtáshoz köt, és továbbítás előtt ellenőrzi a célt.

A SPACE hónapok óta naponta több millió végrehajtást kezel, amelyek mindegyikét egyedi kriptográfiai identitás védi, 0,0002% alatti hibaaránnyal és egyetlen megszakadt kapcsolat nélkül.

Az útválasztási probléma

A sandbox biztonsága azon is múlik, hogy minden kérés a megfelelő célhoz jusson el. Még egy egyszerű fájlolvasás is olyan megosztott infrastruktúrán halad át, amelynek nyomon kell követnie, hol fut a sandbox, miközben az szünetel, folytatódik vagy gépek között mozog.

Egy fájlolvasás több komponensen halad át. A SPACE vezérlősíkja a sandboxot egy végrehajtáshoz és egy munkacsomóponthoz rendeli. A kérés a node-api komponensen keresztül lép be, továbbhalad a sandbox-kezelőhöz (sbx-manager), majd egy Unix socketen át eljut a gazdagéphídhoz (spaced-host). A híd VSOCK-on – a gazdagép és a vendég közötti socketalapú átvitelen – keresztül továbbítja a Firecracker microVM-en belül futó spaced-guest komponenshez.

Minden döntés olyan állapotra támaszkodik, amely lemaradhat az infrastruktúra változásaitól. Egy adatbázis megőrizhet egy régi elhelyezést, egy gyorsítótárazott cím máshová mutathat, vagy egy socketútvonalhoz más figyelő kapcsolódhat. Egy sikeres kapcsolat is eljuthat rossz célhoz. Egy olvasás felfedheti egy másik felhasználó adatait; egy írás a rossz fájlrendszert módosíthatja.

A pillanatképek újabb problémát vetnek fel. Ha egy sandboxot egy másik munkacsomóponton folytatunk, a logikai identitása megmarad, de új végrehajtás indul. Egy késleltetett kérés vagy egy fennmaradt kapcsolat eljuthat az elődjéhez, és a helyes sandboxnév alatt régi állapotot adhat vissza.

Nagyítás

Sandbox-identitás és végrehajtási identitás

A SPACE elválasztja a felhasználó környezetét az azt kiszolgáló futtatókörnyezettől:

• Sandbox-identitás: A logikai környezet állandó azonosítója. A hívó engedélyezése ehhez a sandboxhoz biztosít hozzáférést.
• Útvonal-/végrehajtási identitás: A kiválasztott futtatókörnyezeti inkarnáció és annak elhelyezése, beleértve a workert, az alapréteget (substrate) és az aktiválást.

A végrehajtási generáció különbözteti meg egymástól a futásidejű példányokat. Kubernetesen az útvonal a pod UID-ját is tartalmazza. A címek a végpontok helyét határozzák meg; a végrehajtási identitás dönti el, hogy ezek a végpontok kiszolgálhatják-e a műveletet.

Tegyük fel, hogy az S sandbox a 7-es végrehajtásként fut az A munkacsomóponton, majd a 8-as végrehajtásként folytatódik a B munkacsomóponton. A 8-as végrehajtáshoz kiválasztott kérésnek meg kell hiúsulnia, ha a 7-es végrehajtáshoz jut el. Ha csak a sandbox azonosítóját ellenőriznénk, az eltérés észrevétlen maradna.

Nagyítás

Aláírt végrehajtás-kiválasztás

Minden kérés aláírt igazolást hordoz arról, hogy melyik sandbox-végrehajtás kezelheti, és milyen hozzáférés engedélyezett. A fogadó komponens a saját futásidejű identitásával veti össze ezt az igazolást, mielőtt továbbengedné a kérést.

A hívó engedélyezése után a SPACE egy rövid élettartamú, aláírt képességet állít ki, amely azonosítja a sandboxot, a végrehajtást, az elhelyezést és az engedélyezett hozzáférést. A nyilvános szolgáltatásport-képességek az engedélyezett portot és protokollt is meghatározzák.

A fogadó sandbox-kezelő ellenőrzi az aláírást, és összeveti a teljes identitást a helyileg tárolt futásidejű rekordjával. Az aláírás azt igazolja, ki engedélyezte a kiválasztást. Az összevetés azt állapítja meg, hogy a kiválasztás megfelel-e a fogadónak.

A ServicePort-forgalom egy második ellenőrzésen is átesik a sandboxonkénti hálózati átjárónál (netgtw), mielőtt vendégkapcsolat nyílna. Az átjáró összeveti az identitást a megbízható aktiválási állapottal, és ellenőrzi a portot és a protokollt. A vezérlőműveletek a híd végpontjainak ellenőrzéséhez haladnak tovább.

A SPACE Ed25519-aláírásokat használ. A képességeket a vezérlősík aláírókulcsai állítják ki; a munkacsomópontokon és az átjárókon lévő nyilvános ellenőrzőkulcsok nem képesek kiállítani őket.

A képességek 120 másodpercig érvényesek, a lejáratnál legfeljebb 15 másodperces óraeltérési ráhagyással. Az érvényes aláírás és a le nem járt token sem elegendő, ha a kiválasztott és a telepített identitás eltér.

Nagyítás

Elutasítás a rossz célállomáson

A fogadó munkacsomópont akkor is észreveheti az útválasztási hibát, ha maga a kérés engedélyezett. Ellenőrzi, hogy azt a végrehajtást futtatja-e, amelyet az adott kéréshez kiválasztottak, és eltérés esetén elutasítja a kérést.

Ha a 8. végrehajtáshoz kiválasztott kérés eljut az A workerhez, amely még a 7. végrehajtást szolgálja ki, az A worker a továbbítás előtt elutasítja. Amint egy fogadó telepíti a 8. végrehajtás identitását, a 7. végrehajtáshoz tartozó képességeket (capabilities) is elutasítja, még a lejáratuk előtt.

Ennek a garanciának van egy fontos korlátja. A 7-es végrehajtásra szóló képesség továbbra is egyezhet egy olyan munkacsomóponttal, amely a 7-es végrehajtást szolgálja ki, amíg az adott munkacsomópont nem értesül a kivezetésről, vagy a képesség le nem jár. A helyi kikényszerítés és a korlátozott képesség-élettartam együtt nyújt védelmet, amíg a frissítések terjednek.

Nagyítás

A híd végpontjainak ellenőrzése

Az egyező futásidejű rekord meghatározza a szándékolt végrehajtást. A vezérlőhídnak emellett az adott aktiváláshoz tartozó folyamatokat és átvitelt is el kell érnie, nem pedig egy olyan helyettesítőt, amely ugyanazt a címet örökölte.

A sandbox- és csomópontkezelők ellenőrzik a gazdagéphíd társfél-hitelesítő adatait, valamint a híd és a Firecracker folyamatidentitását is, az indítási időpontokkal együtt, így észlelik az újrahasznosított azonosítókat vagy a megváltozott futtatható fájlokat

Az átviteli ellenőrzések a socket tulajdonjoga, a vendégidentitás és a kernelszintű socketbizonyítékok alapján kötik a VSOCK-figyelőt az elvárt Firecracker-folyamathoz. A híd csak az ellenőrzés után továbbít műveleteket, és elutasítja az átlátszó újracsatlakozást. Minden új kapcsolatnak újra át kell mennie az ellenőrzéseken.

Ez az ellenőrzés a Firecracker vezérlőhídjára terjed ki Kubernetesen és a közvetlenül felügyelt gazdagépeken. A ServicePort-forgalom esetében az átjáró végrehajtás- és portellenőrzést végez; ez nem igazolja a vendégrendszeren belül futó tetszőleges alkalmazások identitását.

Nagyítás

Az adatfolyamok élettartama és az útvonal-helyreállítás

Egyes kapcsolatok nyitva maradnak, miközben egy sandbox végrehajtása megváltozik, ezért az identitásellenőrzéseknek a kezdeti kérésen túl is érvényesülniük kell. A SPACE kivezeti a régi végrehajtáshoz kötött kapcsolatokat, a jogosult műveletek pedig ugyanazon biztonsági ellenőrzések mellett újracsatlakozhatnak az aktuális végrehajtáshoz.

A terminálok és a fájlfigyelők túlélhetik az őket megnyitó kéréseket. A SPACE a háttérrendszer adatfolyamait egy identitás-epochhoz köti, így egy adatfolyam nem maradhat az elődjéhez csatolva, miután a fogadó telepítette a helyettesítő végrehajtást.

A SPACE egy adatfolyam megnyitása előtt újra ellenőrzi a tartós identitást. Az útvonal vagy a végrehajtás lecserélése visszavonja az adatfolyam bérletét, és leállítja a bemenetet és a kimenetet.

A tulajdonosváltás nem azonos a végrehajtás lecserélésével. Egy változatlan Kubernetes-rezidensen végzett életciklus-művelet átadása megőrzi a rezidens útvonal-identitását, le nem járt képességeit és adatfolyamait. Az átjáró a már létrejött adatfolyamokat azoknál a változásoknál is megőrzi, amelyek csak az aktiválási kísérletet érintik ugyanazon az útvonalon és végrehajtási generáción belül. Az új megnyitásokhoz a frissített identitás szükséges.

A helyreállítás során ezek az ellenőrzések érintetlenek maradnak. Az identitás-összehasonlító ugyanazon a sandboxon belüli inkarnációeltérés esetén RefreshRoute, eltérő sandbox esetén pedig Deny értéket adhat vissza. Identitáselutasítás után kizárólag egy felismert frissítési jelzés indít útvonaljavítást. Az átviteli hibákra külön, műveletspecifikus helyreállítási szabályok vonatkoznak. Az érvénytelen aláírásokat, célokat vagy portprofilokat a rendszer továbbra is elutasítja.

Egy erre jogosult művelet feloldhatja az aktuális végrehajtást, és egyetlen újraépített kísérletet tehet. A gyorsítótár-bejegyzés cseréje csak akkor történik meg, ha az még az elutasított útvonalat tartalmazza, így egy késleltetett elutasítás nem szoríthat ki egy újabb bejegyzést. A natív munkamenet frissítése megőrzi a gyorsítótár eredeti lejáratát, így az útvonal-helyreállítás elkülönül a hívó engedélyének megújításától.

Az újrajátszási szabályok továbbra is műveletspecifikusak. A helyettesítő háttérrendszernek ismét át kell mennie a beengedésen, még akkor is, ha a kliens felé néző WebSocket-kapcsolat nyitva marad.

Nagyítás

Kompromisszumok és bizalmi határok

A végrehajtási identitás biztonsági szempontból kritikus állapottá válik. A vezérlősík frissítéseinek és az ellenőrzőkulcs-csomagoknak el kell jutniuk a kiszolgáló komponensekhez, a kivezetés pedig akkor lép érvénybe, amikor az egyes fogadók telepítik a frissítést. A rövid képesség-élettartam korlátozza az újrafelhasználást a terjedés ideje alatt.

A kialakítás feltételezi, hogy az identitás-kikényszerítés engedélyezve van, és megbízik a vezérlősík aláírójában, a munkacsomópont kerneljében és a csomópont helyi felügyeleti szolgáltatásaiban. A munkacsomópont root jogosultságának vagy egy privilegizált fürtadminisztrátornak a kompromittálódása kívül esik a fenyegetési modellen. A hídellenőrzés helyi folyamat- és átviteli ellenőrzés, nem pedig hardveresen támogatott távoli tanúsítás.

Az aláírás-ellenőrzés, a futásidejű összevetések és a hídvalidálás többletmunkát jelent a kérés útvonalán. Ezek helyi állapotot használnak ahelyett, hogy minden privát ugrásnál távoli engedélyezési lekérdezést végeznének.

Iparági összehasonlítás

A releváns összehasonlítás az, hogyan kezelik a platformok, ha egy engedélyezett kérés a megfelelő sandbox rossz végrehajtásához jut el. Ezek a megállapítások a vizsgált implementációkra vonatkoznak, nem a platformok általános biztonságára. A SPACE-t, az OpenShellt és az E2B-t 2026. október 8-án vizsgáltuk:

• OpenShell: Hasonló, új hívásokra vonatkozó végrehajtás-kiválasztást és felügyelő–futtatókörnyezet kötést biztosít az átjáró generációs és engedélyezési ellenőrzésein, a háttérrendszer identitásának validálásán és a megerősített aktív felügyelői kapcsolatokon keresztül (átjáró-beengedés, futásidejű hitelesítés és kötés). A SPACE a teljes kiszolgálási útvonalon végigviszi az aláírt kiválasztást, és munkacsomópont-szintű folyamat- és átviteli ellenőrzéssel egészíti ki; az OpenShell a megfelelő ellenőrzéseket az átjáró, az indítási identitás és a hitelesített futásidejű protokoll között osztja el (futásidejű kialakítás).
• E2B: Nyomon követi a végrehajtási azonosítókat, és a Firecracker életciklusa szerint különíti el a proxykészleteket, a bejövő proxyja azonban a logikai sandboxot és a portot választja ki, a fogadói összevetéshez szükséges elvárt végrehajtási identitás nélkül (útvonal-közzététel, proxybeengedés). Egy régebbi végrehajtást, amely egy elavult fogadón egyező hitelesítő adatokkal még élőként van regisztrálva, ezek az ellenőrzések nem tudnak megkülönböztetni a kiválasztott újabb végrehajtástól, bár a szokásos lebontás eltávolítja az útvonalakat, és lezárja az életciklushoz kötött kapcsolatokat (hitelesítő adatok, lebontás).
• CubeSandbox: Folytatáskor helyreállítja az útválasztást és érvényteleníti a gyorsítótárakat, a privát bejövő forgalom azonban sandbox-szintű hitelesítő adatokat használ, és elvárt futásidejű példány nélkül továbbít (útválasztás folytatáskor, bejövő útválasztás). Az útvonal-helyreállítás szűkíti az elavult útvonalak időablakait; a SPACE végrehajtáshoz kötött képessége emellett független alapot ad a fogadónak a rossz példány elutasításához.

Az identitás mint elkülönítési határ

A biztonságos delegálás azon múlik, hogy minden ügynök munkája a számára kijelölt határokon belül maradjon. A microVM biztosítja az elkülönítést, a körülötte lévő platformnak pedig gondoskodnia kell arról, hogy minden kérés és folyamatban lévő kapcsolat ahhoz a végrehajtáshoz jusson el, amely jogosult a kezelésére.

A SPACE a végrehajtási identitást ennek a védelemnek a részévé teszi. A célok ellenőrzésével, a híd végpontjainak hitelesítésével és a kapcsolatoknak az őket engedélyező végrehajtáshoz kötésével megőrzi ezeket a határokat, miközben a sandboxok szünetelnek, folytatódnak és mozognak.

Az infrastruktúra fejlődésével párhuzamosan folytatjuk a munkát. A SPACE és más sandbox-platformok esetében a biztonság megköveteli, hogy ezeket az útvonalakat a rutinszerű útválasztási hibákkal és az ártó szándékú munkaterhelésekkel szemben is teszteljük, majd megerősítsük a határokat mindenhol, ahol a tesztek hiányosságokat tárnak fel.