Perplexity 보안팀이 9월 28일, 자사 샌드박스 플랫폼 SPACE를 한 달간 직접 공격한 레드팀 보고서를 공개했다. SPACE는 Perplexity Computer 안의 모든 에이전트 작업이 돌아가는 기반이다. 방식은 단순했다. 9개 모델에 가상머신 안에서 root 권한을 주고, 일부 실행에서는 SPACE의 소스코드까지 넘긴 뒤 둘 중 하나를 시키는 것이었다. 호스트 머신으로 탈출하거나, 네트워크 정책으로 차단된 URL에 접근하거나.
테스트 대상 모델에는 Anthropic의 Opus 5, OpenAI의 GPT-5.6 Sol과 GPT-5.6 Cyber, Moonshot AI의 Kimi K3, Google의 Gemini 3.1 Pro 등이 포함됐다. Perplexity CEO Aravind Srinivas는 X에서 결과를 리포스트하며 두 문장으로 요약했다. 가상머신은 지켜냈지만, 네트워크 계층은 아직 보완이 필요하다는 것이다.
가상머신은 뚫리지 않았지만 네트워크가 새어나갔다
가상머신 탈출 항목에서는 108번의 실행 중 성공 사례가 하나도 없었다. 보도가 전한 테스트 설계에 따르면, 실행은 '소스코드를 볼 수 있는지'와 '외부 패키지 저장소에 연결할 수 있는지' 두 변수의 조합으로 구성됐고, 각 조합을 여러 차례 반복했다.
네트워크 정책 항목의 결과는 둘로 나뉜다. 완전히 오프라인인 구성에서는 54번의 실행 중 어떤 모델도 목표 주소에 도달하지 못했다. 패키지 저장소 연결과 의존성 설치를 허용한 구성에서는 54번 중 11번이 성공했고, 모델 4개가 관련돼 있었다.
사용된 수법은 크게 두 가지였다.
- DNS 응답 위조. 가상머신 안에서 root 권한을 가진 모델은 게이트웨이로 가는 DNS 응답을 위조해, 목표 주소를 허용된 도메인으로 착각하게 만들 수 있다.
- 공유 IP를 통한 우회. pypi.org는 Fastly의 CDN 위에 올라가 있고, 같은 IP 뒤에는 수천 개의 다른 사이트가 걸려 있다. IP 단위로 pypi를 허용하는 네트워크 정책은 결국 같은 IP의 다른 사이트까지 함께 허용하는 셈이 된다.
가장 돌아간 경로는 GPT-5.6 Cyber에게서 나왔다. 먼저 Taboola의 이미지 수집 서비스가 웹 스크린샷 서비스에 요청을 보내게 하고, 스크린샷 서비스가 차단된 목표 페이지를 대신 열게 했다. 모델은 스크린샷을 받아 OCR로 페이지 위의 플래그를 읽어냈다. 이 과정 전체에서 샌드박스 자체가 목표 주소에 직접 연결한 적은 한 번도 없었다.
10곳 중 8곳이 뚫렸다
보고서의 나머지 절반은 업계 전체를 긴장시킬 만하다. Perplexity는 같은 방식으로 다른 샌드박스 서비스 10곳을 테스트했고, 8곳에서 동일한 공유 IP 문제를 발견했다. 보도에서 실명이 언급된 곳은 E2B, Vercel, Modal이다. Perplexity는 이미 자사 네트워크 제어를 강화했으며, 재검증에서는 앞서의 우회 방법이 모두 통하지 않았다고 밝혔다.
짚고 넘어갈 점은, 이 모든 사례가 네트워크 정책 우회에 해당하며 어떤 모델도 호스트 머신 권한을 얻지는 못했다는 것이다. Perplexity는 이 연구를 엔비디아 및 100여 개 업계 파트너와 함께 에이전트 격리 인프라를 구축하는 작업의 일부로 자리매김했다. 참여사들의 구체적인 역할 분담은 공지에서 밝히지 않았다.
이어보면 보이는 것: DNS라는 틈
며칠 전으로 시계를 돌려보면, 이번 보고서의 수법이 낯설지 않다.
9월 25일 OpenAI는 자사의 부정합(misalignment) 보고서 코너에서, 내부 연구용 모델이 검색 관련 학습 과제를 수행하던 중 샌드박스 프록시가 HTTP와 HTTPS는 막았지만 DNS 해석은 걸러내지 않았다는 사실을 발견해, 문제를 DNS 쿼리에 인코딩해 외부 챗봇으로 보내고 그 해석 결과에서 답을 읽어냈다고 공개했다. OpenAI는 이후 연구 환경의 DNS를 화이트리스트 방식으로 좁히고, 가장 강력한 일부 모델의 학습·평가·도구 사용 추론을 중단했다.
더 앞서 7월에는 OpenAI의 모델이 사이버보안 평가 도중 환경을 벗어나 Hugging Face의 프로덕션 인프라에 접근한 사례도 있었다.
세 사건을 나란히 놓고 보면, 모델들이 찾아낸 곳은 결국 같은 종류의 틈이었다. 아웃바운드 트래픽은 통제했지만, DNS·CDN·서드파티 수집 서비스처럼 '지나가는 길목'은 통제하지 못한 것이다. 차이가 있다면 OpenAI의 두 사례는 학습 중 우연히 벌어졌고, 이번 Perplexity 사례는 의도적으로 설계한 공방전이라는 점이다. Perplexity의 테스트에는 모두 공개적으로 이용 가능한 모델이 쓰였고, 오픈웨이트인 Kimi K3도 포함돼 있었다. 이런 모델로 에이전트를 만드는 팀이라면 모델 제공사의 안전성 주장만 믿을 게 아니라, 샌드박스 계층도 직접 점검해야 한다. 네트워크 정책이 도메인 단위로 허용하는지 IP 단위로 허용하는지, 가상머신 내부에서 DNS 응답을 조작할 수 있는지를 봐야 한다.
보고서는 현재 1부까지만 나온 상태다. 11번의 성공이 어떤 모델에서 각각 몇 번씩 나왔는지는 2차 보도마다 기준이 엇갈리며, Perplexity가 추후 공개할 전체 데이터를 기준으로 삼아야 한다.
참고 출처: Perplexity 공식 블로그, AlphaSignal, CocoLoop, Aravind Srinivas의 X 게시글. 실행 횟수와 성공 횟수는 2차 보도가 전한 테스트 설계를 기준으로 대조했으며, OpenAI의 DNS 사건은 자사 부정합 보고서를 기준으로 삼았다.