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