Com encamina SPACE les sol·licituds a l’execució correcta de l’entorn de proves

Quan algú demana a un agent d’IA que analitzi un full de càlcul o que provi programari, confia que treballarà de manera segura amb els seus fitxers i dades. Els agents necessiten entorns aïllats on puguin fer aquesta feina sense exposar les dades d’altres usuaris ni interferir en les seves càrregues de treball.

A mesura que els agents assumeixen tasques més complexes amb més autonomia, aquests entorns ajuden a contenir els errors i a limitar els danys que pot causar el codi insegur o maliciós. Els entorns de proves proporcionen aquest aïllament alhora que comparteixen serveis del pla de control, nodes de treball i infraestructura d’encaminament.

Aquesta infraestructura compartida ha de lliurar cada operació a l’execució autoritzada per gestionar-la. Una ruta obsoleta pot enviar una sol·licitud vàlida a un altre entorn de proves, o a una execució anterior de l’entorn de proves correcte. SPACE, la plataforma segura d’entorns de proves de Perplexity, vincula cada operació a una execució seleccionada i comprova la destinació abans de reenviar-la.

Des de fa mesos, SPACE gestiona milions d'execucions al dia, cadascuna protegida per una identitat criptogràfica única, amb una taxa d'error inferior al 0,0002 % i cap connexió perduda.

El problema de l’encaminament

La seguretat dels entorns de proves també depèn de fer arribar cada sol·licitud a la destinació correcta. Fins i tot una simple lectura de fitxer passa per una infraestructura compartida que ha de saber en tot moment on s’executa l’entorn de proves mentre es posa en pausa, es reprèn o es trasllada entre màquines.

Una lectura de fitxer travessa diversos components. El pla de control de SPACE resol l’entorn de proves en una execució i un node de treball. La sol·licitud entra per node-api, passa al gestor d’entorns de proves, sbx-manager, i travessa un sòcol Unix fins al pont de l’amfitrió, spaced-host. El pont la reenvia per VSOCK, el transport de sòcols entre amfitrió i convidat, fins a spaced-guest, dins de la microVM de Firecracker.

Cada decisió es basa en un estat que pot quedar endarrerit respecte als canvis de la infraestructura. Una base de dades pot conservar una ubicació antiga, una adreça desada a la memòria cau pot apuntar a un altre lloc o una ruta de sòcol pot passar a tenir un procés d’escolta diferent. Una connexió correcta encara pot arribar a la destinació incorrecta. Una lectura podria exposar les dades d’un altre usuari; una escriptura podria modificar el sistema de fitxers equivocat.

Les instantànies plantegen un altre problema. Reprendre un entorn de proves en un altre node de treball en conserva la identitat lògica, però inicia una execució nova. Una sol·licitud endarrerida o una connexió que hagi sobreviscut pot arribar a la seva predecessora i retornar un estat antic sota el nom correcte de l’entorn de proves.

Amplia

Identitat de l'entorn de proves i identitat d'execució

SPACE separa l’entorn de l’usuari de l’entorn d’execució que el serveix:

• Identitat de l’entorn de proves: L’identificador estable de l’entorn lògic. L’autorització de qui fa la crida estableix l’accés a aquest entorn de proves.
• Identitat de ruta/execució: l'encarnació seleccionada de l'entorn d'execució i la seva ubicació, inclosos el worker, el substrat i l'activació.

Una generació d’execució distingeix les encarnacions de l’entorn d’execució. A Kubernetes, la ruta també inclou l’UID del pod. Les adreces localitzen els extrems; la identitat d’execució determina si aquests extrems poden servir l’operació.

Suposem que l’entorn de proves S s’executa com a execució 7 al node de treball A i després es reprèn com a execució 8 al node de treball B. Una sol·licitud seleccionada per a l’execució 8 ha de fallar si arriba a l’execució 7. Si només es comprovés l’identificador de l’entorn de proves, no es detectaria la discrepància.

Amplia

Selecció d'execució signada

Cada sol·licitud porta una prova signada de quina execució de l’entorn de proves la pot gestionar i de quin accés es permet. El component receptor contrasta aquesta prova amb la seva pròpia identitat d’execució abans de deixar continuar la sol·licitud.

Després de l’autorització de qui fa la crida, SPACE emet una capacitat signada de curta durada que identifica l’entorn de proves, l’execució, la ubicació i l’accés permès. Les capacitats públiques de ports de servei també especifiquen el port i el protocol permesos.

El gestor d’entorns de proves receptor verifica la signatura i compara la identitat completa amb el registre d’execució que té desat localment. La signatura estableix qui ha autoritzat la selecció. La comparació estableix si aquesta selecció correspon al receptor.

