SPACE가 요청을 올바른 샌드박스 실행으로 라우팅하는 방법

누군가 AI 에이전트에게 스프레드시트 분석이나 소프트웨어 테스트를 맡긴다면, 에이전트가 자신의 파일과 데이터를 안전하게 다룰 것이라고 믿는 것입니다. 에이전트에게는 다른 사용자의 데이터를 노출하거나 그들의 워크로드를 방해하지 않고 작업을 수행할 수 있는 격리된 환경이 필요합니다.

에이전트가 더 큰 자율성을 갖고 더 복잡한 작업을 맡게 되면서, 이러한 환경은 실수를 억제하고 안전하지 않거나 악의적인 코드로 인한 피해를 제한하는 데 도움을 줍니다. 샌드박스는 컨트롤 플레인 서비스, 워커 노드, 라우팅 인프라를 공유하면서도 이러한 격리를 제공합니다.

이 공유 인프라는 각 작업을 처리 권한이 있는 실행으로 정확히 전달해야 합니다. 오래된 라우트는 유효한 요청을 다른 샌드박스로, 또는 올바른 샌드박스의 이전 실행으로 보낼 수 있습니다. Perplexity의 보안 샌드박스 플랫폼인 SPACE는 각 작업을 선택된 실행에 바인딩하고, 요청을 전달하기 전에 목적지를 확인합니다.

SPACE는 수개월 동안 하루 수백만 건의 실행을 처리해 왔습니다. 각 실행은 고유한 암호화 ID로 보호되며, 오류율은 0.0002% 미만이고 끊긴 연결은 한 건도 없었습니다.

라우팅 문제

샌드박스 보안은 각 요청을 올바른 목적지로 전달하는 데에도 달려 있습니다. 단순한 파일 읽기조차 공유 인프라를 거치며, 이 인프라는 샌드박스가 일시 중지되거나 재개되거나 다른 머신으로 이동할 때 샌드박스가 어디에서 실행 중인지 계속 추적해야 합니다.

파일 읽기 요청은 여러 구성 요소를 거칩니다. SPACE의 컨트롤 플레인은 샌드박스를 실행과 워커로 확인합니다. 요청은 node-api를 통해 들어와 샌드박스 매니저인 sbx-manager로 전달되고, Unix 소켓을 거쳐 호스트 브리지인 spaced-host로 넘어갑니다. 브리지는 호스트-게스트 간 소켓 전송 방식인 VSOCK을 통해 Firecracker microVM 내부의 spaced-guest로 요청을 전달합니다.

각 결정은 인프라 변경보다 뒤처질 수 있는 상태에 의존합니다. 데이터베이스에 이전 배치 정보가 남아 있을 수 있고, 캐시된 주소가 다른 곳을 가리킬 수 있으며, 소켓 경로에 다른 리스너가 연결될 수도 있습니다. 연결에 성공하더라도 잘못된 목적지에 도달할 수 있습니다. 읽기 작업은 다른 사용자의 데이터를 노출할 수 있고, 쓰기 작업은 엉뚱한 파일 시스템을 수정할 수 있습니다.

스냅샷은 또 다른 문제를 더합니다. 다른 워커에서 샌드박스를 재개하면 논리적 ID는 유지되지만 새로운 실행이 시작됩니다. 지연된 요청이나 살아남은 연결이 이전 실행에 도달해 올바른 샌드박스 이름으로 오래된 상태를 반환할 수 있습니다.

확대

샌드박스 ID와 실행 ID

SPACE는 사용자 환경과 이를 서빙하는 런타임을 다음과 같이 분리합니다.

• 샌드박스 ID: 논리적 환경의 고정 ID입니다. 호출자 권한 확인을 통해 이 샌드박스에 대한 접근 권한이 확정됩니다.
• 라우트/실행 ID: 선택된 런타임 인카네이션과 그 배치 정보로, 워커, 기반 환경(substrate), 활성화를 포함합니다.

