Как SPACE маршрутизира заявките към правилното изпълнение на sandbox средата

Когато някой помоли ИИ агент да анализира електронна таблица или да тества софтуер, той му се доверява да работи безопасно с неговите файлове и данни. Агентите се нуждаят от изолирани среди, в които да вършат тази работа, без да излагат данните на други потребители и без да пречат на техните работни натоварвания.

Докато агентите поемат все по-сложни задачи с по-голяма автономност, тези среди помагат да се ограничат грешките и щетите, които опасен или злонамерен код може да причини. Sandbox средите осигуряват тази изолация, като същевременно споделят услугите на контролната равнина, работните възли и инфраструктурата за маршрутизация.

Тази споделена инфраструктура трябва да доставя всяка операция до изпълнението, оторизирано да я обработи. Остарял маршрут може да изпрати валидна заявка до друга sandbox среда или до по-старо изпълнение на правилната sandbox среда. SPACE, защитената sandbox платформа на Perplexity, обвързва всяка операция с избрано изпълнение и проверява местоназначението преди препращане.

От месеци SPACE обработва милиони изпълнения на ден, всяко от които е защитено с уникална криптографска идентичност, с процент на грешки под 0,0002% и нито една прекъсната връзка.

Проблемът с маршрутизацията

Сигурността на sandbox средите зависи и от това всяка заявка да стигне до правилното местоназначение. Дори обикновено четене на файл преминава през споделена инфраструктура, която трябва да следи къде работи sandbox средата, докато тя се поставя на пауза, възобновява или премества между машини.

Четенето на файл преминава през няколко компонента. Контролната равнина на SPACE съпоставя sandbox средата с изпълнение и работен възел. Заявката влиза през node-api, преминава към мениджъра на sandbox средата, sbx-manager, и през Unix сокет стига до хост моста, spaced-host. Мостът я препраща през VSOCK, транспорта за сокети между хоста и гост системата, до spaced-guest в microVM на Firecracker.

Всяко решение разчита на състояние, което може да изостава от промените в инфраструктурата. Базата данни може да пази старо разположение, кеширан адрес може да сочи другаде, а пътят до сокет може да получи друг слушател. Успешната връзка все пак може да достигне грешното местоназначение. Четенето може да разкрие данните на друг потребител; записът може да промени грешната файлова система.

Моментните снимки добавят още един проблем. Възобновяването на sandbox среда на друг работен възел запазва логическата ѝ идентичност, но стартира ново изпълнение. Забавена заявка или оцеляла връзка може да достигне предшественика на това изпълнение и да върне старо състояние под името на правилната sandbox среда.

Уголеми

Идентичност на Sandbox и идентичност на изпълнението

SPACE разделя средата на потребителя от средата за изпълнение, която я обслужва:

• Идентичност на sandbox средата: Стабилният идентификатор на логическата среда. Оторизацията на извикващия установява достъпа до тази sandbox среда.
• Идентичност на маршрута/изпълнението: Избраната инкарнация на средата за изпълнение и нейното разположение, включително нейния worker, субстрат и активиране.

Генерацията на изпълнението разграничава инкарнациите на средата за изпълнение. В Kubernetes маршрутът включва и UID на пода. Адресите локализират крайните точки; идентичността на изпълнението определя дали тези крайни точки могат да обслужат операцията.

Да предположим, че sandbox среда S работи като изпълнение 7 на работен възел A, след което се възобновява като изпълнение 8 на работен възел B. Заявка, избрана за изпълнение 8, трябва да се провали, ако достигне изпълнение 7. Проверката само на ID на sandbox средата не би уловила разминаването.

Уголеми

Подписан избор на изпълнение

Всяка заявка носи подписано доказателство за това кое изпълнение на sandbox средата може да я обработи и какъв достъп е разрешен. Приемащият компонент сверява това доказателство със собствената си идентичност на средата за изпълнение, преди да позволи на заявката да продължи.

След оторизацията на извикващия SPACE издава краткотрайно подписано пълномощие, което идентифицира sandbox средата, изпълнението, разположението и разрешения достъп. Пълномощията за публични сервизни портове посочват също разрешения порт и протокол.

Приемащият мениджър на sandbox средата проверява подписа и сравнява пълната идентичност с локално съхранения си запис за средата за изпълнение. Подписът установява кой е оторизирал избора. Сравнението установява дали този избор съответства на получателя.

