본문으로 건너뛰기

AI Agent를 위한 Sandbox, 뭘 써야 할까?

· 약 8분
nilbox
nilbox
The secure desktop runtime for AI agents

"있으면 좋은 것" 흉내 내기는 이제 멈출 때입니다.

2026년에 AI 에이전트를 실행하고 있다면 — OpenClaw, Claude Code 스타일의 도구, 직접 만든 LangChain 루프, 코드를 작성하고 바로 실행하는 무엇이든 — 그 에이전트는 신뢰할 수 없는 코드를 당신의 PC에서 실행 중입니다. "실행할 수도 있다"가 아닙니다. 실행하고 있습니다. 모든 pip install, 모든 쉘 명령, 모든 "이것만 빨리 해볼게요"는 언어 모델이 선택한 토큰 위에서 에이전트가 행동하는 순간입니다.

그래서 샌드박스 질문은 협상 대상이 아닙니다. 남은 질문은 어느 샌드박스냐 뿐입니다.

TL;DR​

  • AI 에이전트는 모델이 만들어낸 신뢰할 수 없는 코드를 실행합니다 — 샌드박스는 선택이 아니라 최소 조건입니다.
  • 현실적인 선택지는 네 가지입니다: Virtual Machine, Docker 컨테이너, 목적형 오픈소스 샌드박스(E2B, Daytona, Firecracker 기반), Zero Token Architecture 기반의 nilbox 같은 런타임.
  • VM, Docker, 대부분의 오픈소스 샌드박스는 프로세스 격리는 잘 해냅니다 — 하지만 API 토큰, 네트워크 이그레스, 프롬프트 인젝션을 통한 시크릿 유출을 막지는 못합니다.
  • nilbox는 이 셋을 기본 제공하는 유일한 옵션이며, 대신 데스크탑 AI 에이전트라는 범위로 제한됩니다.

왜 AI 에이전트 샌드박스가 필수인가​

위협 표면을 구체적으로 적어보겠습니다.

  • 에이전트가 당신이 작성하지 않은 코드를 실행합니다. LLM이 생성한 코드, 모델의 판단으로 실행되는 코드, npm/PyPI처럼 공급망 공격 이력이 실제로 존재하는 생태계에서 설치한 코드.
  • 프롬프트 인젝션은 해결되지 않았습니다. README, HTML 페이지, PDF, MCP 툴 응답 — 모델이 따르기로 결정할 수 있는 지시가 어디든 숨어 있을 수 있습니다.
  • 파일은 유출됩니다. 소스 코드, .env 파일, SSH 키, 브라우저 쿠키, 홈 디렉터리 아래 모든 것은 cat ~/.aws/credentials 한 줄과 egress 호출 한 번이면 외부로 나갑니다.
  • 내부 네트워크가 노출됩니다. 노트북에서 돌아가는 에이전트는 NAS, 공유기 관리 페이지, 업무 VPN으로 도달 가능한 서브넷과 같은 LAN에 앉아 있습니다.

호스트 OS 위에 AI 에이전트를 그냥 띄우는 건 2005년에 포럼에서 받은 낯선 .exe를 더블클릭하던 의사결정과 같은 등급입니다. 샌드박스는 과민반응이 아니라 최소 기준입니다.

그래서 — 어느 샌드박스냐?

한눈에 보는 비교​

커널 수준 격리API 토큰 유출 차단기본 egress 방화벽프롬프트 인젝션 토큰 방어원클릭 크로스 OS GUI
Virtual Machine (VirtualBox, VMware 등)✓✗✗ (수동 설정)✗✗
Docker 컨테이너일부 (커널 공유)✗✗ (수동 설정)✗✗
오픈소스 샌드박스 (E2B, Daytona, Firecracker 기반 등)구현별로 다름✗다름✗✗ (API 우선)
nilbox (Zero Token + Linux for nilbox)✓ (VM)✓✓✓✓