실행 세대는 런타임 인스턴스를 구별합니다. Kubernetes에서는 라우트에 pod UID도 포함됩니다. 주소는 엔드포인트의 위치를 찾고, 실행 ID는 해당 엔드포인트가 작업을 서빙할 수 있는지를 결정합니다.

샌드박스 S가 워커 A에서 실행 7로 실행되다가 워커 B에서 실행 8로 재개된다고 가정해 보겠습니다. 실행 8에 대해 선택된 요청이 실행 7에 도달하면 실패해야 합니다. 샌드박스 ID만 확인해서는 이 불일치를 잡아낼 수 없습니다.

확대

서명된 실행 선택

각 요청에는 어떤 샌드박스 실행이 이를 처리할 수 있는지, 어떤 접근이 허용되는지에 대한 서명된 증명이 포함됩니다. 수신 구성 요소는 요청 진행을 허용하기 전에 이 증명을 자신의 런타임 ID와 대조합니다.

호출자 권한을 확인한 후, SPACE는 샌드박스, 실행, 배치, 허용된 접근을 식별하는 수명이 짧은 서명된 케이퍼빌리티를 발급합니다. 퍼블릭 서비스 포트 케이퍼빌리티에는 허용된 포트와 프로토콜도 명시됩니다.

수신 측 샌드박스 매니저는 서명을 검증하고 전체 ID를 로컬에 저장된 런타임 레코드와 비교합니다. 서명은 누가 해당 선택을 승인했는지를 입증하고, 비교는 그 선택이 수신 측과 일치하는지를 확인합니다.

ServicePort 트래픽은 게스트 연결이 열리기 전에 샌드박스별 네트워크 게이트웨이인 netgtw에서 두 번째 검사를 받습니다. 게이트웨이는 ID를 신뢰할 수 있는 활성화 상태와 비교하고 포트와 프로토콜을 확인합니다. 제어 작업은 브리지 엔드포인트 검증 단계로 진행됩니다.

SPACE는 Ed25519 서명을 사용합니다. 케이퍼빌리티는 컨트롤 플레인 서명 키로 발급되며, 워커와 게이트웨이에 있는 공개 검증 키로는 발급할 수 없습니다.

케이퍼빌리티는 120초 동안 유효하며, 만료 시점에 대해 최대 15초의 시계 오차가 허용됩니다. 서명이 유효하고 토큰이 만료되지 않았더라도 선택된 ID와 설치된 ID가 일치하지 않으면 요청은 통과하지 못합니다.

확대

잘못된 목적지에서의 거부

수신 측 워커는 요청 자체가 승인된 경우에도 라우팅 오류를 잡아낼 수 있습니다. 워커는 해당 요청에 대해 선택된 실행을 자신이 실행 중인지 확인하고, 일치하지 않으면 요청을 거부합니다.

실행 8용으로 선택된 요청이 아직 실행 7을 처리하고 있는 워커 A에 도달하면, 워커 A는 요청을 전달하기 전에 거부합니다. 수신자가 실행 8의 ID를 설치하고 나면, 실행 7에 대한 capability도 만료 전이라도 거부합니다.

이 보장에는 중요한 한계가 있습니다. 실행 7에 대한 케이퍼빌리티는 해당 워커가 폐기 사실을 인지하거나 케이퍼빌리티가 만료되기 전까지는 여전히 실행 7을 서빙하는 워커와 일치할 수 있습니다. 업데이트가 전파되는 동안에는 로컬 적용과 제한된 케이퍼빌리티 수명이 함께 작동합니다.

확대

브리지 엔드포인트 검증

런타임 레코드가 일치하면 의도된 실행이 확인됩니다. 컨트롤 브리지 역시 동일한 주소를 물려받은 대체 대상이 아니라 해당 활성화에 속한 프로세스와 전송 계층에 도달해야 합니다.

샌드박스 매니저와 노드 매니저는 호스트 브리지의 피어 자격 증명과 함께 시작 시간을 포함한 브리지 및 Firecracker 프로세스 ID를 모두 검증하여, 재사용된 ID나 변경된 실행 파일을 탐지합니다

