Как SPACE направляет запросы к нужному экземпляру песочницы

Когда пользователь просит ИИ-агент проанализировать электронную таблицу или протестировать ПО, он доверяет ему безопасную работу со своими файлами и данными. Агентам необходимы изолированные среды, в которых они могут выполнять эту работу, не подвергая риску данные других пользователей и не мешая их рабочим процессам.

Поскольку агенты берут на себя более сложные задачи с большей автономностью, такие среды помогают локализовать ошибки и ограничить ущерб, который может нанести небезопасный или вредоносный код. Песочницы обеспечивают такую изоляцию, разделяя при этом службы плоскости управления, рабочие узлы и инфраструктуру маршрутизации.

Эта общая инфраструктура должна доставлять каждую операцию именно в ту среду выполнения, которая уполномочена ее обрабатывать. Устаревший маршрут может отправить действительный запрос в другую песочницу или к более старому экземпляру выполнения правильной песочницы. SPACE, защищенная платформа песочниц от Perplexity, привязывает каждую операцию к выбранному экземпляру выполнения и проверяет пункт назначения перед пересылкой.

В течение нескольких месяцев SPACE обрабатывает миллионы запусков в день, каждый из которых защищен уникальной криптографической идентичностью, при этом уровень ошибок составляет менее 0,0002%, а количество потерянных соединений равно нулю.

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

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

Чтение файла проходит через несколько компонентов. Плоскость управления SPACE сопоставляет песочницу с экземпляром выполнения и рабочим узлом. Запрос поступает через node-api, передается в менеджер песочниц sbx-manager и через сокет Unix попадает на хост-мост spaced-host. Мост пересылает его по VSOCK (транспорт сокетов между хостом и гостевой ОС) в spaced-guest внутри микроВМ Firecracker.

Каждое решение опирается на состояние, которое может отставать от изменений инфраструктуры. База данных может сохранять старое размещение, кэшированный адрес может указывать в другое место, или путь к сокету может получить другой прослушиватель. Успешное соединение все равно может попасть не по адресу. Чтение может раскрыть данные другого пользователя; запись может изменить не ту файловую систему.

Снимки (снапшоты) создают еще одну проблему. Возобновление работы песочницы на другом рабочем узле сохраняет ее логическую идентичность, но запускает новый экземпляр выполнения. Задержанный запрос или уцелевшее соединение могут достичь предшественника и вернуть старое состояние под именем правильной песочницы.

Идентичность песочницы и идентичность выполнения

SPACE отделяет среду пользователя от обслуживающей ее среды выполнения:

• Идентичность песочницы: стабильный идентификатор логической среды. Авторизация вызывающего абонента устанавливает доступ к этой песочнице.
• Идентичность маршрута/выполнения: выбранное воплощение среды выполнения и его размещение, включая рабочий узел, подложку (substrate) и активацию.

Поколение выполнения различает воплощения среды выполнения. В Kubernetes маршрут также включает UID пода. Адреса определяют конечные точки; идентичность выполнения определяет, могут ли эти конечные точки обслуживать операцию.

Предположим, песочница S работает как выполнение 7 на рабочем узле A, а затем возобновляется как выполнение 8 на рабочем узле B. Запрос, выбранный для выполнения 8, должен завершиться с ошибкой, если он попадает на выполнение 7. Проверка только по ID песочницы не позволила бы обнаружить несоответствие.

Подписанный выбор выполнения

Каждый запрос содержит подлинное доказательство того, какая именно песочница может его обработать и какой доступ разрешен. Получающий компонент сверяет это доказательство со своей собственной идентичностью среды выполнения, прежде чем разрешить обработку запроса.

После авторизации вызывающей стороны SPACE выдает недолговечный подписанный мандат (capability), идентифицирующий песочницу, выполнение, размещение и разрешенный доступ. Мандаты общедоступных портов служб (service-port) также указывают разрешенный порт и протокол.

Менеджер получающей песочницы проверяет подпись и сравнивает полную идентичность со своей локально сохраненной записью о среде выполнения. Подпись устанавливает, кто санкционировал выбор. Сравнение показывает, соответствует ли этот выбор получателю.

Трафик ServicePort проходит вторую проверку на сетевом шлюзе для каждой песочницы, netgtw, до открытия гостевого соединения. Шлюз сравнивает идентичность с доверенным состоянием активации и проверяет порт и протокол. Операции управления переходят к верификации конечной точки моста.

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

Срок действия мандатов составляет 120 секунд с допуском на рассинхронизацию часов до 15 секунд. Действительная подпись и неиз истекший токен все равно недостаточчны, если выбранная и установленная идентичности не совпадают.

Отклонение в неверном пункте назначения

Рабочий узел-получатель может обнаружить ошибку маршрутизации, даже если сам запрос авторизован. Он проверяет, запущен ли на нем экземпляр выполнения, выбранный для этого запроса, и отклоняет запрос в случае их несовпадения.

Если запрос, выбранный для выполнения 8, попадает на рабочий узел A, который все еще обслуживает выполнение 7, узел A отклоняет его перед пересылкой. Как только получатель устанавливает идентичность выполнения 8, он также отклоняет мандаты для выполнения 7, даже до истечения срока их действия.

Существует важная граница этой гарантии. Мандат для выполнения 7 по-прежнему может соответствовать рабочему узлу, обслуживающему выполнение 7, до тех пор, пока этот узел не узнает об отзыве или пока срок действия мандата не истечет. Локальное принудительное применение и ограниченное время жизни мандата работают в тандеме по мере распространения обновлений.

Верификация конечной точки моста

