Zed Sandboxing은 Zed Agent가 실행하는 terminal과 fetch 도구를 운영체제 수준 보안 기능으로 제한하는 기능이다. 도구 승인 프롬프트처럼 에이전트가 규칙을 따르리라 기대하는 방식이 아니라, macOS Seatbelt, Linux bubblewrap, Windows WSL 기반 격리로 파일 쓰기와 네트워크 접근을 강제 차단한다.
도구 권한과 샌드박싱의 차이
도구 권한(tool permissions)은 에이전트가 특정 도구를 실행해도 되는지 결정한다. 샌드박싱은 도구가 실제로 실행된 뒤 그 프로세스가 어디에 쓰고, 어떤 host에 접속하고, 어떤 IPC socket에 접근할 수 있는지 제한한다.
| 계층 | 질문 | 예시 |
|---|---|---|
| 도구 권한 | 에이전트가 이 도구를 호출해도 되는가 | terminal 실행 승인 |
| 샌드박싱 | 실행된 명령이 무엇에 접근할 수 있는가 | 프로젝트 밖 쓰기 차단, 네트워크 차단 |
복잡한 shell script는 도구 권한만으로 충분히 통제하기 어렵다. 한 번 terminal을 승인하면 그 안에서 여러 파일 작업과 네트워크 호출이 일어날 수 있기 때문이다. Zed Sandboxing은 이 실행 환경 자체에 OS 정책을 건다.
적용 범위
현재 Zed Agent 샌드박싱은 다음 도구에 적용된다.
| 도구 | 제한 대상 |
|---|---|
terminal | 파일시스템 쓰기, outbound network, Git metadata 쓰기 |
fetch | 접근 가능한 host |
Zed 자체, language server, extension, task, 일반 터미널 탭, External Agents, Terminal Threads에는 적용되지 않는다. 이 범위 제한은 중요하다. 에이전트가 프로젝트 파일을 고쳐 language server나 build tool이 나중에 샌드박스 밖에서 실행되도록 만들 수 있기 때문이다.
기본 접근 정책
기본적으로 sandboxed terminal command는 대부분의 파일을 읽을 수 있고, 열린 프로젝트 디렉터리 안에는 쓸 수 있다. 하지만 .git 디렉터리와 linked worktree metadata는 읽기만 가능하고 쓰기는 차단된다. 프로젝트 밖 쓰기와 outbound networking은 추가 승인이 필요하다.
| 접근 | 기본 동작 |
|---|---|
| 파일 읽기 | 대부분 허용 |
| 프로젝트 쓰기 | 열린 프로젝트 안에서 허용, Git metadata 제외 |
| Git metadata | 읽기 허용, 쓰기 차단 |
| 임시 파일 | sandbox별 임시 위치 제공 |
| 프로젝트 밖 쓰기 | 승인 전 차단 |
| outbound network | 승인 전 차단 |
| local IPC socket | 샌드박스 탈출에 악용될 수 있어 차단 |
플랫폼별 구현
| 플랫폼 | 구현 방식 | 요구사항 |
|---|---|---|
| macOS | Apple Seatbelt, sandbox-exec | 추가 요구사항 없음 |
| Linux | bubblewrap | 실행 가능한 non-setuid bwrap 필요 |
| Windows | WSL 안의 bubblewrap | WSL 필요, NTFS 경로에서는 보장 약화 |
macOS와 Linux에서는 host-specific network 승인을 HTTP/HTTPS proxy로 제한한다. SSH, FTP, raw socket client처럼 proxy 환경 변수를 따르지 않는 도구는 host 승인을 받아도 기대대로 동작하지 않을 수 있다. 이 경우에는 SSH URL보다 HTTPS URL을 쓰는 편이 낫다.
Windows는 WSL 안에서만 같은 수준의 Linux 샌드박싱을 제공한다. NTFS 드라이브에 있는 경로는 WSL 파일시스템 객체 매핑 한계 때문에 쓰기 격리 보장이 약해질 수 있다.
승인 프롬프트와 지속 권한
에이전트가 기본 sandbox 밖 접근을 요청하면 Zed는 승인 프롬프트를 띄운다. 사용자는 특정 host 네트워크 접근, 전체 네트워크 접근, 특정 경로 쓰기, Git metadata를 제외한 전체 쓰기, unsandboxed 실행 등을 한 번·현재 thread·항상 허용 범위로 승인할 수 있다.
반복적으로 필요한 권한은 settings.json에 저장할 수 있다.
{
"agent": {
"sandbox_permissions": {
"network_hosts": ["github.com", "*.npmjs.org"],
"write_paths": ["/Users/you/.cache/my-tool"]
}
}
}실무에서는 allow_all_hosts, allow_fs_write_all, allow_unsandboxed보다 특정 host와 특정 write path를 우선해야 한다.
샌드박스가 막지 못하는 것
Zed 문서는 샌드박스를 defense-in-depth의 한 층으로 봐야 한다고 강조한다. OS 기능과 Zed 구현에 버그가 있을 수 있고, 사용자가 넓은 권한을 승인하면 샌드박스는 그 결정을 막지 않는다.
또한 샌드박스 밖에서 실행되는 도구는 별도 위험이다.
- Rust procedural macro가 language server에서 실행될 수 있음
Makefile에 삽입된 명령이 사용자의 일반 터미널에서 나중에 실행될 수 있음- 프로젝트 안에 생성된 submodule metadata가 이후 Git 명령 실행에 영향을 줄 수 있음
따라서 샌드박싱을 켜더라도 diff review, 좁은 권한 승인, 위험한 language server 설정 점검은 계속 필요하다.
Docker Sandbox와의 차이
docker-sandbox가 에이전트 실행 환경 전체를 MicroVM으로 감싸는 접근이라면, Zed Sandboxing은 Zed Agent의 특정 도구 호출에 OS 정책을 적용하는 IDE 내장 보호막에 가깝다.
| 항목 | Zed Sandboxing | Docker Sandbox |
|---|---|---|
| 적용 위치 | Zed Agent 도구 호출 | 독립 실행 샌드박스 |
| 주요 대상 | terminal, fetch | 에이전트와 그 실행 환경 |
| 구현 | Seatbelt, bubblewrap, WSL | MicroVM |
| 장점 | IDE 작업 흐름에 자연스럽게 통합 | 강한 환경 격리와 독립 Docker 엔진 |
| 한계 | Zed 외부 실행 경로는 보호하지 않음 | 별도 런타임과 운영 구성이 필요 |
누가 쓰면 좋은가
- Zed에서 AI 코딩 에이전트를 쓰는 개발자: 프로젝트 밖 파일 쓰기와 무분별한 네트워크 접근을 줄이고 싶을 때
- 보안 민감 저장소를 다루는 팀: 에이전트 승인 프롬프트와 OS 강제 정책을 함께 쓰고 싶을 때
- 에이전트 도구 개발자: 도구 권한만으로는 shell 내부 동작을 통제하기 어렵다는 점을 이해해야 할 때
- 에이전트 플랫폼 설계자: IDE 내장 샌드박스와 외부 MicroVM/컨테이너 격리의 책임 범위를 나눌 때
관련 문서
- docker-sandbox — MicroVM 기반 AI 에이전트 격리 실행 환경
- agent-sandboxing-tips-brain-hands — 에이전트 본체와 코드 실행 샌드박스를 분리하는 설계
- agent-harness — 샌드박스와 실행 루프를 포함한 에이전트 하네스 설계
- ai-agent-security-tips-docker-sandbox — Docker 샌드박스로 에이전트 실행 환경 격리하기
참고 자료
- Zed Sandboxing — Zed Docs (2026-08-07 확인)