Hacker News 의견들

• 내가 만든 프로젝트가 이렇게 빨리 공개될 줄은 몰랐음
  1️⃣ 나는 로컬에서 직접 실행되는 에이전트를 선호함. 컨테이너나 원격 서버가 아니라, 내가 세밀하게 조정한 내 머신 위에서 돌아가는 게 마음이 편함
  2️⃣ 이건 사실상 sandbox-exec용 정책 생성기임. 의존성도 없고, 가상화도 없음. 대신 각 에이전트가 자동 업데이트, 키체인 통합, 이미지 붙여넣기 등을 수행하기 위해 필요한 최소 권한을 찾는 데 많은 시간을 들였음. 관련 조사 내용은 agent-safehouse.dev/docs/agent-investigations에 정리되어 있음
  3️⃣ 프로젝트 전체를 쓸 필요도 없음. Policy Builder만으로도 sandbox-exec 정책을 생성해 dotfiles에 넣어 쓸 수 있음

  • 미리 공개된 건 미안함. 예전에 남긴 댓글을 보고 써봤는데, 효율이 너무 좋아서 글로 소개할 만하다고 생각했음
    기존에도 sandbox 정책 문서는 봤지만, 이렇게 바로 쓸 수 있는 앱 형태는 처음이었음
    다만 몇 가지 불편한 점이 있었음 — 홈 디렉토리의 .gitconfig, .gitignore 접근이 제한되고, 프로세스 접근 제약 때문에 Claude에게 lldb나 pkill 같은 명령을 실행시킬 수 없음. 세밀한 권한 제어가 가능하면 좋겠음
  • 이걸 openclaw에 적용할 수 있을지 궁금함. 로컬 머신에서 접근 가능한 형태로 돌리면 편하지만, 동시에 제어가 어려워지는 문제도 있음
  • 로컬 실행과 컨테이너 실행의 실질적 차이가 뭔지 궁금함
  • 오, 내가 찾던 게 이거였음. microsandbox를 잘 맞춰보려 했는데 이게 훨씬 현실적임
    사이트랑 스크립트를 훑어봤는데 특별한 문제점은 못 찾았음. 혹시 문서화되지 않은 주의할 점이 있을까?
  • 아이러니하게도, 나는 AI를 신뢰하지 않아서 이런 프로젝트에 관심을 가졌는데, 설치하려면 임의의 서버에서 .sh 파일을 받아 실행해야 한다는 점이 좀 웃김
    tarball 형태로 배포해줬으면 좋겠음. tarball은 내부를 직접 확인하고 CI에서 자동 생성된 건지도 검증할 수 있으니까 더 신뢰할 수 있음

• 이런 프로젝트를 보니 반갑고, 지금 sandboxing이 가장 큰 과제라고 생각함
  초기 사용자들은 무턱대고 로컬에서 에이전트를 돌리겠지만, 장기적으로나 기업 환경에서는 절대 통하지 않음
  단순히 네트워크, 파일, 실행 권한 제어를 넘어서, 브라우저 테스트나 클라우드 리소스 생성 같은 복잡한 시나리오를 다뤄야 함
  결국 보안·비용·권한 제어가 통합된 실용적 접근법이 필요함

  • 하지만 혹시 이게 근본적으로 해결 불가능한 문제일 수도 있지 않을까? 기능성과 안전성은 항상 충돌하고, 사람들은 결국 전자를 선택함
  • 파일 수준의 샌드박싱은 기본이고, 진짜 어려운 건 자격 증명과 네트워크 제어임
    나는 로컬 데몬이 짧은 수명의 JWT를 발급해 에이전트가 직접 키를 다루지 않게 하는 방식을 씀. API 접근엔 잘 맞지만, 여전히 파일 시스템 수준에서는 EC2 인스턴스를 무한히 띄울 수도 있음

