에이전트를 둘 이상 씁니다
ai-jail입니다. 정책 파일 하나로 어떤 명령이든 감싸고, 프로세스 전체가 안에 들어갑니다. 설치.
마지막 검토일 2026년 10월 15일. 다른 제품은 빠르게 바뀌므로, 다른 제품에 관한 서술에는 모두 해당 벤더의 공식 문서 링크를 달았습니다.
요약
여섯 가지 상황과 각각의 답입니다. 근거는 페이지 나머지에 있습니다.
Claude Code만 씁니다
Anthropic의 sandbox-runtime도 베타이지만 프로세스 전체를 감쌉니다. ai-jail은 여기에 빈 홈과 닫힌 네트워크를 더합니다. 카드 보기.
에이전트 자체 샌드박스와 프롬프트를 쓰고 싶습니다
그대로 켜 두세요. ai-jail 안에서도 동작합니다. 둘 다 쓰기.
도구별 정책, 실행 중 승인, 서명된 감사 기록이 필요합니다
그 부분은 nono가 더 나갑니다. 대신 정책 언어와 슈퍼바이저를 감수해야 합니다. 래퍼 비교.
코드에서 도구 호출 하나씩 샌드박스에 넣습니다
zerobox에는 그런 용도의 SDK가 있습니다. 읽기는 열어 두고, 2026년 5월 이후 릴리스가 없습니다. 래퍼 비교.
코드를 전혀 믿지 못합니다
일회용 가상 머신입니다. 이 페이지의 모든 도구는 호스트와 커널을 공유합니다. Docker, 컨테이너, VM.
벽이 서 있는 위치
이 글을 쓰는 시점에 Claude Code의 샌드박스는 셸 명령과 그 자식 프로세스에 적용됩니다. 파일 도구는 샌드박스 대신 권한 시스템을 쓰고, 문서에는 MCP 서버와 훅이 호스트에서 제약 없이 실행된다고 적혀 있습니다. ai-jail은 에이전트 자체를 벽 안에서 시작하므로 에이전트가 띄우는 것도 전부 안에 있습니다.
↔ 옆으로 밀어 전체 다이어그램을 확인하세요
Codex도 자신이 실행하는 명령을 샌드박스에 넣고 codex 프로세스는 바깥에 둡니다. 문서에 따르면 MCP 서버는 별도 프로세스나 전송 방식을 쓰므로 샌드박스 바깥에 있습니다.
권한 확인 프롬프트는 종류가 다른 보호입니다
프롬프트는 사람에게 묻고, 사람은 서두르거나 속을 수 있습니다. 샌드박스는 커널에 묻고, 커널은 매번 같은 답을 줍니다.
↔ 옆으로 밀어 전체 다이어그램을 확인하세요
사람을 빼는 모드
이 글을 쓰는 시점에 아래 에이전트에는 모두 더 이상 묻지 않는 모드가 있습니다. 프롬프트가 사라지면 남는 보호는 샌드박스뿐이고, 그것도 켜져 있을 때 이야기입니다.
| 에이전트 | 모드 | 벤더가 설명하는 동작 |
|---|---|---|
| Claude Code | auto | 모든 것이 실행되고 두 번째 모델이 나 대신 동작을 검토합니다. 문서는 이 분류기를 격리 경계가 아닌 동작 단위 제어라고 부릅니다. |
| Claude Code | bypassPermissions, 또는 --dangerously-skip-permissions | 모든 것이 검사 없이 실행됩니다. 문서는 격리된 컨테이너와 VM에서만 쓰라고 안내합니다. |
| Codex CLI | 승인 정책 never | 에이전트가 묻지 않습니다. 샌드박스 모드는 그대로 적용됩니다. 승인과 보안 문서를 참고하세요. |
| Codex CLI | danger-full-access, 또는 --yolo | 샌드박스가 꺼집니다. --yolo를 쓰면 승인도 없어집니다. |
나란히 비교
아래 내용은 모두 이 글을 쓰는 시점의 각 제품 문서를 기준으로 합니다. 우리가 읽은 문서에서 답을 찾지 못한 항목은 칸에 그렇게 적었습니다.
| Claude Code 샌드박스 | Codex CLI 샌드박스 | Gemini CLI 샌드박스 | ai-jail | |
|---|---|---|---|---|
| 에이전트 전체를 감싸는 래퍼가 더해 주는 것 | ||||
| 벽 안에 있는 것 | Bash, PowerShell, Monitor 명령과 그 자식 프로세스. claude 프로세스와 파일 도구, MCP 서버, 훅은 바깥에 있습니다. | 에이전트가 실행하는 명령. codex 프로세스는 바깥에 있습니다. 문서에 따르면 로컬과 원격 MCP 서버는 별도 프로세스나 전송 방식을 쓰므로 역시 바깥에 있습니다. | CLI 프로세스 전체. security.toolSandboxing을 쓰면 셸과 쓰기 도구만. | 프로세스 트리 전체. 에이전트와 파일 도구, MCP 서버, 훅, 모든 명령이 들어갑니다. |
| 기본으로 켜져 있는가 | 아니요. /sandbox나 sandbox.enabled로 켭니다. 의존성이 없으면 경고만 하고 명령을 샌드박스 없이 실행합니다. sandbox.failIfUnavailable을 설정하면 그러지 않습니다. | 네. workspace-write가 기본 모드입니다. | -s, GEMINI_SANDBOX, tools.sandbox 중 하나로 켭니다. | ai-jail을 거쳐 에이전트를 시작하면 항상 켜져 있습니다. 설정이 잘못되었으면 시작을 거부합니다. |
샌드박스 안의 코드가 기본 설정에서 ~/.ssh를 읽을 수 있는가 | 네. 문서에 따르면 기본 설정에서는 ~/.aws/credentials, ~/.ssh/ 같은 자격 증명 파일을 여전히 읽을 수 있습니다. 거부 규칙은 옵트인입니다. | Linux에서는 네. 파일시스템 전체가 읽기 전용으로 마운트됩니다. 권한 프로파일에 **/.env* 같은 경로에 대한 deny 규칙을 추가할 수 있고, OpenAI가 제공하는 강화 설정에는 이미 들어 있습니다. macOS 기본값은 문서에 없음. | macOS 기본 프로파일인 permissive-open은 파일 읽기를 폭넓게 허용합니다. 더 엄격한 프로파일은 옵트인입니다. | 아니요. 에이전트는 새로 만든 빈 홈 디렉터리를 받습니다. --ssh는 옵트인입니다. |
| 환경 변수 | 샌드박스 안의 명령은 기본적으로 부모 환경을 자격 증명까지 그대로 물려받습니다. sandbox.credentials로 거부하거나 마스킹할 수 있습니다. | 문서에 없음 | 문서에 없음 | 터미널, 로케일, 툴체인 변수로 이루어진 최소한의 허용 목록에, 실행한 하네스 자신의 API 키가 로그인과 함께 기본으로 복사됩니다. --no-agent-state로 막을 수 있습니다. 다른 변수는 --env에 이름을 지정해 추가합니다. |
| 모델이 쓸 수 있는 탈출구 | 모델이 dangerouslyDisableSandbox로 명령을 다시 시도할 수 있고, 이때는 일반 권한 확인 절차를 거칩니다. allowUnsandboxedCommands: false로 끌 수 있습니다. | on-request 정책에서는 워크스페이스 바깥을 수정하거나 네트워크를 쓸 때 에이전트가 샌드박스를 벗어나도 되는지 묻습니다. | 문서에 없음 | 없음. 정책은 에이전트가 시작되기 전에 내가 정하고, 프로젝트의 .ai-jail 파일은 정책을 더 조일 수만 있고 열 수는 없습니다. |
| 모든 에이전트에서 동작하는가 | Claude Code 전용 | Codex 전용 | Gemini CLI 전용 | 어떤 명령이든 됩니다. 정책 파일 하나를 모든 에이전트에 씁니다. |
| 네트워크 모델 | 도메인별 허용 목록이 있는 프록시. 새 도메인이 나오면 프롬프트로 묻고, 명령마다 승인은 따로 받습니다. 문서는 프록시가 클라이언트가 보낸 호스트 이름을 그대로 믿기 때문에 도메인 프런팅으로 우회할 수 있다고 밝힙니다. | workspace-write에서는 기본으로 꺼져 있습니다. 설정 하나로 켜고, 선택 사항인 프록시로 도메인별 허용·거부 규칙을 추가합니다. 문서는 프록시가 MCP 서버 연결과 웹 검색, 브라우저는 필터링하지 않는다고 밝힙니다. | 기본 프로파일은 네트워크를 허용합니다. 더 엄격한 프로파일과 프록시 프로파일은 옵트인입니다. | 세 가지 모드가 있습니다. 기본은 닫힘이고, 예외는 두 플랫폼 모두에서 알려진 에이전트 자신의 API 호스트, 그리고 Linux에서 툴체인이 켜져 있을 때 github.com을 포함한 고정된 패키지 레지스트리 목록이라서 HTTPS로 git clone이 됩니다. --no-network는 둘 다 닫습니다. --allow-host는 호스트와 그 서브도메인을 더하고, Linux에서는 네트워크 네임스페이스가, macOS에서는 seatbelt 엔드포인트 규칙이 이를 강제하며, 프록시는 이름을 한 번만 해석해서 검사한 주소로만 연결합니다. --network는 전부 엽니다. 필터는 TCP 전용이고 경로별 규칙이 없으며 묻지도 않습니다. 목록에 없는 호스트는 거부되고 --audit-log가 그 시도를 기록합니다. 허용된 호스트는 통째로 신뢰됩니다. Linux에서는 --forward-port가 호스트 루프백의 포트 하나를 샌드박스 안으로 중계하는데, 무엇이 지나가는지에 대한 규칙은 없습니다. |
| 내장 샌드박스가 더 잘하는 것 | ||||
| 명령별 승인 | 있음. 권한 모드, plan 모드, 분류기 모델, 조직 관리 정책. | 있음. 승인 정책, 범주별 규칙, 선택 사항인 리뷰어 에이전트. | 문서에 없음 | 없음. ai-jail은 개별 명령을 보지 않고 묻지도 않습니다. |
| 프로젝트 안의 보호 경로 | 있음. .git/hooks, .git/config, .claude 설정, .mcp.json, 셸 rc 파일 등이 읽기 전용으로 유지됩니다. | 있음. 쓰기 가능한 루트 아래의 .git, .agents, .codex는 읽기 전용입니다. | 문서에 없음 | 내장된 것은 없음. .git/까지 포함해 프로젝트 전체에 쓸 수 있고, 호스트 쪽 git은 거기서 찾은 것을 신뢰합니다. 경로를 마스킹하거나 거부하려면 --mask와 deny_paths를 직접 지정합니다. .git/이 왜 중요한지. |
| 시크릿을 에이전트에게 숨긴 채로 사용하기 | 자격 증명 마스킹을 쓰면 프록시에서 실제 시크릿을 주입할 수 있습니다. 실험적 설정이 필요합니다. | 문서에 없음 | 문서에 없음 | 됩니다. 2.2부터 --secret KEY=host로 가능합니다. 샌드박스에는 플레이스홀더만 있고, 프록시가 그 호스트 하나로 가는 요청에만 실제 값을 넣습니다. 그 호스트에 대해 프록시로 평문 HTTP를 보내는 클라이언트만 해당하고, HTTPS 터널은 건드리지 않습니다. 마스킹된 파일은 여전히 빈 파일입니다. |
| 플랫폼 | macOS, Linux, WSL2. 네이티브 Windows와 WSL1은 안 됩니다. | macOS, Linux, WSL2, 네이티브 Windows. | macOS Seatbelt, Docker 또는 Podman, gVisor, LXC(실험적), 네이티브 Windows. | Linux와 macOS. Windows에서는 WSL2만 됩니다. |
| 설치 | 에이전트에 포함. Linux에서는 bubblewrap과 socat이 필요합니다. | 에이전트에 포함. | 에이전트에 포함. 컨테이너 백엔드에는 Docker나 Podman이 필요합니다. | 별도 바이너리. Linux에서는 bubblewrap이 필요합니다. |
출처: Claude Code 샌드박싱, Claude Code 샌드박스 환경, Codex 승인과 보안, Codex 권한, Codex Linux 샌드박스, Gemini CLI 샌드박스, Antigravity 터미널 샌드박스, Antigravity 권한, nono 보안 모델, zerobox README.
다른 에이전트, 카드 하나씩
둘 다 쓰세요
알려진 에이전트는 아무것도 열 필요가 없습니다. 로그인은 기본으로 마운트되고, 필터링 프록시는 모델의 API 호스트와 Linux의 패키지 레지스트리를 통과시킵니다. 도구에 더 필요하면 --allow-host로 호스트를 더하거나 네트워크 전체를 여세요.
cd ~/Projects/my-appai-jail claudeai-jail --network claudeai-jail은 알려진 에이전트 자신의 API 호스트를 알고 있어서 기본으로 허용하고, Linux에서는 패키지 레지스트리도 허용합니다. 명시적인 --allow-host 목록은 그 기본값에 더해지므로 API 호스트는 계속 허용됩니다. 로그인은 기본으로 마운트되고, --no-agent-state를 주면 로그아웃 상태로 실행됩니다. 모든 플래그는 설정 페이지에 있습니다.
↔ 옆으로 밀어 전체 다이어그램을 확인하세요
에이전트 자체 검사가 계속 하는 일
권한 확인 프롬프트, 허용·거부 규칙, plan 모드는 에이전트 프로그램에 속한 기능이라 감옥 안에서도 바깥과 똑같이 동작합니다. 내가 승인하지 않았을 명령을 여기서 걸러 냅니다.
ai-jail이 그 아래에서 보장하는 것
내가 무엇을 승인하든 에이전트와 MCP 서버, 훅은 홈 디렉터리와 키, 셸에 있는 토큰을 볼 수 없습니다. 유일한 예외는 에이전트 자신의 로그인과 API 키로, 로그인된 상태로 시작하도록 기본으로 마운트됩니다. 에이전트가 읽을 수 있는 것은 자신의 API 호스트와 허용한 호스트로는 여전히 보낼 수 있으니 프로젝트 안의 시크릿은 마스킹하세요.
Docker, 개발 컨테이너, 가상 머신
이들도 좋은 답이고, 가상 머신은 더 강한 답입니다. 차이는 무엇을 직접 빌드하고 최신으로 관리해야 하느냐에 있습니다.
| 얻는 것 | 치르는 비용 | |
|---|---|---|
| Docker 컨테이너 | 전용 파일시스템, 프로세스 목록, 네트워크. 에이전트는 내가 마운트한 것만 봅니다. | 빌드하고 유지보수할 이미지가 생기고, 툴체인을 한 번 더 설치해야 합니다. Docker 소켓을 마운트하면 컨테이너는 호스트에서 root와 동등해집니다. |
| 개발 컨테이너 | 컨테이너와 같은 격리를, 에디터가 이해하고 팀이 공유할 수 있는 파일 하나로 기술합니다. | 이미지 관리 부담은 같고, 이 형식을 이해하는 에디터나 도구가 추가로 필요합니다. |
| 가상 머신 | 전용 커널. 여기 나온 것 중 가장 강한 경계이고, 악의적이라고 판단되는 코드에 맞는 선택입니다. | 가장 무거운 선택지입니다. 게스트 시스템을 설치하고 업데이트하고 메모리를 떼어 주고 프로젝트를 복사해 넣어야 합니다. |
| ai-jail | 명령 하나를 감싸는 샌드박스. 내 컴퓨터에 이미 있는 컴파일러와 런타임을 씁니다. 이미지도 데몬도 root도 필요 없습니다. | 호스트와 커널을 공유하므로 커널이나 드라이버 익스플로잇은 경계 밖에 있습니다. 가상 머신보다 약합니다. |
ai-jail 문서는 스스로를 일회용 VM을 대체하지 못하는 유용한 계층 하나라고 설명합니다. 위협 모델 읽기.
평가자를 위해: 다른 래퍼와 플랫폼
오픈 소스 래퍼 둘과 런타임 플랫폼 하나를 출처와 함께 정리했습니다. 대안을 저울질하는 분을 위한 내용입니다.
래퍼와 플랫폼 상세 정보 보기
에이전트 런타임 플랫폼
NVIDIA OpenShell은 다른 범주입니다. 상시 실행되는 게이트웨이가 에이전트마다 컨테이너나 MicroVM을 주고 네트워크 앞에 정책 엔진을 둡니다. ai-jail은 명령 하나를 감싸고 그 명령과 함께 종료되는 프로세스 하나입니다. 이 내용은 이 글을 쓰는 시점, 아직 1.0 릴리스 전인 OpenShell 문서를 따릅니다.
| OpenShell | ai-jail | |
|---|---|---|
| 샌드박스를 실행하는 것 | Docker, Podman, Kubernetes, KVM 위에서 도는 게이트웨이 데몬. 에이전트는 번들된 컨테이너 이미지 안에서 삽니다. | 바이너리 하나뿐입니다. 에이전트는 내 컴퓨터에 이미 있는 컴파일러와 런타임으로 프로젝트를 다룹니다. |
| 네트워크 | 기본은 거부. 규칙은 프로그램, 호스트, 포트를 기준으로 맞추고, 메서드, 경로, MCP 도구 검사는 선택입니다. 거부된 엔드포인트는 운영자 쪽에서 승인할 수 있습니다. | 꺼짐, 호스트별 필터링, 열림. 필터는 네임스페이스 울타리와 CONNECT 프록시입니다. 호스트와 포트는 보지만 내용은 보지 않고, 허용된 호스트는 통째로 신뢰됩니다. --forward-port로 중계한 호스트 루프백 포트 역시 아무 규칙 없이 통째로 신뢰됩니다. |
| 자격 증명 | 게이트웨이가 중개해서 요청마다 주입하고, 샌드박스 디스크에는 쓰지 않습니다. | 환경에 그대로 놓입니다. 하네스 자신의 로그인은 기본으로 읽기·쓰기 마운트되고, --env나 --env-from-file로 넘긴 것은 안에 있는 모든 것이 볼 수 있습니다. --no-agent-state를 주면 로그아웃 상태로 실행됩니다. 도구 자격 증명(--github, --aws, --kube, --gcloud, --docker-config)은 옵트인 읽기 전용 마운트이며, 문서는 읽기 전용이 사용까지 막지는 못한다고 밝힙니다. |
| 격리의 상한 | MicroVM 드라이버는 진짜 가상 머신 경계를 주고, 샌드박스는 멈췄다가 다시 시작해도 작업 공간을 유지합니다. | 호스트와 커널을 공유하고 설계상 일회성입니다. 악의적인 코드에는 일회용 VM을 쓰라고 자체 문서에 적혀 있습니다. |
| macOS | Docker Desktop의 Linux VM 안에서 실행됩니다. macOS 호스트는 정책 바깥입니다. | 호스트에서 생성하는 네이티브 seatbelt 프로파일. |
| 텔레메트리와 안정성 | 익명 텔레메트리가 기본으로 켜져 있고 끌 수 있습니다. 정책 형식은 아직 바뀌는 중입니다. | 텔레메트리가 없습니다. 새 버전은 이전 버전이 쓴 설정을 계속 읽고, 테스트가 이를 강제합니다. 2026년 9월에 저장소에 공개된 독립적인 소스 감사 두 건이 2.4.0의 수정으로 이어졌습니다. |
ai-jail 저장소의 비교 문서 docs/openshell-comparison.md는 양방향으로 쓰였고, 호스트 허용 목록은 여기서 나왔습니다.
함께 쓸 때 나오는 질문
에이전트 자체 샌드박스와 프롬프트는 꺼야 하나요?
프롬프트와 규칙은 그대로 두세요. 이들은 명령을 하나씩 검토하는데, ai-jail은 그 일을 하지 않습니다. Linux에서 에이전트의 OS 샌드박스는 사정이 다릅니다. ai-jail은 중첩된 bubblewrap 샌드박스에 필요한 시스템 콜을 막고, 문서에도 이 조합이 동작한다는 말이 없습니다. 에이전트가 감옥 안에서 자기 샌드박스를 쓸 수 없다고 알려도 감옥은 그대로 있습니다.
ai-jail이 Docker보다 안전한가요?
둘은 같은 부류의 경계입니다. 둘 다 호스트와 커널을 공유하고 가상 머신이 아닙니다. ai-jail은 전부 닫힌 상태에서 시작하고 이미지, 데몬, root가 필요 없습니다. 컨테이너는 내가 지정한 것을 마운트하며, Docker 소켓을 마운트하면 호스트에서 root와 동등해집니다. 악의적이라고 판단되는 코드에는 일회용 VM을 쓰세요.
호스트 허용 목록은 에이전트 자체의 것과 어떻게 다른가요?
에이전트의 프록시는 샌드박스 안의 프로그램이 쓰기로 선택해야 하는 것입니다. ai-jail에서는 커널이 울타리입니다. Linux에서는 샌드박스가 프록시만 유일한 출구인 전용 네트워크 네임스페이스를 유지하고, macOS에서는 seatbelt 규칙이 프록시 포트로 나가는 트래픽만 허용하므로,
http_proxy를 무시하는 프로그램은 어디에도 닿지 못합니다. UDP는 다루지 않아서 Linux에서는 샌드박스 안의 DNS가 실패하고 macOS에서는 시스템 리졸버에 울타리가 없습니다. 연결 내용을 검사하지 않으므로 허용된 호스트는 통째로 신뢰됩니다. --network나 --browser와는 함께 쓸 수 없습니다.Claude Code만 쓰는데 그래도 ai-jail이 필요한가요?
이 글을 쓰는 시점에 선택지는 세 가지입니다. 내장 샌드박스는 셸 명령을 막아 줍니다. Anthropic의
@anthropic-ai/sandbox-runtime은 베타 리서치 프리뷰이고 프로세스 전체를 감쌉니다. ai-jail도 프로세스 전체를 감싸며, 홈 디렉터리와 환경 변수를 닫은 상태에서 시작하고, 나중에 써 볼 다른 에이전트에도 같은 정책을 씁니다. Anthropic의 샌드박스 환경 비교를 참고하세요.에이전트를 철창 안에 넣으세요
ai-jail은 바이너리 하나입니다. 데몬도 root 권한도 필요 없습니다. 평소 실행하던 명령 앞에 단어 하나만 붙이면 됩니다.
brew tap akitaonrails/tap && brew install ai-jailai-jail claude