Perplexity는 2026년 10월 15일 공식 Hub 블로그를 통해, 개인 에이전트 제품 Computer를 뒷받침하는 샌드박스 플랫폼 SPACE를 오픈소스로 공개한다고 발표했습니다. Computer는 올해 2월 출시 당시 상용 샌드박스 서비스를 썼지만, 7월에 자체 개발한 SPACE로 교체됐고, 이후 모든 세션을 담당하며 하루 수백만 번의 샌드박스를 만들고 있습니다. Perplexity가 밝힌 이유는 직설적입니다. 에이전트 거버넌스는 공학의 문제라서, 모델이 스스로 규칙을 지키는 데만 기대서는 부족하고, 실행 환경 자체를 다른 이들이 검사하고, 고치고, 단단하게 만들 수 있어야 한다는 것입니다. 이번에 나온 것은 논문이 아니라 실제 운영에서 돌던 런타임 코드이며, 저장소와 배포 문서도 같은 날 공개됐습니다.
격리 방식: 에이전트마다 자기 가상머신 하나씩
SPACE의 기본 단위는 독립 운영체제를 가진 작은 가상머신입니다. 에이전트가 만든 코드와 파일은 그 안에서만 움직이고, 중앙 제어면이 샌드박스의 생성, 일시정지, 재개, 삭제를 관리합니다. 눈에 띄는 설계는 두 가지입니다. 첫째, 샌드박스는 신뢰할 수 없는 것으로 취급됩니다. 네트워크 접근과 플랫폼이 보관하는 자격 정보는 샌드박스 바깥에서 관리되어, 에이전트는 허용된 서비스에 접속할 수 있어도 자격 정보 자체가 작업 환경 안에 놓이지 않습니다. 열쇠는 늘 문 밖에 있는 셈입니다. 둘째, 진행 상황은 잦은 파일 스냅샷과 환경 전체 체크포인트로 저장하되 바뀐 부분만 기록하므로, 환경을 통째로 반복 복사하지 않습니다. 그래서 멈춘 세션은 파일과 실행 상태를 그대로 이어받을 수 있고, 한 세션을 둘로 갈라 서로 다른 방법을 시도할 수도 있습니다. 본 사이트는 앞서 Perplexity가 Project를 되돌릴 수 있는 작업 공간으로 만든 소식을 다뤘는데, SPACE가 다루는 것은 그보다 한 층 아래의 문제, 즉 코드가 실제로 어디서 돌고, 탈선했을 때 누가 막아 서는가입니다.
탈출 시도 108번 전부 실패, 이 결과를 어떻게 읽을까
Perplexity가 공개한 보안 평가에서는 에이전트가 의도적으로 경계를 뚫으려 했습니다. 108번의 시도 중 가상머신에서 호스트로 빠져나간 경우는 한 번도 없었지만, 네트워크 제한을 우회한 경우는 있었습니다. Perplexity는 그 약점을 고쳤고, 재시험에서 발견된 두 공격 방법 모두 성공하지 못했다고 밝혔습니다. 또한 같은 운영 트래픽 기준으로 SPACE의 샌드박스 생성이 이전 상용 공급자보다 3~5배 빠르며, 다른 샌드박스 플랫폼에서 찾은 관련 약점은 해당 업체에 알렸다고 합니다. 이 숫자는 조심해서 읽어야 합니다. 시험의 설계와 실행을 Perplexity 스스로 했고 표본도 제한적이기 때문입니다. 진지한 적대적 검증을 거쳤다는 것은 보여주지만 외부 감사를 대신하지는 못합니다. 오픈소스 공개의 진짜 가치는 코드가 열린 뒤 남들이 자기 공격 방법으로 같은 검증을 다시 돌릴 수 있다는 데 있습니다.
어떤 팀이 SPACE를 내려받아 돌려볼 만한가
에이전트에 코드 실행 능력을 붙이는 팀이 첫 번째로 볼 대상입니다. 격리, 스냅샷, 자격 정보 관리를 처음부터 만들기 전에 SPACE의 구현과 자기들의 빈틈을 견줘 볼 가치가 있고, 특히 자격 정보를 샌드박스 안에 넣지 않는다는 점과 상태를 복구할 수 있다는 점이 참고가 됩니다. 클라우드 업체들의 움직임도 이것이 단순한 전시가 아님을 보여줍니다. CoreWeave와 Akamai는 각자 플랫폼에서 SPACE를 검증하고 출시했고, Crusoe도 관리형 AI 서비스에 SPACE를 넣고 있습니다. 반대로 에이전트에게 코드를 실행시키지 않거나 업체의 전면 위탁 환경만 쓰는 팀은 지금 따라갈 필요가 없습니다. 에이전트 경쟁은 이제 모델이 얼마나 똑똑한가만이 아니라, 통제력을 잃었을 때의 대가를 누가 먼저 상자 안에 가둬 두는가의 싸움이 됐고, SPACE가 공개한 것은 바로 그 상자의 설계도입니다.