전송 계층 검사는 소켓 소유권, 게스트 ID, 커널 소켓 증거를 사용해 VSOCK 리스너를 예상된 Firecracker 프로세스에 연결합니다. 브리지는 검증이 끝난 후에만 작업을 전달하며 투명한 재연결을 거부합니다. 모든 새 연결은 검사를 다시 통과해야 합니다.

이 검증은 Kubernetes와 직접 관리되는 호스트의 Firecracker 컨트롤 브리지에 적용됩니다. ServicePort 트래픽은 게이트웨이에서 실행 및 포트 검사를 거치며, 게스트 내부의 임의 애플리케이션 ID까지 증명하지는 않습니다.

확대

스트림 수명과 라우트 복구

일부 연결은 샌드박스의 실행이 바뀌는 동안에도 열린 상태로 유지되므로, ID 검사는 최초 요청 이후까지 확장되어야 합니다. SPACE는 이전 실행에 연결된 연결을 폐기하고, 대상이 되는 작업이 동일한 보안 검사를 거쳐 현재 실행에 다시 연결되도록 합니다.

터미널과 파일 감시는 이를 연 요청보다 오래 유지될 수 있습니다. SPACE는 백엔드 스트림을 ID 에포크에 연결하므로, 수신 측이 대체 실행을 설치한 후에는 스트림이 이전 실행에 연결된 채로 남아 있을 수 없습니다.

SPACE는 스트림을 열기 전에 영속 ID를 다시 확인합니다. 라우트나 실행이 교체되면 스트림의 리스가 취소되어 입력과 출력이 중단됩니다.

소유권 변경은 실행 교체와 구별됩니다. 변경되지 않은 Kubernetes 상주 리소스에서 수명 주기 작업이 인계되면 라우트 ID, 만료되지 않은 케이퍼빌리티, 스트림이 유지됩니다. 게이트웨이는 동일한 라우트 및 실행 세대 내에서 활성화 시도만 변경된 경우에도 기존 스트림을 유지합니다. 스트림을 새로 열 때는 업데이트된 ID가 필요합니다.

복구 과정에서도 이러한 검사는 그대로 유지됩니다. ID 비교기는 같은 샌드박스 내에서 인카네이션이 일치하지 않으면 RefreshRoute를, 다른 샌드박스이면 Deny를 반환할 수 있습니다. ID가 거부된 후에는 인식된 새로 고침 신호만 라우트 복구를 트리거합니다. 전송 실패는 작업별로 정해진 별도의 복구 규칙을 따릅니다. 유효하지 않은 서명, 용도 또는 포트 프로필은 계속 거부됩니다.

대상이 되는 작업은 현재 실행을 확인한 후 재구성된 요청으로 한 번 재시도할 수 있습니다. 캐시 교체는 거부된 라우트를 조건으로 이루어지므로, 지연된 거부 응답이 더 최신 항목을 밀어내지 않습니다. 네이티브 세션 갱신은 원래 캐시 만료 시간을 유지하여, 라우트 복구와 호출자 권한 갱신을 분리합니다.

재전송 규칙은 작업별로 달리 적용됩니다. 클라이언트 쪽 WebSocket이 열린 상태로 유지되더라도 대체 백엔드는 진입 승인을 다시 통과해야 합니다.

확대

트레이드오프와 신뢰 경계

실행 ID는 보안상 매우 중요한 상태가 됩니다. 컨트롤 플레인 업데이트와 검증 키 번들은 서빙 구성 요소에 전달되어야 하며, 폐기는 각 수신 측이 업데이트를 설치하는 시점에 적용됩니다. 짧은 케이퍼빌리티 수명은 전파 중 재사용 가능 기간을 제한합니다.

