▲

Agent Safehouse – macOS용 로컬 에이전트 샌드박싱 도구

 (agent-safehouse.dev)
7P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • macOS 네이티브 샌드박스를 통해 로컬 AI 에이전트가 시스템 외부를 변경하지 못하도록 격리하는 도구
  • 모든 에이전트가 독립된 샌드박스 환경에서 실행되어, 사용자 홈 디렉터리나 다른 프로젝트에 접근 불가
  • Deny-first 접근 모델을 적용해, 명시적으로 허용된 디렉터리만 읽기·쓰기 가능
  • 설치는 단일 Bash 스크립트로 완료되며, 별도 빌드나 의존성 없이 바로 실행 가능
  • LLM 기반 프로필 생성 기능을 통해 최소 권한 sandbox-exec 설정을 자동화할 수 있음

개요

  • Agent Safehouse는 macOS 전용 샌드박싱 시스템으로, 로컬에서 실행되는 AI 에이전트가 시스템 파일을 손상시키지 않도록 보호
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • LLM의 확률적 특성으로 인한 예기치 못한 명령 실행 위험을 차단
  • 모든 주요 에이전트가 샌드박스 내에서 완벽히 동작하며, 외부 시스템에는 영향을 미치지 않음
  • Deny-first 접근 모델을 채택해, 기본적으로 모든 접근을 차단하고 명시적으로 허용된 경로만 접근 가능
    • 예시: ~/my-project는 읽기/쓰기 허용, ~/.ssh, ~/.aws, ~/other-repos는 접근 거부

설치 및 실행

  • 설치는 단일 셀 스크립트 다운로드로 완료
    • curl 명령으로 스크립트를 받아 ~/.local/bin/safehouse에 저장 후 실행 권한 부여
  • 이후 safehouse 명령으로 원하는 에이전트를 실행
    • 예: safehouse claude --dangerously-skip-permissions
  • Safehouse는 기본적으로 현재 작업 디렉터리(git root) 에 읽기/쓰기 권한을 부여하고, 도구 체인 디렉터리에는 읽기 전용 접근을 허용

샌드박스 검증 예시

  • 민감한 파일 접근 시 커널 수준에서 차단됨
    • safehouse cat ~/.ssh/id_ed25519 실행 시 “Operation not permitted” 오류 발생
    • 다른 프로젝트 디렉터리(~/other-project)는 보이지 않음
    • 현재 프로젝트 디렉터리는 정상적으로 접근 가능

자동화 및 프로필 생성

  • 쉘 함수 추가로 모든 에이전트를 기본적으로 Safehouse 내에서 실행 가능
    • 예: .zshrc 또는 .bashrc에 safe() 함수 정의 후 claude, codex, amp, gemini 명령을 자동 샌드박싱
    • 샌드박스 없이 실행하려면 command claude 형태로 호출
  • LLM 기반 프로필 생성 기능 제공
    • Claude, Codex, Gemini 등 모델이 Safehouse 템플릿을 분석해 최소 권한 sandbox-exec 프로필을 생성
    • 홈 디렉터리와 도구 체인 정보를 기반으로 ~/.config/sandbox-exec.profile 경로에 저장
    • 현재 작업 디렉터리에 대한 접근 권한과 에이전트별 단축 명령어를 포함

보안 및 활용 의의

  • LLM 기반 로컬 에이전트가 의도치 않은 파일 삭제나 시스템 변경을 수행하지 못하도록 보호
  • macOS 커널 수준의 접근 제어를 활용해 기본적으로 안전한 실행 환경을 제공
  • 단일 스크립트 기반으로 개발자 워크플로우에 쉽게 통합 가능
▲
GN⁺ 21시간전  [-]
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를 설치함

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

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

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

    • 오타였음, 방금 수정 완료함
답변달기