이제 자세히 보겠습니다. 각 후보마다 동일한 구조입니다: 어떻게 격리하는가, 어디가 진짜로 단단한가, AI 에이전트 관점에서 어디가 무너지는가, 누가 써야 하는가.

Virtual Machine​

어떻게 격리하는가. 하이퍼바이저가 게스트에게 별도의 커널, 파일시스템, 메모리를 제공합니다. 호스트 입장에서 에이전트는 완전히 다른 컴퓨터 안에 들어 있는 것처럼 보입니다.

어디가 단단한가. VM은 우리가 가진 가장 검증된 격리 원시입니다. 수십 년에 걸친 공격 표면 연구, 단단한 커널 경계, 스냅샷-리버트가 기본 제공, 게스트가 루트를 빼앗겨도 호스트는 대체로 무사합니다. 행동을 전혀 신뢰할 수 없는 임의 바이너리를 돌릴 때 VM은 여전히 가장 무거운 기준선입니다.

AI 에이전트 관점에서 어디가 무너지는가. VM은 프로세스를 격리할 뿐, 그 프로세스가 일하기 위해 필요한 자격증명을 격리하지는 않습니다. OpenAI나 Anthropic과 통신하려면 진짜 API 키를 VM 안으로 주입해야 합니다. 들어가는 순간:

  • 프롬프트 인젝션이 에이전트를 설득해 다음 응답에 $OPEN_API_TOKEN을 echo하게 만들 수 있습니다.
  • 악성 의존성이 process.env를 원격 서버로 POST할 수 있습니다.
  • VM의 egress는 기본적으로 열려 있습니다 — 방화벽도 allow-list도 없이, 게스트는 해석되는 모든 URL에 접근할 수 있습니다.

거기에 설치 경험도 좋지 않습니다. 설치 과정은 여러 단계이고, 사용자마다 설정이 미묘하게 다르며, 팀원이 매번 정확히 구성하리라 기대하기 어렵습니다.

누구를 위한 선택인가. 완전한 OS 격리가 필요하고 실제로 VM 인프라를 운영할 역량이 있는 장기 워크로드. 데스크탑 AI 에이전트의 일상 도구로는 과합니다.

Docker 컨테이너​

어떻게 격리하는가. Linux 커널 namespace와 cgroup을 이용해 프로세스, 네트워크, 파일시스템 뷰를 컨테이너에 분리해 주되, 호스트 커널은 공유합니다.

어디가 단단한가. 빠르고, 어디에나 있고, 재현 가능합니다. Dockerfile 하나면 팀원 누구의 장비에서도 같은 환경이 만들어집니다. 툴링은 비현실적으로 좋고, 이미 만들어진 이미지 생태계가 웬만한 런타임을 다 커버합니다.

AI 에이전트 관점에서 어디가 무너지는가. 세 가지 독립된 문제가 있습니다:

  1. 커널을 공유합니다. 컨테이너 탈출은 곧 호스트 침해입니다. 관련 CVE는 10년 넘게 꾸준히 나오고 있습니다. 신뢰할 수 없는 코드 — LLM 출력이 바로 그런 코드입니다 — 에 대해서는 VM보다 약한 경계입니다.
  2. 토큰이 환경 변수에 존재합니다. -e OPEN_API_TOKEN=sk-... 또는 Docker secret으로 진짜 키를 주입하는 순간, 에이전트 프로세스는 그걸 그대로 읽습니다. VM에 해당하는 모든 토큰 유출 경로가 여기에도 해당합니다.
  3. egress가 제어되지 않습니다. 기본 설정에서 컨테이너는 전체 인터넷에, 대부분의 셋업에서 LAN에도 도달합니다. 이걸 잠그려면 별도 Docker 네트워크, 프록시 사이드카, iptables 구성이 필요합니다 — 가능하지만 꾸준히 하는 팀은 거의 없습니다.

누구를 위한 선택인가. CI 파이프라인, 재현 가능한 개발 환경, 이미 Docker로 일하고 있고 빠른 반복이 중요한 팀. 에이전트 샌드박스의 한 구성 요소로는 합리적이지만, 완전한 답은 아닙니다.