이 설계는 ID 적용이 활성화되어 있다고 가정하며, 컨트롤 플레인 서명자, 워커 커널, 노드 로컬 관리 서비스를 신뢰합니다. 워커 루트 권한 또는 권한 있는 클러스터 관리자 권한이 탈취되는 경우는 위협 모델의 범위를 벗어납니다. 브리지 검증은 로컬 프로세스 및 전송 계층 검증이며, 하드웨어 기반 원격 증명이 아닙니다.

서명 검증, 런타임 비교, 브리지 검증은 요청 경로에 작업을 추가합니다. 이 과정에서는 모든 프라이빗 홉마다 원격 권한 조회를 하는 대신 로컬 상태를 사용합니다.

업계 비교

여기서 중요한 비교 기준은 승인된 요청이 올바른 샌드박스의 잘못된 실행에 도달했을 때 각 플랫폼이 이를 어떻게 처리하는지입니다. 이 결과는 검토한 구현에 관한 것이며 플랫폼 전반의 보안에 관한 것이 아닙니다. SPACE, OpenShell, E2B는 2026년 10월 8일에 확인했으며, 결과는 다음과 같습니다.

• OpenShell: 게이트웨이 세대 및 권한 확인, 백엔드 ID 검증, 활성 슈퍼바이저 연결 확인을 통해 새 호출에 대한 실행 선택과 슈퍼바이저-런타임 바인딩을 SPACE와 비슷한 수준으로 제공합니다(게이트웨이 진입 승인, 런타임 인증 및 바인딩). SPACE는 서명된 선택 정보를 서빙 경로 전체에 걸쳐 전달하고 워커 로컬 프로세스 및 전송 계층 검증을 추가하는 반면, OpenShell은 이에 상응하는 검사를 게이트웨이, 실행 시작 ID, 인증된 런타임 프로토콜에 분산합니다(런타임 설계).
• E2B: 실행 ID를 추적하고 Firecracker 수명 주기별로 프록시 풀을 격리하지만, 인바운드 프록시는 수신 측이 비교할 예상 실행 ID 없이 논리적 샌드박스와 포트만 선택합니다(라우트 게시, 프록시 진입 승인). 일치하는 자격 증명을 가진 오래된 수신 측에 여전히 활성 상태로 등록된 이전 실행은 이러한 검사만으로는 선택된 최신 실행과 구별할 수 없습니다. 다만 정상적인 종료 과정에서는 라우트가 제거되고 수명 주기에 묶인 연결이 닫힙니다(자격 증명, 종료).
• CubeSandbox: 재개 시 라우팅을 복구하고 캐시를 무효화하지만, 프라이빗 인그레스는 샌드박스 범위의 자격 증명을 사용하며 예상 런타임 인스턴스를 확인하지 않은 채 요청을 전달합니다(재개 라우팅, 인그레스 라우팅). 라우트 복구는 오래된 라우트가 남는 시간을 줄여 주며, SPACE의 실행 바인딩 케이퍼빌리티는 수신 측이 잘못된 인스턴스를 거부할 수 있는 독립적인 근거도 제공합니다.

격리 경계로서의 ID

안전한 위임은 각 에이전트의 작업을 의도된 경계 안에 유지하는 데 달려 있습니다. microVM이 격리를 제공한다면, 이를 둘러싼 플랫폼은 모든 요청과 진행 중인 연결이 처리 권한이 있는 실행에 도달하도록 보장해야 합니다.

SPACE는 실행 ID를 이러한 보호의 일부로 삼습니다. 목적지를 확인하고, 브리지 엔드포인트를 검증하고, 연결을 이를 승인한 실행에 연결함으로써 샌드박스가 일시 중지되거나 재개되거나 이동할 때도 이러한 경계를 유지합니다.

인프라가 발전함에 따라 이 작업도 계속 이어 가고 있습니다. SPACE를 비롯한 샌드박스 플랫폼의 보안을 위해서는 이러한 경로를 일상적인 라우팅 오류와 악의적인 워크로드 모두에 대해 테스트하고, 테스트에서 드러난 허점이 있는 곳마다 경계를 강화해야 합니다.