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

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

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

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

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

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

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

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

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

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

Развернуть

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

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

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

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

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

Развернуть

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

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

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

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

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

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

Токены полномочий действуют 120 секунд; при проверке срока действия допускается расхождение часов до 15 секунд. Корректной подписи и непросроченного токена все равно недостаточно, если выбранная и установленная идентичности не совпадают.

Развернуть

Отклонение запроса у неверного адресата

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

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

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

Развернуть

Проверка конечных точек моста

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

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

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

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

Развернуть

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

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

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

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

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

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

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

Правила повторной отправки по-прежнему зависят от конкретной операции. Бэкенд, пришедший на замену, должен заново пройти допуск, даже если WebSocket на стороне клиента остается открытым.

Развернуть

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

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

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

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

Сравнение с другими решениями в отрасли

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

• OpenShell: обеспечивает сопоставимый выбор выполнения для новых вызовов и привязку супервизора к среде выполнения за счет проверок поколения и авторизации в шлюзе, проверки идентичности бэкенда и подтвержденных активных подключений супервизора (допуск в шлюзе, аутентификация и привязка среды выполнения). SPACE передает подписанный выбор по всему пути обслуживания и добавляет локальную на рабочем узле проверку процессов и транспорта; OpenShell распределяет соответствующие проверки между своим шлюзом, идентичностью запуска и аутентифицированным протоколом среды выполнения (архитектура среды выполнения).
• E2B: отслеживает идентификаторы выполнений и изолирует пулы прокси по жизненному циклу Firecracker, однако входящий прокси выбирает логическую песочницу и порт без ожидаемой идентичности выполнения, с которой мог бы сверяться получатель (публикация маршрутов, допуск в прокси). Более старое выполнение, которое все еще зарегистрировано как активное на устаревшем получателе с совпадающими учетными данными, невозможно отличить этими проверками от выбранного более нового выполнения, хотя при штатном завершении работы маршруты удаляются, а привязанные к жизненному циклу подключения закрываются (учетные данные, завершение работы).
• CubeSandbox: восстанавливает маршрутизацию при возобновлении работы и инвалидирует кэши, однако приватный входящий трафик использует учетные данные уровня песочницы и пересылается без ожидаемой инкарнации среды выполнения (маршрутизация при возобновлении, маршрутизация входящего трафика). Восстановление маршрутов сокращает периоды, в течение которых действуют устаревшие маршруты; привязанный к выполнению токен полномочий в SPACE также дает получателю независимое основание отклонить неверную инкарнацию.

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

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

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

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