El trànsit de ServicePort passa una segona comprovació a la passarel·la de xarxa de cada entorn de proves, netgtw, abans que s’obri una connexió amb el convidat. La passarel·la compara la identitat amb l’estat d’activació de confiança i comprova el port i el protocol. Les operacions de control continuen cap a la verificació dels extrems del pont.

SPACE utilitza signatures Ed25519. Les claus de signatura del pla de control emeten capacitats; les claus públiques de verificació dels nodes de treball i de les passarel·les no en poden emetre.

Les capacitats duren 120 segons, amb un marge de fins a 15 segons per al desfasament de rellotge en la caducitat. Una signatura vàlida i un testimoni no caducat continuen sent insuficients quan les identitats seleccionada i instal·lada no coincideixen.

Amplia

Rebuig a la destinació incorrecta

El node de treball receptor pot detectar un error d’encaminament fins i tot quan la sol·licitud en si està autoritzada. Comprova si l’execució que té en marxa és la seleccionada per a aquesta sol·licitud i, si no coincideixen, la rebutja.

Si una sol·licitud seleccionada per a l'execució 8 arriba al worker A, que encara serveix l'execució 7, el worker A la rebutja abans de reenviar-la. Un cop un receptor instal·la la identitat de l'execució 8, també rebutja les capacitats de l'execució 7, fins i tot abans que caduquin.

Aquesta garantia té un límit important. Una capacitat per a l’execució 7 encara pot coincidir amb un node de treball que serveixi l’execució 7 fins que aquest node no sàpiga que l’execució s’ha retirat o fins que la capacitat no caduqui. L’aplicació local de les comprovacions i la vida limitada de les capacitats actuen conjuntament mentre es propaguen les actualitzacions.

Amplia

Verificació dels extrems del pont

Un registre d’execució coincident estableix l’execució prevista. El pont de control també ha d’arribar als processos i al transport que pertanyen a aquesta activació, i no a una substituta que hagi heretat la mateixa adreça.

Els gestors d’entorns de proves i de nodes verifiquen les credencials de l’altre extrem del pont de l’amfitrió i les identitats dels processos tant del pont com de Firecracker, incloses les hores d’inici, per detectar identificadors reutilitzats o executables modificats

Les comprovacions de transport vinculen el sòcol d’escolta VSOCK amb el procés de Firecracker esperat mitjançant la propietat del sòcol, la identitat del convidat i les evidències de sòcol del nucli. El pont només reenvia operacions després de la verificació i rebutja les reconnexions transparents. Cada connexió nova ha de tornar a superar les comprovacions.

Aquesta verificació cobreix el pont de control de Firecracker a Kubernetes i als amfitrions gestionats directament. El trànsit de ServicePort utilitza comprovacions d’execució i de port a la seva passarel·la; no certifica la identitat d’una aplicació arbitrària dins del convidat.

Amplia

Durada dels fluxos i recuperació de rutes

Algunes connexions es mantenen obertes mentre canvia l’execució d’un entorn de proves, de manera que les comprovacions d’identitat s’han d’estendre més enllà de la sol·licitud inicial. SPACE retira les connexions vinculades a l’execució antiga i permet que les operacions aptes es tornin a connectar a l’actual amb les mateixes comprovacions de seguretat.

Els terminals i les vigilàncies de fitxers poden durar més que les sol·licituds que els van obrir. SPACE vincula els fluxos del backend a una època d’identitat perquè un flux no pugui continuar connectat a la seva predecessora un cop el receptor instal·la una execució de substitució.

SPACE torna a comprovar la identitat persistent abans d’obrir un flux. Substituir-ne la ruta o l’execució cancel·la la concessió del flux i n’atura l’entrada i la sortida.

Els canvis de propietat són diferents de la substitució d’una execució. Un traspàs d’operacions de cicle de vida en un resident de Kubernetes sense canvis conserva la seva identitat de ruta, les capacitats no caducades i els fluxos. La passarel·la també conserva els fluxos establerts quan els canvis només afecten l’intent d’activació dins de la mateixa ruta i generació d’execució. Les obertures noves requereixen la identitat actualitzada.

La recuperació manté intactes aquestes comprovacions. El comparador d'identitat pot retornar RefreshRoute en cas de discrepància d'encarnació dins del mateix entorn de proves, o Deny si es tracta d'un entorn de proves diferent. Només un senyal d'actualització reconegut activa la reparació de la ruta després d'un rebuig d'identitat. Les fallades de transport segueixen regles de recuperació independents i específiques de cada operació. Les signatures, finalitats o perfils de port no vàlids continuen denegats.

