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

(jai.scs.stanford.edu)

1P by GN⁺ 19시간전 | ★ 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⁺ 19시간전 [-]

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” 같은 이름이 더 어울릴 듯함

답변달기

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

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

실제 문제 사례

jai의 핵심 기능

격리 모드 선택

대안 도구와의 비교

보안 한계

프로젝트 배경

Hacker News 의견들