• 여러 샌드박스를 비교 평가하는 게 어렵다는 게 문제임
  이건 sandbox-exec의 래퍼로 보이는데, 요즘 이런 래퍼가 많이 생김
  진짜 필요한 건 신뢰성 검증 문서와 자동화된 테스트임. 대부분의 샌드박스는 문서가 부족함
  신뢰하려면 세부 문서와 작동 증거가 필요함

  • 그래서 나는 Bash로 구현했음 — 불투명한 바이너리를 피하려고
    각 에이전트별 sandbox-exec 프로필은 GitHub 프로필 폴더에 분리되어 있고, 쉽게 검토 가능함
    실제 에이전트로 E2E 테스트도 수행 중임
    Safehouse 래퍼 없이도 Policy Builder로 최소 권한 정책을 직접 생성 가능함
    또 LLM에게 샌드박스 프로필을 작성하게 하는 지침 파일도 제공함

• 이건 sandbox-exec의 래퍼 스크립트임. 미리 잘 짜인 프리셋이 많아서 좋음
  sandbox-exec의 90%는 올바른 범위 설정이고, 나머지 90%는 그걸 이해하는 일임
  단, overlay나 copy-on-write 방식으로 샌드박싱할 수 있으면 좋겠음. 내 .bashrc가 아닌 임시 환경만 수정되면 충분함

  • Bash를 쓴 이유는 Go나 Rust 바이너리를 믿기 어렵기 때문임
    overlay FS는 macOS에서 어렵지만, CWD 외부를 읽기 전용으로 제한해 임시 폴더에서 작업하도록 유도하는 식으로 해결했음
  • 나는 Amika라는 OSS를 만들고 있음. 로컬·원격 샌드박스를 빠르게 띄워주는 도구로, Git과 잘 연동됨
    TCP/UDP 포트 노출, 팀원과의 공유도 가능함. GitHub 링크 참고 바람
  • 나는 Treebeard라는 프로젝트를 만들었음. sandbox-exec, worktree, COW 파일시스템을 결합한 구조임
    git-ignored 파일을 안전하게 접근할 수 있음. Treebeard 링크
  • 그런데 sandbox-exec은 이미 deprecated된 거 아님?

• 흥미로운 사실: sandbox-exec은 macOS Sierra(2016) 부터 공식적으로 deprecated 상태였음
  그래도 여전히 유용하게 쓰이고 있음. Apple의 App Sandbox는 이런 사용자 정의 규칙엔 맞지 않음
  Apple이 완전 폐기하지 않길 바람

  • 사실 태생부터 deprecated였던 것 같음. 프로필 언어 문서화가 거의 없고, 대부분 역공학으로 파악된 수준임

• Sandvault라는 프로젝트도 있음. sandbox-exec과 Unix 사용자 시스템을 결합한 방식임
  각 에이전트에 별도의 비권한 사용자 계정을 주고, sudo·SSH·공유 디렉토리로 상호작용함
  Sandvault GitHub 링크

• 나는 macOS용 GUI 앱을 만들어서 sandbox-exec을 시각적으로 관리할 수 있게 했음
  도메인별 네트워크 필터링과 비밀 탐지 기능도 포함함
  multitui.com

• Apple의 container 명령어를 이용해 Claude 코드를 Apple 컨테이너 안에서 실행하는 방법을 공유함
  container system start → container run → container exec 순으로 환경을 구성하고, Node.js와 Claude를 설치함

  • 고마움! Homebrew에도 apple/container가 있음을 처음 알았음

• 왜 로컬에서 에이전트를 돌리는 게 더 낫다고 생각하는지 궁금함.
  대부분의 사람에게는 원격 실행이 더 효율적일 것 같음 — 항상 켜둘 필요가 없으니까

  • 로컬 실행의 장점은 통제권과 소유권임. Plex나 웹서버를 직접 돌리는 이유와 비슷함
    게다가 구독료를 피할 수 있음
  • 나는 이 문제를 해결하려고 pixels를 만들었음. TrueNAS SCALE이나 Incus 위에서 실행 가능함
    보안 강화를 진행 중이며, AI 워크플로에는 충분히 적합함
    pixels GitHub 링크

• “clunker”가 “clanker”의 새로운 속어인지 궁금함. 친구의 친구 Roku가 물어봄
  지금 샌드박싱 문제로 고생 중이라 타이밍이 딱 좋음

  • 오타였음, 방금 수정 완료함