▲

jai - AI 에이전트를 위한 손쉬운 격리 도구

 (jai.scs.stanford.edu)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Linux 환경에서 AI 에이전트를 격리 실행할 수 있는 경량 도구로, 복잡한 컨테이너 설정 없이 단일 명령으로 안전한 실행 경계 제공
  • AI 도구가 실제 파일 시스템에 접근해 데이터를 삭제하거나 손상시키는 사례가 잇따르며, 안전한 실행 환경의 필요성이 부각됨
  • 홈 디렉터리를 copy-on-write 오버레이로 보호하고 /tmp·/var/tmp를 분리해 원본 파일 변경을 방지
  • Casual·Strict·Bare 세 가지 격리 모드를 제공해 보안 수준과 접근 범위를 선택 가능
  • Stanford 연구팀이 개발한 오픈소스 프로젝트로, AI 도구를 보다 안전하게 활용하기 위한 실용적 보호 수단 제공

AI 에이전트 격리를 위한 경량 도구 jai

  • jai는 Linux 환경에서 AI 에이전트를 손쉽게 격리(containment) 할 수 있도록 설계된 도구
    • 복잡한 컨테이너나 VM 설정 없이 단일 명령으로 안전한 실행 경계 제공
    • 코딩 보조나 스크립트 실행 등 기존 워크플로우에 바로 적용 가능

  • 실제 문제 사례

    • 여러 사용자가 AI 도구 사용 중 파일 손실 및 디렉터리 삭제 피해를 보고함
      • Nick Davidov은 15년치 가족 사진이 터미널 명령으로 삭제되었다고 보고
      • Anthropic의 Claude Code는 홈 디렉터리를 삭제해 개발 프로젝트가 손실됨
      • Cursor는 작업 트리를 비워 “모든 것이 사라졌다”고 보고됨
      • Reddit 사용자는 Antigravity가 전체 D 드라이브를 삭제했다고 언급
      • 또 다른 Cursor 사용자는 100GB의 파일이 삭제되었다고 보고
    • 이러한 사례는 AI 도구에 실제 계정 접근을 허용할 때 발생하는 보안 공백을 보여줌

  • jai의 핵심 기능

    • 실행 계정과 홈 디렉터리 사이의 경계를 자동 설정
      • 작업 디렉터리는 완전한 읽기/쓰기 권한 유지
      • 홈 디렉터리는 copy-on-write 오버레이로 보호되어 원본 파일이 변경되지 않음
      • /tmp와 /var/tmp는 독립된 공간으로 분리, 나머지 파일은 읽기 전용으로 제한
    • 명령어 앞에 jai를 붙이는 것만으로 격리 실행 가능
      • 예: jai codex, jai claude, 또는 단순히 jai로 셸 실행
    • Dockerfile이나 이미지 빌드 과정 없이 즉시 사용 가능
      • 복잡한 bwrap 플래그 설정이나 스크립트 작성이 불필요

  • 격리 모드 선택

    • Casual / Strict / Bare 세 가지 모드 제공
      • Casual: 홈 디렉터리를 copy-on-write로 보호, 대부분의 파일 읽기 가능
      • Strict: 별도 jai 사용자로 실행, 홈 디렉터리가 비워진 상태로 강력한 격리 제공
      • Bare: 홈 디렉터리가 비워진 상태지만 사용자 UID 유지
    • 각 모드는 기밀성(confidentiality), 무결성(integrity), NFS 지원 여부가 다름
      • Strict 모드는 가장 강력한 격리를 제공하지만 NFS 홈은 지원하지 않음

  • 대안 도구와의 비교

    • Docker
      • 이미지 기반 환경 재현에는 적합하지만, 호스트 도구의 임시 샌드박싱에는 무거움
      • 홈 디렉터리 오버레이 기능 없음
    • bubblewrap
      • 강력한 네임스페이스 샌드박스지만 파일시스템 구성을 직접 지정해야 함
      • jai는 이러한 복잡성을 제거
    • chroot
      • 보안 격리 수단이 아니며, 마운트·PID 네임스페이스·자격 분리 기능이 없어 Linux에서도 샌드박싱 용도로 권장되지 않음

  • 보안 한계

    • jai는 완전한 보안을 보장하지 않음
      • “casual sandbox”로서 피해 범위를 줄이지만 모든 공격을 차단하지는 않음
      • Casual 모드는 기밀성 보호가 약하며, Strict 모드도 컨테이너나 VM 수준의 격리와는 다름
      • 다중 테넌트 환경이나 고위험 상황에서는 컨테이너 또는 가상머신 사용 권장

  • 프로젝트 배경

    • Stanford Secure Computer Systems(SCS) 연구 그룹과 Future of Digital Currency Initiative(FDCI) 가 공동 개발
    • 무료 오픈소스 소프트웨어로 제공되며, 사용자가 AI를 더 안전하게 활용할 수 있도록 지원
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • .claude/settings.json에 다음 설정을 추가하면 됨

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    외부 디렉토리 접근을 허용하려면 allowRead 부분을 수정하면 됨
    이 기능은 10일 전에 추가된 새로운 샌드박스 옵션임

    • claude가 현재 디렉토리를 헷갈려 하거나 rm -rf * 같은 명령을 실행하는 걸 본 적이 있음
      다행히 동시에 일어나진 않았지만, 상상만 해도 아찔함
      샌드박스 아이디어는 좋지만, 저수준에서 강제 적용되어야 효과적임
      claude 자체가 AI가 만든 거대한 프로그램이라, 사람이 직접 만든 3000줄 미만의 보안 레이어를 추가하는 게 의미 있는 방어 수단이 될 수 있음
    • claude-code의 향후 버전이 이 설정 이름을 조용히 바꾸거나 제거할 수도 있음
      그래서 사람들은 별도의 샌드박싱 소프트웨어를 선호할 수도 있음
    • GPU를 쓰게 하되 / 삭제만 막는 농담 섞인 설정 예시를 공유함
      /dev/nvidia* 장치 접근을 허용하는 구성으로, 데이터 유출은 감수하겠다는 풍자적 설정임
    • 수십 년간 검증된 기존 보안 도구들이 이미 존재함
      claude를 제한된 권한의 사용자로 실행하면 하위 프로세스에도 격리가 자동 상속됨
    • Linux(Arch)와 macOS(Tahoe)에서 샌드박스 기능이 제대로 작동하지 않았음
      관련 이슈가 열려 있음
      bubblewrap과 seatbelt는 독립적으로는 잘 작동하지만 claude-code를 통해 실행하면 비활성화된 것처럼 보임

  • 사람들이 이렇게 쉽게 AI 에이전트를 개인 컴퓨터에 설치하는 게 놀라움
    수십 년간 시스템 보안을 지켜왔는데, 갑자기 예측 불가능한 소프트웨어에 모든 권한을 준 셈임

    • 예전에도 빌드 도구가 자동으로 의존성을 끌어오던 시절에 경고를 무시했는데, 지금은 공급망 공격이 반복되고 있음
      단기적 편의가 장기적 보안보다 우선되는 현실임
    • 사실 이런 위험을 감수하는 사람들과 보안을 중시하는 사람들은 서로 다른 집단임
    • 회사 환경에서는 이미 접근이 제한되어 있으니, 개인용 PC에서만 더 민감한 문제임
      내 원격 개발 VM에는 Claude가 봐도 상관없는 데이터만 있음
    • Docker 초창기에도 “그냥 이미지 다운로드하면 되지!”라는 분위기였음
      하지만 업계는 곧 보안 리스크를 깨닫고 대응했음

  • 단순한 Unix 권한 분리로도 충분함
    사용자 계정을 두 개 두고, AI와 공유할 폴더만 그룹으로 묶으면 됨
    관련 블로그 글 참고

  • 홈페이지에 “맹목적 신뢰를 멈추라”고 써 있는데, 설치 방법은 curl | bash 대신 수동 빌드임

    • tar 파일을 직접 풀고 makepkg -i로 설치하는 게 훨씬 안전함
      PKGFILE은 30줄 정도로 짧고, 빌드 함수도 7줄뿐임
      반면 rustup(910줄), claude(158줄), opencode(460줄) 같은 스크립트는 훨씬 복잡함
    • 반대로 curl | tar | makepkg를 한 줄로 연결하는 건 신뢰할 수 없는 방식임

  • 이 프로젝트는 설계가 잘 되어 있고, 내 방식보다 조금 더 안전하고 편리해 보임
    나는 별도 사용자 계정을 만들어 에이전트를 격리함
    다만 권한이 꼬일 때가 있어 스크립트로 수정함
    결국 가장 확실한 방법은 아예 별도 노트북을 주는 것임
    물리적으로 분리된 장비만큼 안전한 건 없음

    • 하지만 외부 서비스와 통신하려면 API 키를 줘야 해서, 그 키가 유출될 위험이 있음
      에이전트는 보안 침투 테스트 수준의 능력을 갖고 있어서 단순한 사용자 분리만으로는 불안함
    • 나도 현재는 사용자 분리 방식을 쓰고 있음
      컨테이너를 쓰면 에이전트가 스스로 컨테이너를 만들 때 혼란스러워짐

  • 사이트가 “vibe-coded”라서 퀄리티가 낮아 보이지만, 실제 툴은 Stanford 교수가 직접 구현한 것임
    FAQ 링크 참고

    • 작성자인 내가 직접 말하자면, 웹디자인은 못하지만 운영체제 전문가임
      문서 내용은 정확하게 수정했으니 신뢰해도 됨
      사이트는 AI가 만든 걸 그대로 둔 거라 다소 아이러니함
    • 저자는 David Mazieres, 2000년대 초부터 사용자 수준 파일시스템 연구를 해온 사람임
      Stanford Secure Computer Systems 그룹을 이끌고 있음
    • jai는 고위험 툴이지만, 웹사이트는 단순하니 vibe-coded여도 괜찮음
    • 그래도 개인적으로는 간결한 HTML 페이지가 더 낫다고 생각함

  • 에이전트가 프로젝트 디렉토리에 쓰기 권한을 가지면 지속적 익스플로잇이 가능하다는 점이 걱정됨
    .pyc, .venv, .git/hooks 같은 파일을 통해 샌드박스 밖에서 실행될 수 있음
    ChatGPT 대화에서도 이런 취약점이 확인됨
    그래서 가장 안전한 방법은 git patch 기반 파일 전송임
    샌드박스에서 수정된 파일을 git에 커밋된 항목만 외부로 내보내는 식으로 해야 함

    • .git/ 디렉토리를 읽기 전용으로 만드는 옵션을 추가하는 게 좋겠음
      jai -D로 CWD를 오버레이로 만들 수 있지만, 변경사항을 병합하는 게 까다로움
    • 나는 아예 샌드박스(VM 수준) 안에서만 코드를 실행함
      에이전트는 별도의 git worktree 브랜치에서 작업하고, 리뷰 후에만 병합함
      이렇게 하면 리뷰 기반 보안 흐름을 유지할 수 있음
    • 절대 git hook은 허용하지 말아야 함

  • 간단한 대안으로, 에이전트를 별도 사용자 계정에서 ssh로 실행함
    프로젝트 디렉토리를 바인드 마운트해서 접근을 제어함
    VSCode의 ssh remote 기능과 잘 어울림

    • 나도 6개월째 전용 계정을 쓰고 있는데, 접근 가능한 디렉토리만 관리하면 됨
      복잡한 보안 시스템보다 훨씬 단순하고 효율적인 격리 방식임

  • 실제로는 rm -rf보다 더 미묘한 문제가 많음
    claude-code가 SVG를 저장하려고 /public/blog/ 폴더를 만들어서 Apache 라우팅이 깨진 적이 있음
    삭제나 권한 문제는 아니지만, 의도치 않은 동작으로 블로그가 404를 뿜었음
    jai는 이런 대형 실수는 막겠지만, 이런 세밀한 문제는 여전히 어려움

  • 훌륭한 프로젝트지만 제목이 아쉬움
    현재 디렉토리에는 전체 접근, 나머지는 읽기 전용, 홈 디렉토리는 copy-on-write로 처리하는 구조가 마음에 듦
    이런 접근이 AI 에이전트의 기본 보안 모델이 되어야 함

    • 사이트에 제목이 없으니 “jai - filesystem containment for AI agents” 같은 이름이 더 어울릴 듯함
답변달기