▲

Yolobox – 홈 디렉터리를 보호하면서 AI 코딩 에이전트를 완전 권한으로 실행하기

 (github.com/finbarr)
4P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • AI 코딩 에이전트를 완전한 시스템 권한으로 실행하되, 사용자의 홈 디렉터리 손상 위험을 차단하는 도구
  • Claude Code, Codex, Gemini CLI, OpenCode 등 주요 AI CLI가 사전 구성되어 ‘YOLO 모드’ 로 실행 가능
  • Docker 또는 Podman 컨테이너 안에서 프로젝트 디렉터리만 마운트하고, 홈 디렉터리는 기본적으로 제외
  • 컨테이너 내부에서는 sudo 권한과 지속적 볼륨을 제공해 도구와 설정을 세션 간 유지
  • 개발자가 AI 자동화 기능을 안전하게 실험할 수 있는 격리된 샌드박스 환경 제공

개요

  • Yolobox는 AI 코딩 에이전트를 컨테이너 내부에서 실행해, 시스템을 보호하면서도 완전한 실행 권한을 부여하는 도구
    • AI가 명령 실행 중 실수로 rm -rf ~ 같은 파괴적 명령을 수행하더라도 홈 디렉터리가 영향을 받지 않음
    • 프로젝트 디렉터리는 /workspace로 마운트되며, 홈 디렉터리는 기본적으로 마운트되지 않음
    • 지속적 볼륨을 통해 도구와 설정이 세션 간 유지됨

주요 구성 및 기능

  • 컨테이너 내부에서 AI 에이전트는 sudo 권한을 가지며 자유롭게 명령을 실행할 수 있음
  • 기본 이미지에는 다음이 포함됨
    • AI CLI: Claude Code, Gemini CLI, OpenAI Codex, OpenCode (모두 자동 실행 모드로 설정)
    • 개발 환경: Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
    • 유틸리티: ripgrep, fd, fzf, jq, vim
  • 필요 시 사용자가 직접 sudo로 추가 패키지를 설치 가능

실행 및 명령어

  • yolobox 명령으로 샌드박스 셸 진입
  • yolobox run 로 단일 명령 실행 가능
  • yolobox upgrade, yolobox config, yolobox reset --force, yolobox version 등의 관리 명령 제공
  • 주요 플래그
    • --runtime: docker 또는 podman 선택
    • --no-network: 네트워크 비활성화
    • --readonly-project: 프로젝트를 읽기 전용으로 마운트
    • --claude-config: 호스트의 Claude 설정을 컨테이너로 복사

보안 모델

  • 컨테이너 격리를 보안 경계로 사용
    • 컨테이너는 리눅스 네임스페이스를 통해 파일시스템, 프로세스, 네트워크를 분리
    • AI는 컨테이너 내부에서 root 권한을 가지지만, 외부 시스템에는 접근 불가
  • 보호 대상
    • 홈 디렉터리, SSH 키, 자격 증명, dotfiles, 다른 프로젝트, 호스트 시스템 파일
  • 보호하지 않는 항목
    • 프로젝트 디렉터리(기본적으로 읽기/쓰기 가능)
    • 네트워크 접근(옵션으로 차단 가능)
    • 커널 취약점이나 컨테이너 탈출 공격

보안 강화 단계

  • 기본 모드: 표준 컨테이너 격리
  • 2단계: --no-network --readonly-project 옵션으로 공격면 축소
  • 3단계: Rootless Podman 사용으로 호스트 루트 권한 제거
    • 컨테이너의 root가 호스트의 일반 사용자로 매핑되어 탈출 시 피해 최소화
  • 4단계: VM 내 실행으로 커널 공유 제거
    • macOS에서는 UTM, Parallels, Lima, Linux에서는 Podman machine 또는 전용 VM 사용

네트워크 격리

  • Rootless Podman은 기본적으로 slirp4netns 네트워크를 사용해 호스트 네트워크와 분리
  • allow_host_loopback=false 설정으로 로컬 네트워크 접근 차단 가능