그 외 오픈소스 샌드박스​

E2B, Daytona, Firecracker 기반 microVM 프로젝트, 그리고 "LLM이 만든 코드를 안전하게 실행" 목적의 다양한 오픈소스들.

어떻게 격리하는가. 구현마다 다릅니다. Docker를 감싸는 경우도 있고(더 약한 커널 경계, 같은 문제), Firecracker 같은 microVM을 쓰는 경우도 있고(VM급에 가까움), 순수 유저랜드 jail도 있습니다.

어디가 단단한가. 이 목록에서 유일하게 AI가 생성한 코드 실행을 목적으로 설계된 도구들입니다. 콜드 스타트는 밀리초 단위이고, API는 깔끔하며, 좋은 것들(microVM 기반)은 컨테이너급 사용성으로 VM급 격리를 제공합니다. 호스팅된 코드 인터프리터 제품을 만든다면 이 카테고리가 정답입니다.

AI 에이전트 관점에서 어디가 무너지는가. 대부분이 API 우선, 클라우드 호스팅입니다:

  • API 토큰은 여전히 진짜입니다. 샌드박스 런타임의 환경 변수로 넘기든 호스팅된 API의 헤더로 넘기든, 그 안의 에이전트는 결국 진짜 키를 봅니다. 프롬프트 인젝션과 악성 패키지는 여전히 이깁니다.
  • egress 방화벽은 구현마다 편차가 큽니다. 호스트 allow-list를 지원하는 프로젝트도 있지만, 대부분은 사용자가 올바르게 설정할 거라고 가정합니다. "알아서 조립하세요"는 보안 포지션이 아닙니다.
  • 데스크탑 통합이 없습니다. 이들은 인프라 원시입니다. GUI가 필요하면 직접 만들어야 합니다.
  • 클라우드 호스팅 변형은 코드를 외부로 보냅니다. 컴플라이언스 상황에 따라 괜찮을 수도, 아닐 수도 있지만 — 어쨌든 당신이 추가로 해야 할 대화가 하나 더 생깁니다.

누구를 위한 선택인가. 서버사이드 에이전트 플랫폼, 호스팅 코드 인터프리터, 샌드박스가 백엔드의 일부인 AI 제품을 출시하는 팀. 자기 장비에서 에이전트를 돌리는 개발자에겐 모양이 맞지 않습니다.

nilbox — Zero Token Architecture + Linux for nilbox​

어떻게 격리하는가. 두 겹입니다. 첫째, Linux for nilbox라는 Debian 기반 전용 VM이 에이전트를 실행합니다 — 하이퍼바이저급 격리를, Windows / macOS / Linux 어디서나 원클릭으로 설치합니다. 둘째, Zero Token Architecture를 구현한 경계 프록시: 에이전트는 진짜 API 키를 절대 보지 못합니다.

Zero Token을 짧게 요약하면(전체 논의는 이전 글 참고): 에이전트에게 OPEN_API_TOKEN=sk-proj-real-...를 주는 대신, OPEN_API_TOKEN=OPEN_API_TOKEN을 줍니다. 네, 값이 변수 이름 그 자체입니다. 경계 프록시가 나가는 호출을 가로채 플레이스홀더를 인식하고, 에이전트 외부에 암호화되어 있는 진짜 토큰으로 교체한 뒤 업스트림으로 보냅니다.

┌───────────┐   OPEN_API_TOKEN   ┌──────────┐   sk-proj-real   ┌──────┐
│  Agent    │  ───────────────▶  │ Boundary │  ──────────────▶ │ LLM  │
└───────────┘                    └──────────┘                  └──────┘