Трафикът на ServicePort преминава втора проверка в мрежовия шлюз на всяка sandbox среда, netgtw, преди да се отвори връзка към гост системата. Шлюзът сравнява идентичността с довереното състояние на активацията и проверява порта и протокола. Контролните операции продължават към проверката на крайните точки на моста.

SPACE използва подписи Ed25519. Ключовете за подписване на контролната равнина издават пълномощия; публичните ключове за проверка в работните възли и шлюзовете не могат да ги издават.

Пълномощията са валидни 120 секунди, като при изтичането се допуска разминаване на часовниците до 15 секунди. Валиден подпис и неизтекъл токен все пак не са достатъчни, когато избраната и инсталираната идентичност се разминават.

Уголеми

Отхвърляне при грешно местоназначение

Приемащият работен възел може да улови грешка в маршрутизацията, дори когато самата заявка е оторизирана. Той проверява дали при него работи изпълнението, избрано за тази заявка, и я отхвърля, ако има разминаване.

Ако заявка, избрана за изпълнение 8, достигне до worker A, който все още обслужва изпълнение 7, worker A я отхвърля, преди да я препрати. След като получателят инсталира идентичността на изпълнение 8, той отхвърля и правомощията (capabilities) за изпълнение 7, дори преди те да са изтекли.

Тази гаранция има важна граница. Пълномощие за изпълнение 7 все още може да съвпадне с работен възел, обслужващ изпълнение 7, докато този възел не научи за извеждането на изпълнението от експлоатация или пълномощието не изтече. Локалното прилагане и ограниченият срок на валидност на пълномощията действат заедно, докато актуализациите се разпространяват.

Уголеми

Проверка на крайните точки на моста

Съвпадащият запис за средата за изпълнение установява целевото изпълнение. Контролният мост трябва също да достигне процесите и транспорта, принадлежащи на тази активация, а не заместител, наследил същия адрес.

Мениджърите на sandbox средата и на възела проверяват идентификационните данни на отсрещната страна на хост моста и идентичността на процесите както на моста, така и на Firecracker, включително времената им на стартиране, като откриват повторно използвани ID или променени изпълними файлове

Транспортните проверки обвързват VSOCK слушателя с очаквания процес на Firecracker чрез собствеността върху сокета, идентичността на гост системата и данните за сокета от ядрото. Мостът препраща операции само след проверка и отказва прозрачно повторно свързване. Всяка нова връзка трябва да премине проверките отново.

Тази проверка обхваща контролния мост на Firecracker в Kubernetes и на директно управлявани хостове. Трафикът на ServicePort използва проверки на изпълнението и порта в своя шлюз; той не удостоверява идентичността на произволно приложение в гост системата.

Уголеми

Продължителност на потоците и възстановяване на маршрутите

Някои връзки остават отворени, докато изпълнението на sandbox средата се сменя, затова проверките на идентичността трябва да се простират отвъд първоначалната заявка. SPACE прекратява връзките, обвързани със старото изпълнение, и позволява на допустимите операции да се свържат отново с текущото при същите проверки за сигурност.

Терминалите и наблюденията на файлове могат да надживеят заявките, които са ги отворили. SPACE обвързва бекенд потоците с епоха на идентичността, така че потокът да не може да остане свързан с предишното изпълнение, след като получателят инсталира заместващо изпълнение.

SPACE проверява отново трайната идентичност, преди да отвори поток. Замяната на маршрута или изпълнението му отменя наема на потока, като спира входа и изхода.

Промените в собствеността се различават от замяната на изпълнението. Предаването на операция от жизнения цикъл при непроменен резидент в Kubernetes запазва идентичността на маршрута му, неизтеклите пълномощия и потоците. Шлюзът също запазва установените потоци при промени, засягащи само опита за активиране, в рамките на същия маршрут и същата генерация на изпълнението. Отварянето на нови потоци изисква актуализираната идентичност.

Възстановяването запазва тези проверки непокътнати. Компараторът на идентичност може да върне RefreshRoute при несъответствие на инкарнацията в рамките на същия Sandbox или Deny при различен Sandbox. Само разпознат сигнал за опресняване задейства поправка на маршрута след отхвърляне на идентичността. Грешките на транспортно ниво следват отделни правила за възстановяване, специфични за всяка операция. Невалидните подписи, предназначения или профили на портове продължават да бъдат отхвърляни.