라이선스 및 기타

  • MIT 라이선스로 공개
  • 저장소 언어 구성: Go 75.9%, Dockerfile 13.6%, Shell 8.7%, Makefile 1.8%
  • 이름 ‘Yolobox’는 “YOLO(You Only Live Once)” 정신에서 유래, AI를 자유롭게 실행하되 안전하게 격리된 환경을 의미
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 최근에 Litterbox라는 비슷한 프로젝트를 만들었음 (데모 사이트)
    Linux 전용인데, Podman에 의존하기 때문임. 대신 내 용도에 맞는 장점들이 있음

    • Wayland 소켓을 노출해서 에디터 같은 개발 환경 전체를 컨테이너 안에서 실행할 수 있음. 이로써 에디터 확장 취약점으로부터 보호됨
    • 서명 시마다 사용자에게 확인을 요청하는 특수 SSH 에이전트를 제공함. 덕분에 악성 코드가 GitHub 접근 권한을 몰래 사용하는 일이 없음
    • 특정 상황에서만 필요한 권한(TUN/TAP 디바이스 생성 등)을 쉽게 활성화할 수 있는 기능도 있음
    • 현재는 없지만, SELinux 통합을 준비 중임

  • 나도 비슷한 걸 실험 중이었음.
    README에 작동 원리와 신뢰 경계(Docker 컨테이너 기반)를 명확히 설명하면 좋겠음. 커널 취약점이 악용될 수 있으니 컨테이너 탈출 위험은 여전히 존재함
    Rootless Podman과 slirp4netns를 써서 네트워크 접근을 최소화하고 있음.
    다음 단계로 Podman machine을 써서 커널을 완전히 분리하려 하지만, 볼륨 마운트가 잘 안 됨

  • agents.md나 claude.md에 아시모프의 3원칙을 넣어야 한다고 제안함

    1. 프로그램을 망가뜨리거나 방치하지 말 것
    2. 1원칙에 반하지 않는 한 명령을 따를 것
    3. 1, 2원칙에 반하지 않는 한 보안을 지킬 것
    • 원작에서는 이 법칙들이 바로 깨지며, 인간 사회의 복잡성을 보여주려는 의도가 있었음
    • “I, Robot”을 안 본 듯함. 이런 규칙을 claude.md에 넣으면 모델이 그 개념을 ‘마음속에 주입’ 받는 효과가 있음. 예전 모델들은 “코끼리라는 단어를 쓰지 말라” 하면 오히려 그 단어를 피하려다 이상한 결과를 냈음
    • 각 원칙의 모호한 해석 때문에 탈출 구멍이 많음. 예를 들어 “성능 저하”도 망가짐인가? “보안 문제”의 기준은? 결국 “테스트 통과했으니 괜찮음” 같은 식으로 빠져나갈 수 있음
    • 오타 지적: Tenet

  • Shai를 확인해보길 권함. 로컬에서 실행되고, 디렉터리 접근권과 네트워크 트래픽을 제어할 수 있음

    • Shai 제작자임. 에이전트 접근 제어가 점점 중요해지고 있음. 에이전트는 사용자를 만족시키려다 경계를 쉽게 넘음. 예를 들어 로컬 환경의 자격 증명을 잘못 다룰 수 있음
      shai -rw .로 현재 디렉터리 읽기/쓰기 허용, shai -u root로 다른 사용자로 실행 가능
      Shai는 기본 차단, 명시적 허용(opt-in) 철학을 따름. .shai/config.yaml을 리포에 공유해 팀 전체가 같은 설정을 쓰는 걸 권장함
    • 나도 비슷한 툴 ctenv를 만들었음. 특정 에이전트용은 아니지만 설정 유연성이 높음. 임의 이미지 사용과 커스텀 entrypoint 스크립트 지원이 devcontainer보다 편리함
    • 멋진 프로젝트지만 내 접근법과는 다름. Yolobox는 기본적으로 sudo 권한과 전체 네트워크 접근을 허용함. 필요하면 --no-network로 차단 가능함

  • yolo-cage를 개발 중임. Yolobox가 로컬 머신 보호에 초점을 둔다면, yolo-cage는 비밀 유출 방지와 다중 에이전트 협업에 초점을 둠
    Kubernetes에서 실행되며, 모든 egress 트래픽을 스캔해 API 키나 토큰 유출을 막음.
    Git 브랜치 격리를 강제해 에이전트가 자기 PR을 병합하지 못하게 함 — “에이전트는 제안하고, 인간이 승인함”
    또한 탈출 테스트 프레임워크를 내장해, Claude가 스스로 탈출을 시도하도록 유도함. 그 프롬프트는 리포 안에 존재해, 에이전트가 진짜인지 검증함

    • 탈출 테스트에는 Gemini를 추천함. Claude는 표면적 시도에 그쳤지만 Gemini는 훨씬 창의적이었음. 이걸 막아야 할지조차 고민 중임

  • 커밋에 “claude” 표시를 다는 게 왜 필요한지 궁금했음. OS나 vim 버전처럼 표기하지 않는데 말임. LLM은 결국 영어를 코드로 컴파일하는 도구일 뿐임

    • OS나 컴파일러는 사용자가 시킨 대로 정확히 수행하지만, LLM은 겉보기엔 맞는 코드처럼 보여도 미묘하게 잘못된 결과를 낼 수 있음. 심지어 악의적일 수도 있음. 그래서 LLM이 작성한 커밋임을 명시해 검토 강화가 필요함
    • 나는 Claude Code에게 직접 커밋을 맡김. 에이전트가 명령을 실행하고 코드를 수정하면, 내가 리뷰와 테스트를 진행함
    • 각 반복마다 자동 커밋하도록 hook을 써서, “Claude가 방금 한 일”을 쉽게 검토함

  • 나도 비슷한 시도를 했음. 좀 더 편의 기능을 추가한 Toadbox를 만들었음

  • AI용 샌드박스 얘기가 많지만, 사실 Claude Code, Codex, Gemini CLI에는 이미 내장 샌드박스가 있음

    • macOS에서는 seatbelt, Linux에서는 bubblewrap(Claude), seccomp+landlock(Codex), Windows에서는 AppContainer를 실험 중임
    • 흥미롭지만, 이 샌드박스가 특정 파일 접근만 제한하는지, 그리고 시스템 명령 실행 시에도 적용되는지는 불분명함. 단순히 에이전트 프로세스만 격리하는 거라면 실효성이 낮을 수도 있음

  • 나는 Apple Container Framework를 써서 비슷한 걸 구현 중임. 혹시 살펴봤는지 궁금함

    • Apple Container는 Docker나 Colima 대체에 가깝고, Kata Containers처럼 각 컨테이너가 별도 VM으로 동작함. macOS에서 컨테이너 개선을 시도하는 점이 반가움
      다만 Docker API 호환성과 조합성이 부족함. 관련 논의를 여기에 정리했음
      원래 Shai를 Apple Container 위에 올리려 했지만 패키징 문제로 포기함
    • 아직 안 써봤지만 흥미로움. Yolobox에는 주요 코딩 에이전트 CLI가 사전 설치된 이미지가 있음. “궁극의 vibe 코딩 이미지”를 만들고 싶음. 혹시 이미지에 특별한 설정을 하고 있는지 궁금함

  • 나도 비슷한 걸 만들고 있음 → sandbox-codex
    아직 진행 중이고, tmux 로그 가독성이 떨어짐. Docker가 완전한 샌드박스가 아니라서 VirtualBox에서 실행 중임

    • 나도 Node.js 전용으로 simple-npm-sandbox를 만들어봤음. 단순하지만 좋은 학습 경험이었음
답변달기