Agent Safehouse, 로컬 coding agent에 deny-first macOS sandboxing을 적용하다

Hacker News 토론: HN thread
프로젝트 사이트: agent-safehouse.dev
GitHub: eugene1g/agent-safehouse

Agent Safehouse는 로컬 agent 시대의 꽤 현실적인 문제를 겨냥한다. 많은 coding agent가 실제로는 하나의 repository만 만지면 되는데도, 실행되는 순간 로그인된 macOS 사용자와 거의 같은 권한을 물려받는다. Hacker News에서 관심을 끈 이유도 여기에 있다. Claude Code, Codex, Aider, Gemini CLI 같은 도구가 편리한 만큼, 실수 한 번이면 다른 repo, credential, 개인 파일까지 접근 범위가 넓어질 수 있기 때문이다.

Safehouse의 접근은 비교적 단순하다. sandbox-exec와 composable policy profile을 이용해 agent process를 deny-first sandbox 안에서 실행한다. 기본적으로 선택한 workdir만 read/write를 허용하고, 사용자가 지정한 공유 폴더만 read-only 또는 read/write로 추가한다. 그 밖의 경로는 명시적으로 열어 주지 않는 한 막힌다. 문서가 강조하는 지점은 이 차단이 app 차원의 친절한 경고가 아니라, syscall 단계에서 kernel이 접근을 막는다는 점이다. 즉 ~/.ssh, 다른 repository, 개인 디렉터리를 읽으려 하면 process가 내용을 보기 전에 곧바로 permission error가 난다.

왜 이 설계가 의미가 있나

이 프로젝트가 흥미로운 이유는 새로운 agent runtime 전체를 만들려 하지 않는다는 점이다. Safehouse는 기존 도구 앞에 붙는 작은 hardening layer에 가깝다. 설치는 단일 shell script 다운로드로 끝나고, 별도 build step이나 복잡한 dependency를 요구하지 않는다. 사이트에는 policy builder와 함께 claude, codex, gemini 같은 command를 기본적으로 sandbox 안에서 실행하도록 만드는 shell wrapper 예시도 제공된다.

저자도 과장하지 않는다. GitHub README는 Safehouse를 완벽한 보안 경계가 아니라 practical least-privilege layer라고 설명한다. 이 표현이 중요하다. 핵심은 “절대 안전”이 아니라, 이미 강력한 agent를 로컬 codebase와 credential이 섞인 환경에서 쓰는 개발자에게 더 나은 기본값을 제공하는 것이다.

그래서 Safehouse는 하나의 utility release를 넘어서는 의미를 갖는다. 로컬 coding agent의 경쟁이 model quality만이 아니라 operational guardrail로 옮겨가고 있기 때문이다. agent가 무엇을 읽고, 무엇을 쓰고, 어느 정도의 ambient authority를 상속받는지에 대한 관심이 커지는 상황에서, Agent Safehouse는 macOS에서 지금 바로 적용 가능한 좁고 이해하기 쉬운 통제를 제시한 사례라고 볼 수 있다.