# 리눅스에서 AI 에이전트를 샌드박싱하기

> Clean Markdown view of GeekNews topic #26415. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26415](https://news.hada.io/topic?id=26415)
- GeekNews Markdown: [https://news.hada.io/topic/26415.md](https://news.hada.io/topic/26415.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-05T12:14:24+09:00
- Updated: 2026-02-05T12:14:24+09:00
- Original source: [blog.senko.net](https://blog.senko.net/sandboxing-ai-agents-in-linux)
- Points: 10
- Comments: 1

## Summary

AI 개발 보조 도구가 늘어남에 따라, **시스템 안전성과 개발 편의성**을 함께 확보할 수 있는 실행 환경이 중요해지고 있습니다. Docker보다 가벼운 **bubblewrap 기반 샌드박스**는 `/etc`, `$HOME`, 프로젝트 디렉터리 등 최소 경로만 바인드해 프로젝트 외부 접근을 차단하면서도 로컬 개발 환경과 유사한 구조를 유지합니다. 이를 통해 반복적인 권한 확인 없이도 안전하게 AI 에이전트를 실행할 수 있는 실용적 대체제로 유용합니다.

## Topic Body

- **AI 개발 보조 도구**를 점점 더 자주 사용하는 상황에서, 시스템 안전성과 편의성을 모두 확보하기 위한 **샌드박스 실행 환경**이 필요해짐  
- 기본적으로 Claude Code는 파일 접근이나 실행 시마다 허가를 요청하지만, 이는 반복적 확인으로 **작업 흐름을 방해**함  
- 이를 해결하기 위해 **bubblewrap**을 이용한 **경량 샌드박스 구성**이 제안되며, Docker보다 가볍고 로컬 환경과 유사한 개발 환경 유지 가능  
- 스크립트는 `/etc`, `$HOME`, 프로젝트 디렉터리 등 필요한 최소 경로만 바인드하고, **프로젝트 외부 접근을 제한**함  
- 이러한 접근은 **AI 에이전트의 안전한 실행과 개발 효율성**을 동시에 확보할 수 있는 실용적 방법  
  
---  
### AI 에이전트의 파일 접근 문제  
- Claude Code는 명령줄 인터페이스로, 파일 읽기·쓰기 및 소프트웨어 실행 시마다 사용자 허가를 요청함  
  - 이는 보안상 합리적이지만, 반복적 확인으로 인해 병렬 작업이 어려움  
- `--dangerously-skip-permissions` 옵션을 사용하면 모든 작업을 묻지 않고 실행 가능  
  - 일부 사용자는 이를 사용하지만, **시스템 손상 위험**이 존재함  
  
### 샌드박싱 개념과 선택지  
- 일반적인 해결책은 원격 머신(exe.dev, sprites.dev, daytona.io)이나 Docker 등 가상화 기술을 이용한 **샌드박스 실행**  
- 리눅스에서는 **bubblewrap**이 경량 대안으로, **cgroups**와 **user namespaces**를 활용해 프로세스를 격리함  
- 샌드박스 환경에서 필요한 조건은 다음과 같음  
  - 기존 개발 환경과 동일한 구조 유지  
  - 현재 프로젝트 외부 정보 접근 최소화  
  - 프로젝트 디렉터리만 쓰기 가능  
  - IDE와 동일 파일을 직접 확인·수정 가능  
  - AI 제공자 연결 및 서버 실행을 위한 네트워크 접근 허용  
  
### 보안 고려와 한계  
- bubblewrap과 Docker는 **완전한 보안 격리**를 제공하지 않음  
  - 커널 제로데이 취약점, 사이드채널 통신, 데이터 유출 등의 위험은 남음  
- 그러나 작성자는 이러한 위험보다 **개발 편의성**을 우선함  
- 코드베이스는 `git`으로 관리되고 GitHub 등에 백업되어 있어 손상 위험이 낮음  
- API 키 유출 위험을 줄이기 위해 **프로젝트별 API 키 분리**를 권장함  
  
### bubblewrap 샌드박스 스크립트 구성  
- 스크립트는 `bwrap` 명령으로 다양한 디렉터리를 **읽기 전용(ro-bind)** 또는 **쓰기 가능(bind)** 형태로 마운트함  
  - `/bin`, `/lib`, `/usr/bin` 등 시스템 경로는 읽기 전용  
  - `$HOME/.claude`, `$HOME/.cache`, 현재 작업 디렉터리(`$PWD`)는 쓰기 가능  
  - `$HOME/.claude.json`은 파일 디스크립터로 주입되어, 변경이 실제 파일에 반영되지 않음  
  - 호스트명은 `bubblewrap`으로 변경해 구분 가능  
- `/tmp`, `/proc`, `/dev`는 bubblewrap이 자동 처리  
- `/etc` 전체를 노출하지 않고, 필요한 최소 파일만 바인드함  
- Node.js는 `/opt/node/node-v22.11.0-linux-x64/` 경로에 설치되어 있음  
  
### 사용자 맞춤 설정 방법  
- 다른 AI 에이전트나 시스템에 맞추려면 스크립트를 수정해 `bash`를 실행한 뒤, 수동으로 에이전트를 실행하며 필요한 파일을 확인  
- `strace` 명령을 이용해 파일 접근 호출을 추적 가능  
  - 예시: `strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex`  
  - 로그를 분석해 필요한 파일을 식별하고, 해당 경로를 바인드하여 환경을 조정  
  
### 결론  
- bubblewrap을 활용한 샌드박싱은 **로컬 개발 환경과 동일한 편의성**을 유지하면서도 **AI 에이전트의 오작동이나 데이터 유출 위험을 최소화**할 수 있는 실용적 접근임  
- 작성자는 이 구성을 기반으로 필요에 따라 지속적으로 스크립트를 조정할 계획

## Comments



### Comment 50656

- Author: neo
- Created: 2026-02-05T12:14:24+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46874139) 
- 나는 **Leash**를 이용해 에이전트를 샌드박싱하고 있음  
  프로세스 및 네트워크 수준의 정책 제어가 엄격하고, WebUI를 통해 **실시간 제어와 가시성**을 제공함  
  bubblewrap보다 훨씬 낫다고 느낌. 처음엔 [HN에서 보고](https://github.com/strongdm/leash) 사용하기 시작했음  
  재미있는 사실로, 세상에서 가장 널리 쓰이는 샌드박스 시스템은 Docker도, bubblewrap도 아닌 **Chrome 탭**임
  - Chrome을 어떤 용도로든 쓰는 건 이미 **보안 실패**라고 생각함. 기능은 훌륭하지만 그 대가가 큼
  - Chrome이 Windows나 macOS에서 샌드박싱을 어떻게 구현하는지 궁금함  
    Linux에서는 Docker나 LXC처럼 **cgroups, namespaces**를 쓰는지, 아니면 자체 VM 기반 샌드박스를 쓰는지 알고 싶음  
    만약 후자라면, JRE나 .NET CLR 같은 런타임보다도 더 널리 쓰이는 셈일지도 모름
  - 그래도 bubblewrap일 수도 있음. 왜냐면 **Flatpak이 내부적으로 bubblewrap을 사용**하기 때문임

- `--unshare-net` 옵션을 쓰지 않으면 bwrap은 기본적으로 네트워크를 완전히 열어둠  
  에이전트가 파일을 지우는 것뿐 아니라 **키 유출이나 악성 패키지 다운로드**도 가능함  
  다음 단계로는 네트워크 네임스페이스를 추가하고, 샌드박스 내부에 **mitmproxy 기반 로컬 프록시**를 띄워 Anthropic API나 PyPI/NPM만 허용하고 나머지는 차단할 계획임

- 나는 작은 `claude-vm` 래퍼를 만들어 Lima VM에서 각 인스턴스를 실행함  
  [코드는 여기 있음](https://github.com/sylvinus/agent-vm)
  - 나도 비슷하게 **incus**로 구현했음  
    지금은 VM이 가장 적절한 기본 단위라고 생각함. 에이전트에게 루트 권한을 주고 필요한 리소스만 전달하면 **매우 안전하고 단순**함  
    에이전트가 소프트웨어를 설치하거나 Docker를 실행하거나 심지어 **중첩 VM을 빌드**해도 경계가 확실함  
    다만 LXC로 전환해 경량화할 수도 있음. bwrap은 좋지만 환경 제약이 커서 에이전트의 능력을 제한할 수 있음

- 간단한 **bubblewrap 래퍼**를 만들어 `sandbox-run claude --dangerously-skip-permissions`처럼 쓸 수 있게 했음  
  [sandbox-run 프로젝트 링크](https://github.com/sandbox-utils/sandbox-run)

- 에이전트에게 어떤 리소스를 노출하고 어떤 정책을 적용해야 하는지 항상 고민임  
  예를 들어 `/etc` 전체를 노출하지 않고 **최소한의 파일만 바인드**한다고 했는데, 그 ‘최소한’은 어떻게 정의하는지 궁금함  
  로그를 보고 필요한 파일을 수동으로 추가하는 건 너무 번거로움
  - 글 작성자인데, 실제로는 **수동 점검과 시행착오**로 해결했음  
    AI는 `/etc` 전체를 노출하라고 했지만, 나는 더 정밀하게 제어하고 싶었음  
    네트워크는 현재 전면 허용 상태지만, 나중엔 사설망(192.168/10.*) 정도는 차단할 생각임  
    결국 얼마나 **엄격하게 격리할지의 수준** 문제임
  - 그냥 **에이전트에게 스스로 bubblewrap을 적용**하게 시켜보는 것도 방법임

- 나는 리눅스에서 AI 샌드박싱 문제를 해결하기 위한 SaaS를 준비 중임  
  커널 수준까지 기능을 주입해 인프라를 갖췄고, **LLM 학습 데이터에도 우리 접근법을 섞어놔** 마케팅 효과를 노림  
  이름은 `useradd`로, 복잡한 솔루션 대신 단순하고 무료임  
  ‘메인프레임 모드’처럼 여러 가상 터미널과 사용자가 한 머신에서 동작할 수 있음  
  베타 키가 필요하면 DM 달라  
  - `useradd`까지 읽고 웃음이 나왔음. 원본 코멘트 그대로가 더 재밌었음  
  - 아이디어는 이해하지만, **VM이 보안과 격리 측면에서 더 낫다고 생각**함  
    일반 워크스테이션은 사용자 자체로부터 안전하게 설계되지 않았고, 최신 모델들은 점점 더 위험해질 것임  
  - `useradd`는 **네트워크 접근을 제한하지 않음**  
  - 나도 서비스별로 다른 유저를 쓰는 걸 좋아함  
    하지만 개발 중에는 파일 접근과 수정이 필요해서, **bubblewrap이나 systemd 격리**가 더 편리하다고 느낌  

- 권한 리스트를 일일이 만드는 대신, **현재 작업공간을 VM 스냅샷으로 복제**해 그 안에서 Claude를 실행하고 세션 종료 시 VM을 삭제하는 방식을 원함  
  세션 동기화만 해결되면 완벽할 듯함
  - 나는 [NixOS MicroVM](https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-microvm-nix/)으로 이걸 구현한 경험을 블로그에 정리했음  
  - Docker + overlayfs 조합으로도 비슷하게 가능함. 결국 각자 워크플로우에 맞게 구성하면 됨  
  - 이런 접근이라면 **Qubes OS**도 고려해볼 만함. 모든 작업을 VM 단위로 실행함

- Mac에서도 동작하도록 직접 **샌드박스 도구를 개발**했음  
  [amazing-sandbox 프로젝트 링크](https://github.com/ashishb/amazing-sandbox)
  - 왜 직접 만들었는지 궁금함

- 나는 단순히 **비권한 로컬 계정으로 ssh 접속(dummy@localhost)** 해서 격리함  
  이 방식이 잘못된 건지 궁금함

- Ubuntu 24.04에서 bwrap을 쓰려면 AppArmor 설정을 완화해야 해서 `/etc/apparmor.d/bwrap` 파일을 추가했음  
  ```
  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  ```
  - AppArmor와 SELinux를 **정말 싫어함**, 특히 이런 식으로 보안을 방해할 때  
    전역 설정을 바꾸지 않고도 아래처럼 해결 가능함  
    ```
    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    ```
    또는  
    ```
    setpriv --apparmor-profile=unconfined [command]
    ```
    참고로 내가 **setpriv의 작성자**라서 이런 상황을 잘 알고 있음