Допустима операция може да определи текущото изпълнение и да направи един повторен опит с наново изграден маршрут. Замяната в кеша е обусловена от отхвърления маршрут, което не позволява забавено отхвърляне да изтрие по-нов запис. Обновяването на нативната сесия запазва първоначалния срок на валидност в кеша, като отделя поправката на маршрута от подновяването на оторизацията на извикващия.

Правилата за повторно изпращане остават специфични за всяка операция. Заместващият бекенд трябва отново да премине допускане, дори когато WebSocket връзката към клиента остава отворена.

Уголеми

Компромиси и граници на доверие

Идентичността на изпълнението се превръща в критично за сигурността състояние. Актуализациите от контролната равнина и пакетите с ключове за проверка трябва да достигат обслужващите компоненти, а извеждането от експлоатация влиза в сила, когато всеки получател инсталира актуализацията. Краткият срок на валидност на пълномощията ограничава повторното им използване по време на разпространението.

Дизайнът предполага, че прилагането на идентичността е включено, и се доверява на подписващия компонент на контролната равнина, ядрото на работния възел и локалните за възела услуги за управление. Компрометирането на root достъпа до работен възел или на привилегирован администратор на клъстера е извън модела на заплахите. Проверката на моста е локална проверка на процесите и транспорта, а не хардуерно базирана отдалечена атестация.

Проверката на подписите, сравненията на средата за изпълнение и валидирането на моста добавят работа по пътя на заявката. Те използват локално състояние, а не отдалечена проверка на оторизацията при всяка частна стъпка.

Сравнение с индустрията

Същественото сравнение е как платформите се справят с оторизирана заявка, която достига грешно изпълнение на правилната sandbox среда. Тези констатации се отнасят до прегледаните имплементации, а не до цялостната сигурност на платформите. SPACE, OpenShell и E2B бяха проверени на 8 октомври 2026 г.:

• OpenShell: Осигурява сравним избор на изпълнение за нови извиквания и обвързване на супервайзора със средата за изпълнение чрез проверки на генерацията и оторизацията в шлюза, валидиране на идентичността на бекенда и потвърдени активни връзки на супервайзора (допускане в шлюза, удостоверяване и обвързване на средата за изпълнение). SPACE пренася подписания избор по целия си път на обслужване и добавя локална за работния възел проверка на процесите и транспорта; OpenShell разпределя съответните проверки между своя шлюз, идентичността при стартиране и удостоверения протокол на средата за изпълнение (дизайн на средата за изпълнение).
• E2B: Проследява ID на изпълненията и изолира пуловете от проксита според жизнения цикъл на Firecracker, но входящото му прокси избира логическата sandbox среда и порта без очаквана идентичност на изпълнението, с която получателят да направи сравнение (публикуване на маршрути, допускане в проксито). По-старо изпълнение, все още регистрирано като активно на остарял получател със съвпадащи идентификационни данни, не може да бъде разграничено от избраното по-ново изпълнение чрез тези проверки, макар че нормалното премахване изтрива маршрутите и затваря връзките, обвързани с жизнения цикъл (идентификационни данни, премахване).
• CubeSandbox: Поправя маршрутизацията при възобновяване и инвалидира кешовете, но частният входящ път използва идентификационни данни с обхват на sandbox средата и препраща без очаквана инкарнация на средата за изпълнение (маршрутизация при възобновяване, маршрутизация на входящия трафик). Поправката на маршрутите съкращава периодите с остарели маршрути; обвързаното с изпълнението пълномощие на SPACE освен това дава на получателя независимо основание да отхвърли грешната инкарнация.

Идентичността като граница на изолация

Безопасното делегиране зависи от това работата на всеки агент да остава в предвидените за нея граници. MicroVM осигурява изолация, а заобикалящата я платформа трябва да гарантира, че всяка заявка и всяка продължаваща връзка достигат изпълнението, оторизирано да ги обработи.

SPACE прави идентичността на изпълнението част от тази защита. Като проверява местоназначенията, верифицира крайните точки на моста и обвързва връзките с изпълнението, което ги е оторизирало, SPACE запазва тези граници, докато sandbox средите се поставят на пауза, възобновяват и преместват.

Продължаваме работата с развитието на инфраструктурата. За SPACE и другите sandbox платформи сигурността изисква тези пътища да се тестват както срещу рутинни грешки в маршрутизацията, така и срещу враждебни работни натоварвания, а след това границите да се укрепват навсякъде, където тестовете разкрият пропуски.