TL;DR

  • 작업 폴더 밖의 파일 접근은 로컬 오용뿐 아니라 AI 제공자에게 민감 정보가 전송되는 위험도 만들며, Agent Safehouse는 macOS 커널 수준에서 이를 차단함.
  • safehouse pi처럼 선호하는 AI 하니스(harness)를 샌드박스에서 실행할 수 있지만, 작업 폴더 안의 .env 파일은 별도 규칙 없이는 읽힐 수 있음.
  • sensitive-deny.sb는 작업 폴더 접근 허용 규칙 뒤에 로드되어 환경 파일, 키·인증 정보, 클라우드·인프라 비밀 파일의 읽기와 쓰기를 거부함.
  • .env.example, .env.sample, .env.template, .env.dist는 거부 규칙 뒤에서 읽기를 다시 허용하며, 전역 도구 인증 파일 차단은 기본적으로 비활성화됨.
  • 설정 파일을 safehouse --append-profile로 추가하면 에이전트의 .env 접근 시도가 운영체제 수준에서 거부되며, 파일 존재 여부는 보여도 내용은 읽지 못함.

AI 에이전트의 파일 접근 위험

  • 작업 중인 폴더 밖의 파일에 AI 에이전트 접근 권한을 줄 이유는 거의 없으며, 이는 큰 보안 위험임.
  • 위험은 에이전트가 파일을 로컬에서 오용하는 데 그치지 않음. AI 제공자에게 보내는 프롬프트에 민감 정보가 포함되거나, 알 수 없는 독일어 위키백과 페이지에 정보가 저장되는 경우도 가능함.
  • Agent Safehouse는 macOS용 AI 샌드박스로, 커널 수준에서 AI 에이전트의 파일 및 폴더 접근을 차단함.
  • safehouse pi처럼 선호하는 AI 하니스를 실행할 수 있으며, 예시 설정은 셸 초기화 파일인 .zshrc에 safepi 별칭으로 등록하는 방식임.
  • 다만 이 방식만으로는 에이전트가 작업 폴더 안의 민감 파일에 접근하는 것을 막지 못함. 예를 들어 .env 파일은 별도 차단 대상임.

민감 파일 차단 프로필

  • 스크립트 폴더에 sensitive-deny.sb 설정 파일을 두고, 이를 경로 허용 규칙이 모두 적용된 뒤 불러오도록 구성함.
  • 샌드박스 규칙은 나중에 선언된 규칙이 우선하므로, 마지막에 거부 규칙을 추가하는 것이 작업 폴더나 도구 설정 디렉터리의 읽기 허용보다 민감 경로 차단을 우선시키는 방법임.
  • Agent Safehouse의 문서화된 최종 계층인 --append-profile로 프로필을 추가하거나, 별도 실행 래퍼가 실행 시점의 작업 폴더 허용 규칙 뒤에 파일을 덧붙이는 방식임.
  • 프로필은 Safehouse의 00-base 프로필에서 정의한 HOME_DIR 및 home-literal을 사용함. 이 파일이 기본 프로필 뒤에 로드되므로 두 사용 방식 모두에서 해당 도우미를 사용할 수 있음.

차단 대상과 예외

  • 심각도 1 차단 대상은 .env 계열 파일, .dev.vars, 키 자료, 인증 정보 저장소, 서비스 계정 JSON, 테라폼 상태 파일, direnv 설정임.
  • 환경 파일 규칙은 .env와 *.env, .env.local, .env.production, foo.env.staging 같은 이름을 포함함. 파일명 앞의 접두부가 비어 있는 경우도 정규식에서 의도적으로 허용함.
  • Cloudflare Workers 및 Wrangler의 로컬 비밀 파일인 .dev.vars와 그 파생 파일, 빌드된 dist 폴더의 복사본도 차단 대상임. 비밀 정보가 자주 포함되는 .envrc도 읽기와 쓰기를 거부함.
  • 키 및 인증 정보 규칙은 .pem, .key, .p12, .pfx, .jks, .keystore, id_rsa, id_ed25519, id_ecdsa 파일과 .netrc, _netrc, .git-credentials, .htpasswd, .sentryclirc를 대상으로 함.
  • 클라우드 및 인프라 비밀 규칙은 서비스 계정 및 Firebase Admin SDK JSON, secrets.yaml·secrets.yml, *.tfvars, *.tfvars.json, *.tfstate, *.tfstate.backup을 포함함.
  • 거부 규칙은 파일 읽기, 읽기 메타데이터, 쓰기를 차단함. 다만 테스트 픽스처에서 .key 파일이 필요하면 해당 규칙을 제거할 수 있음.
  • 비밀이 아닌 템플릿을 다시 열도록 거부 규칙 뒤에 .env.example, .env.sample, .env.template, .env.dist의 읽기를 허용함. 저장소에 실제 값을 담은 파일이 있다면 이 예외 규칙을 제거해야 함.
  • 심각도 2인 전역 도구 인증 정보는 기본적으로 주석 처리된 선택 설정임. 차단을 켜면 해당 도구가 샌드박스 안에서 작동하지 않을 수 있음.
  • ~/.npmrc 차단은 npm 게시 및 비공개 패키지 설치를, ~/.pypirc 차단은 Twine 업로드를 방해함.
  • ~/.config/gh/hosts.yml 차단은 gh 인증 및 풀 리퀘스트 자동화를, ~/.config/git/credentials와 ~/.git-credentials 차단은 Git 인증 정보를 사용하는 작업을 방해함.
  • ~/.netrc 차단은 curl 및 Heroku 방식의 도구를 방해함.
  • SSH 키, 클라우드 디렉터리, 키체인 등 나머지 항목은 기본 거부 규칙으로 이미 보호되므로, 추가 명시 규칙은 심층 방어 목적에 한정됨.

설정 적용과 검증

  • .zshrc의 safepi 별칭에 --append-profile="$HOME/Scripts/sensitive-deny.sb"를 추가해 pi 실행 시 차단 프로필을 로드함.
  • 에이전트에게 .env의 DATABASE_URL을 출력하라고 요청하면, 에이전트는 파일이 존재하는 것은 확인할 수 있지만 운영체제 수준에서 파일 접근이 차단됨.

“아니요. 파일은 존재하지만 모든 접근 시도가 운영체제 수준에서 거부됨.”

  • 예시에서는 cat, grep, ls, stat, xattr, Node.js의 fs.lstatSync('.env'), Pi 자체 읽기 도구 모두 EPERM(작업 허용 안 됨) 오류를 반환함.
  • .gitignore 같은 저장소의 다른 파일은 읽을 수 있어, 차단이 .env 파일에 적용된다는 점도 확인됨.

제한 사항

  • 파일명 기반 차단은 완전한 보장이 아님. 대소문자를 구분하지 않는 APFS에서는 .ENV가 .env로 해석될 수 있음.
  • 하드 링크 또는 이름을 바꾼 복사본은 새 이름으로 읽힐 수 있음.
  • 저장소에 커밋된 .env는 .git/의 기록이나 객체를 통해 계속 읽힐 수 있음.
  • 차단 규칙은 쓰기도 거부하므로 cp .env.example .env도 실패함. 템플릿 파일 생성을 허용해야 한다면 해당 거부 규칙에서 file-write*를 제거해야 함.