Совпадающая запись среды выполнения определяет предполагаемое выполнение. Мост управления также должен получать доступ к процессам и транспорту, принадлежащим этой активации, а не к замене, унаследовавшей тот же адрес.

Менеджеры песочницы и узлов проверяют учетные данные пира хост-моста, а также идентичность процессов моста и Firecracker, включая время запуска, что позволяет обнаружить повторно используемые ID или измененные исполняемые файлы.

Проверки транспорта связывают прослушиватель VSOCK с ожидаемым процессом Firecracker с помощью владения сокетом, гостевой идентичности и данных сокета ядра. Мост пересылает операции только после верификации и отклоняет прозрачные переподключения. Каждое новое соединение должно проходить проверки заново.

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

Время жизни потока и восстановление маршрута

Некоторые соединения остаются открытыми во время изменения выполнения песочницы, поэтому проверки идентичности должны выходить за рамки первоначального запроса. SPACE отзывает соединения, привязанные к старому выполнению, и позволяет подходящим операциям переподключиться к текущему под теми же проверками безопасности.

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

SPACE повторно проверяет постоянную идентичность перед открытием потока. Замена его маршрута или выполнения аннулирует аренду потока, останавливая ввод и вывод.

Смена владельцев отличается от замены среды выполнения. Передача операции жизненного цикла для неизменного объекта Kubernetes сохраняет его идентификатор маршрута, неизведанные возможности и потоки. Шлюз также сохраняет установленные потоки для изменений, связанных исключительно с попыткой активации в рамках одного маршрута и поколения среды выполнения. Для новых открытий требуется обновленная идентичность.

Восстановление сохраняет эти проверки в силе. Компаратор идентификаторов может вернуть RefreshRoute в случае несовпадения воплощений в пределах одной песочницы или Deny для другой песочницы. Только распознанный сигнал обновления запускает восстановление маршрута после отклонения идентификатора. Сбои транспорта подчиняются отдельным правилам восстановления, зависящим от конкретной операции. Недействительные подписи, назначения или профили портов по-прежнему отклоняются.

Подходящая операция может определить текущую среду выполнения и предпринять одну попытку повторной сборки. Замена кэша зависит от отклоненного маршрута, что предотвращает вытеснение более новой записи запоздалым отклонением. Обновление нативного сеанса сохраняет исходный срок действия кэша, отделяя восстановление маршрута от продления авторизации вызывающей стороны.

Правила повтора остаются специфичными для конкретных операций. Сменный бэкенд должен заново пройти проверку допуска, даже если ориентированный на клиента WebSocket остается открытым.

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

Идентификатор среды выполнения становится критически важным для безопасности состоянием. Обновления плоскости управления и пакеты ключей проверки должны доходить до обслуживающих компонентов, а вывод из эксплуатации вступает в силу, когда каждый получатель устанавливает обновление. Короткий срок жизни возможностей ограничивает повторное использование во время распространения.

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

Проверка подписей, сравнения во время выполнения и проверка моста добавляют работы на пути запроса. Они используют локальное состояние, а не удаленный поиск авторизации при каждом частном переходе.

Сравнение в отрасли

Соответствующее сравнение заключается в том, как платформы обрабатывают авторизованный запрос, достигающий неправильной среды выполнения правильной песочницы. Эти выводы касаются проверенных реализаций, а не общей безопасности платформы. Системы SPACE, OpenShell и E2B были проверены 8 октября 2026 года:

• OpenShell: Обеспечивает сопоставимый выбор среды выполнения для новых вызовов и привязку супервизора к рантайму посредством генерации шлюза и проверок авторизации, валидации идентичности бэкенда и подтвержденных активных соединений с супервизором (gateway admission, runtime authentication and binding). SPACE переносит подписанный выбор по пути обслуживания и добавляет проверку локального процесса и транспорта воркера; OpenShell распределяет соответствующие проверки между своим шлюзом, идентичностью запуска и протоколом аутентифицированного рантайма (runtime design).
• E2B: Отслеживает идентификаторы среды выполнения и изолирует пулы прокси по жизненному циклу Firecracker, но входящий прокси выбирает логическую песочницу и порт без ожидаемого идентификатора среды выполнения для сравнения с получателем (route publication, proxy admission). Более старая среда выполнения, все еще зарегистрированная как активная на устаревшем получателе с совпадающим credentials, не может быть отличена от выбранной более новой среды выполнения посредством этих проверок, хотя обычный teardown удаляет маршруты и закрывает соединения, привязанные к жизненному циклу (учетные данные, завершение работы).
• CubeSandbox: Восстанавливает маршрутизацию при возобновлении и инвалидирует кэши, но частный ингресс использует учетные данные в рамках песочницы и пересылает данные без ожидаемого воплощения рантайма (resume routing, ingress routing). Восстановление маршрута сокращает окна устаревших маршрутов; возможность SPACE, привязанная к среде выполнения, также дает получателю независимое основание для отклонения неправильного воплощения.

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

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

SPACE делает идентификатор среды выполнения частью этой защиты. Проверяя пункты назначения, проверяя конечные точки моста и привязывая соединения к среде выполнения, которая их авторизовала, система сохраняет эти границы по мере того, как песочницы приостанавливаются, возобновляются и перемещаются.

Мы продолжаем эту работу по мере развития инфраструктуры. Для SPACE и других платформ песочниц безопасность требует тестирования этих путей как на предмет обычных ошибок маршрутизации, так и на предмет враждебных рабочих нагрузок, а затем укрепления границ везде, где эти тесты выявляют пробелы.