어디가 단단한가. 다른 옵션들이 남겨 둔 세 가지 구멍을 모두 덮습니다:

  • 토큰 유출 차단. 프롬프트 인젝션이 에이전트가 가진 모든 환경 변수를 빼낼 수 있습니다. 하지만 빠져나가는 값은 OPEN_API_TOKEN=OPEN_API_TOKEN — 쓸모없는 문자열입니다. 공격자는 이걸로 LLM을 호출할 수도, 계정에 과금할 수도, 심지어 어느 벤더의 토큰이었는지 증명할 수도 없습니다.
  • egress 방화벽 내장. 경계는 토큰 치환 경로를 거치지 않은 outbound를 거부합니다. 부수 효과로 "에이전트가 임의 URL을 호출하려는 시도"도 함께 차단됩니다.
  • 원클릭 크로스 플랫폼 GUI. WSL도, Docker CLI도, VM 설치 마법사도 없습니다. 데스크탑 앱을 설치하고, OpenClaw든 원하는 에이전트든 스토어에서 설치 버튼 한 번 누르면 끝입니다.

한계 / 트레이드오프. nilbox는 데스크탑 AI 에이전트 범위에 맞춰져 있습니다. 서버사이드 코드 인터프리터 제품이 아니고, Firecracker의 대체재가 아니며, 생태계는 Docker/VMware 대비 훨씬 젊습니다. 호스팅 서비스를 만든다면 이 도구는 맞지 않습니다. 자기 노트북에서 에이전트를 돌린다면 맞습니다.

누구를 위한 선택인가. 토큰 유출 차단 + 네트워크 egress 제어 + VM 격리까지 세 가지를 직접 조립하지 않고 받고 싶은 데스크탑 AI 에이전트 사용자.

결정 매트릭스​

이런 게 필요하다면...선택
임의 바이너리를 위한 완전한 OS 격리, 운영할 인프라 역량이 있음Virtual Machine
재현 가능한 개발 환경, 빠른 반복, 이미 Docker 숙련팀Docker
호스팅 AI 제품/코드 인터프리터 서비스의 백엔드 샌드박스E2B / Daytona / Firecracker 기반 오픈소스
토큰 + 네트워크 + 프롬프트 인젝션 방어가 기본 제공되는 데스크탑 AI 에이전트nilbox

"전부 다"라는 줄이 없습니다. 그게 정직한 답입니다. Docker는 사용성에서, VM은 성숙도에서, Firecracker 계열은 목적형 격리에서, nilbox는 데스크탑 AI 에이전트라는 케이스에서의 방어 심화에서 이깁니다.

결론​

이 목록의 모든 옵션이 어느 정도의 격리는 줍니다. 하지만 에이전트가 결국 API 키를 유출하고, 네트워크를 넘나들고, 당신의 시크릿을 프롬프트 응답에 되돌려 보낼 것이라는 가정에서 설계된 건 하나뿐입니다.

규칙은 이것입니다: 무엇을 선택하든, "프로세스를 격리하는가?"가 아니라 토큰 유출, egress 제어, 프롬프트 인젝션 유출 세 가지로 평가하세요. 여전히 에이전트에게 진짜 sk-proj-...를 쥐여주는 프로세스 레벨 샌드박스는 절반의 답입니다. 에이전트는 당신에게 청구서를 보내거나 데이터를 흘리기 위해 샌드박스를 탈출할 필요가 없습니다 — 가지고 있어선 안 되는 자격증명으로 네트워크에 말만 걸면 됩니다.

직접 만든다면 Docker든 VM이든 로컬 프록시 + 플레이스홀더 토큰 + egress allow-list를 얹으세요. 그러고 싶지 않다면 nilbox가 데스크탑 에이전트를 위한 풀 스택을 오픈소스로 제공합니다. 어느 쪽이든: 샌드박스 없이 에이전트를 돌리는 건 멈추고, 그 안의 에이전트가 아직 당신의 진짜 API 키를 들고 있다면 "샌드박스가 완성됐다"고 부르는 것도 멈추세요.

같은 맥락의 이전 글: AI 에이전트에게 진짜 API 키를 보여줄 필요가 없는 이유.