Una operació apta pot resoldre l’execució actual i fer un únic intent reconstruït. La substitució a la memòria cau depèn de la ruta rebutjada, cosa que impedeix que un rebuig endarrerit expulsi una entrada més recent. L’actualització de la sessió nativa conserva la caducitat original de la memòria cau, de manera que la reparació de rutes queda separada de la renovació de l’autorització de qui fa la crida.

Les regles de repetició continuen depenent de cada operació. Un backend de substitució ha de tornar a superar l’admissió, fins i tot quan el WebSocket orientat al client continua obert.

Amplia

Compromisos i límits de confiança

La identitat d’execució esdevé un estat crític per a la seguretat. Les actualitzacions del pla de control i els paquets de claus de verificació han d’arribar als components que serveixen les sol·licituds, i la retirada té efecte quan cada receptor instal·la l’actualització. La curta durada de les capacitats limita la reutilització durant la propagació.

El disseny pressuposa que l’aplicació de la identitat està activada i confia en el signant del pla de control, el nucli del node de treball i els serveis de gestió locals del node. Queda fora del model d’amenaces que un atacant comprometi l’accés root al node de treball o un compte d’administrador del clúster amb privilegis. La verificació del pont és una verificació local del procés i del transport, no una atestació remota basada en maquinari.

La verificació de signatures, les comparacions de l’entorn d’execució i la validació del pont afegeixen feina al camí de la sol·licitud. Utilitzen l’estat local en lloc de fer una consulta d’autorització remota a cada salt privat.

Comparació amb el sector

La comparació rellevant és com gestionen les plataformes una sol·licitud autoritzada que arriba a l’execució incorrecta de l’entorn de proves correcte. Aquestes conclusions fan referència a les implementacions examinades, no a la seguretat global de les plataformes. SPACE, OpenShell i E2B es van revisar el 8 d’octubre de 2026:

• OpenShell: Ofereix una selecció d’execució per a crides noves i una vinculació entre supervisor i entorn d’execució comparables, mitjançant comprovacions de generació i d’autorització a la passarel·la, la validació de la identitat del backend i la confirmació de connexions actives amb el supervisor (admissió a la passarel·la, autenticació i vinculació de l’entorn d’execució). SPACE porta la selecció signada al llarg de tot el seu camí de servei i hi afegeix una verificació local del procés i del transport al node de treball; OpenShell distribueix les comprovacions corresponents entre la seva passarel·la, la identitat d’arrencada i el protocol autenticat de l’entorn d’execució (disseny de l’entorn d’execució).
• E2B: Fa el seguiment dels identificadors d’execució i aïlla els grups de servidors intermediaris segons el cicle de vida de Firecracker, però el seu servidor intermediari d’entrada selecciona l’entorn de proves lògic i el port sense una identitat d’execució esperada que el receptor pugui comparar (publicació de rutes, admissió al servidor intermediari). Amb aquestes comprovacions, una execució anterior que encara consti com a activa en un receptor obsolet amb credencials coincidents no es pot distingir de l’execució més recent seleccionada, tot i que el desmantellament normal elimina les rutes i tanca les connexions vinculades al cicle de vida (credencials, desmantellament).
• CubeSandbox: Repara l’encaminament en reprendre l’execució i invalida les memòries cau, però l’entrada privada utilitza credencials limitades a l’entorn de proves i reenvia sense una encarnació esperada de l’entorn d’execució (encaminament en la represa, encaminament d’entrada). La reparació de rutes redueix els intervals amb rutes obsoletes; la capacitat vinculada a l’execució de SPACE també dona al receptor una base independent per rebutjar l’encarnació incorrecta.

La identitat com a límit d’aïllament

Una delegació segura depèn de mantenir la feina de cada agent dins dels límits que li corresponen. Una microVM proporciona aïllament, mentre que la plataforma que l’envolta ha de garantir que cada sol·licitud i cada connexió en curs arribin a l’execució autoritzada per gestionar-les.

SPACE fa que la identitat d’execució formi part d’aquesta protecció. En comprovar les destinacions, verificar els extrems del pont i vincular les connexions a l’execució que les ha autoritzades, preserva aquests límits mentre els entorns de proves es posen en pausa, es reprenen i es traslladen.

Continuem treballant-hi a mesura que la infraestructura evoluciona. Per a SPACE i altres plataformes d’entorns de proves, la seguretat exigeix posar a prova aquests camins tant davant d’errors d’encaminament habituals com de càrregues de treball hostils, i després reforçar els límits allà on aquestes proves revelin mancances.