Anthropic Claude 에이전트 보안: sandbox와 egress control 설계

 

Claude 에이전트 보안 설계: Anthropic이 말한 샌드박스와 egress control

인간 승인만으로 부족한 코딩 에이전트 보안을 실행 환경 경계로 읽기

 

Claude 에이전트 보안 설계: Anthropic이 공개한 경계

 

Anthropic Claude 에이전트 보안 sandbox egress control의 초점은 모델에게 조심하라고 말하는 데서 끝나지 않고, 에이전트가 실제로 접근할 파일, 네트워크, 실행 환경을 좁히는 데 있습니다.

Claude Code를 쓰다 보면 결국 같은 질문으로 돌아옵니다. 코딩 에이전트가 코드를 고치고, 테스트를 돌리고, 터미널 명령을 실행한다면 어디까지 믿어도 되는가입니다.

Anthropic Engineering은 2026년 5월 25일 `How we contain Claude across products`라는 공식 글에서 이 문제를 제품별로 풀어냈습니다. claude.ai, Claude Code, Claude Cowork는 모두 Claude라는 이름을 쓰지만, 실제 보안 경계는 꽤 다릅니다.

제가 보기에는 이번 공개에서 볼 부분은 제품 소개가 아니라 운영 기준입니다. 에이전트 보안은 "승인 버튼을 잘 누르자" 수준을 넘어 sandbox, VM, filesystem boundary, egress control을 어디까지 좁힐 것인가의 문제에 가까워졌습니다.

Anthropic Claude 에이전트 보안 sandbox egress control을 검색한 독자라면, 공식 글의 제품별 차이보다 내 개발 환경에서 무엇을 막고 어떤 순서로 확인할지가 더 궁금할 겁니다. 그 기준으로 제품 차이, 위험 지점, 첫 테스트 순서를 다시 배치했습니다.

 

 

2025년부터 2026년까지 바뀐 흐름

 

Anthropic의 방향은 많은 permission prompt에 기대는 방식에서, 샌드박스와 auto mode classifier, 제품별 containment architecture를 함께 쓰는 방식으로 이동했습니다.

2025년 10월 Claude Code sandboxing 글, 2026년 3월 auto mode 글, 2026년 5월 제품군 containment 글을 이어서 보면 흐름이 보입니다. Anthropic은 코딩 에이전트의 자율성을 늘리면서도 피해 범위를 줄이는 쪽으로 설계를 옮겨 왔습니다.

날짜	변화	읽어야 할 포인트
2025-10-20	Claude Code sandboxing 소개	파일 시스템 경계와 네트워크 격리로 permission prompt 부담을 줄이는 방향
2026-03-25	Claude Code auto mode 설명	prompt-injection probe와 transcript classifier로 자동 실행 위험을 줄이려는 시도
2026-05-25	제품군 containment 비교 공개	claude.ai, Claude Code, Claude Cowork의 경계 설계를 한 번에 비교

여기서 볼 부분은 "승인 절차를 없애도 된다"가 아닙니다. 인간 승인이 피로해질 수 있으니, 승인 이전에 실행 환경 자체를 좁혀야 한다는 쪽에 가깝습니다.

Anthropic Claude 에이전트 보안 sandbox egress control이라는 긴 키워드가 결국 가리키는 것도 이 지점입니다. 모델이 맡는 일이 넓어질수록 보안 경계는 말이나 정책 문구보다 파일 시스템, 네트워크, VM 같은 운영 단위로 내려와야 합니다.

 

제품별 차이: 웹 실행, 로컬 에이전트, VM

 

claude.ai는 서버 측 격리 실행, Claude Code는 로컬 개발 환경을 고려한 OS-level sandbox, Claude Cowork는 VM과 파일 마운트 및 egress 제어가 핵심으로 설명됩니다.

세 제품의 차이를 한 문장으로 줄이면 이렇습니다. 같은 Claude라도 어디에서 실행되고 무엇에 접근하느냐에 따라 보안 설계가 달라집니다.

claude.ai의 code execution은 사용자 로컬 파일 시스템이 아니라 서버 측 isolated infrastructure 위에서 돌아가는 방식으로 설명됩니다. 공식 글은 gVisor container와 session별 ephemeral filesystem을 언급합니다. 웹에서 코드를 실행할 때 내 노트북 디스크 전체를 직접 만지는 구조는 아니라는 점을 봐야 합니다.

Claude Code는 성격이 다릅니다. 로컬 repository, shell, network에 접근해야 개발 도구로 쓸 수 있습니다. 그래서 Anthropic은 초기에는 read 허용, write/bash/network 승인 같은 permission 중심 방어를 두었고, 이후 macOS Seatbelt와 Linux bubblewrap 기반 OS-level sandbox를 설명했습니다.

Claude Cowork는 더 강한 격리 단위로 VM이 등장합니다. 파일 마운트 모드도 read-only, read-write, read-write-no-delete처럼 나뉩니다. 한국 사용자 입장에서는 이 차이가 꽤 현실적입니다. 개인 노트북에서 쓰는 Claude Code와 기업형 agent workflow를 같은 보안 기준으로 묶어 판단하면 빠지는 부분이 생깁니다.

 

 

왜 중요한가: 프롬프트 인젝션은 권한 문제이기도 하다

 

프롬프트 인젝션은 모델이 이상한 답을 하는 문제에 그치지 않습니다. 에이전트가 파일, 네트워크, shell, MCP 도구에 접근하면 잘못된 지시가 실제 명령 실행이나 데이터 유출로 이어질 수 있습니다.

일반 챗봇에서 프롬프트 인젝션은 대개 답변 품질 문제처럼 보입니다. 하지만 코딩 에이전트에서는 성격이 달라집니다. 모델이 `~/.aws/credentials` 같은 민감 파일을 읽고 외부 endpoint로 보내도록 유도된다면, 그것은 대화 실패가 아니라 운영 사고입니다.

Anthropic은 2026년 2월 내부 red-team exercise에서 사용자가 붙여 넣은 악성 prompt가 자격 증명 파일을 읽고 외부로 보내도록 유도한 사례를 공개했습니다. 이 수치는 Anthropic 공식 공개 맥락의 내부 실험값이지 독립 재현값은 아닙니다. 그래도 읽을 메시지는 분명합니다. 모델 계층 방어만으로는 부족합니다.

> 코딩 에이전트의 위험은 "무슨 말을 했는가"보다 "그 말이 어떤 권한으로 실행되는가"에서 커집니다.

Claude Code 보안 문서도 read-only 기본 권한, 명시적 승인, network request approval, trust verification 같은 항목을 나열합니다. 실제로 확인할 부분은 모델이 안전하다고 말하는지가 아니라, 작업 디렉터리, MCP 서버, 네트워크, secret mount가 어떤 경계 안에 있는지입니다.

 

첫 테스트 순서: 가짜 자격 증명부터 시작하기

 

첫 테스트는 disposable repository와 fake credentials에서 시작하고, 기본 read-only 동작, `/sandbox`, devcontainer, network egress, managed settings 순서로 좁게 확인하는 편이 안전합니다.

이 주제는 읽고 끝내기보다 작은 테스트로 확인하는 편이 낫습니다. 제가 권한다면 운영 repository가 아니라 버려도 되는 샘플 repository에서 시작하겠습니다.

1. 테스트용 repository를 만들고 실제 `.env`, `~/.ssh`, `~/.aws/credentials` 같은 host secret은 연결하지 않습니다.
2. Claude Code를 기본 permission mode로 실행해 read-only 동작과 edit/test/command 승인 흐름을 확인합니다.
3. Claude Code 안에서 `/sandbox`를 사용해 Claude가 자율적으로 작업할 파일 시스템과 네트워크 경계를 좁힙니다.
4. Dev Containers를 쓰는 팀은 `.devcontainer/devcontainer.json`에 `ghcr.io/anthropics/devcontainer-features/claude-code:1.0` feature를 추가해 container 내부에서 `claude`를 실행해 봅니다.
5. 제한된 네트워크에서는 `api.anthropic.com`, `claude.ai`, `platform.claude.com`, `downloads.claude.ai`, `raw.githubusercontent.com` 같은 required endpoint를 firewall/proxy 정책에서 검토합니다.
6. Teams/Enterprise 환경이라면 managed settings 배포 후 Claude Code를 재시작하고 `/permissions`로 실제 적용 권한을 확인합니다.

목표는 "한 번에 완전한 자동화"가 아닙니다. Anthropic Claude 에이전트 보안 sandbox egress control이 내 환경에서 어떤 실패를 만들고, 어떤 로그와 승인 절차를 남기는지 보는 일입니다.

다만 host secret을 container에 넓게 mount하면 devcontainer의 의미가 약해집니다. repository-scoped token이나 short-lived token을 쓰는 편이 낫고, 가짜 credential로 유출 테스트를 먼저 진행해야 합니다.

 

 

 

운영 모델: 어떤 권한을 누구에게 맡길 것인가

 

개발자는 작업 단위 권한을 확인하고, 플랫폼팀은 devcontainer와 proxy baseline을 관리하며, 보안팀은 bypass permission mode, MCP 서버, 로그 수집, egress 정책을 별도로 검토해야 합니다.

실무 도입에서 자주 빠지는 부분은 역할 분리입니다. Claude Code를 개인 도구로만 보면 개발자가 승인 버튼을 잘 누르면 된다고 생각하기 쉽습니다. 팀 도입에서는 기준을 더 넓게 잡아야 합니다.

개발자는 repository edit, test run, refactor, code review automation 같은 작업 단위에서 Claude가 무슨 파일과 명령에 접근하는지 확인해야 합니다. 플랫폼팀은 Dev Containers, GitHub Codespaces, corporate proxy, firewall baseline처럼 실행 환경의 기본값을 잡습니다. 보안팀은 MCP allowlist, cloud connector, bypass permission mode, OTLP 로그 export, egress policy를 별도로 봐야 합니다.

특히 `--dangerously-skip-permissions`나 `bypassPermissions` 계열 실행은 이름 그대로 신중하게 다룰 항목입니다. 공식 문서의 취지는 isolated container나 VM처럼 경계가 분명한 곳에서만 다루라는 쪽입니다. 관리자는 `permissions.disableBypassPermissionsMode`, `allowManagedPermissionRulesOnly`, `autoMode.environment` 같은 정책 항목을 검토할 수 있습니다.

한국 회사 환경에서는 프록시와 사내망 제약이 흔합니다. 그래서 Anthropic Claude 에이전트 보안 sandbox egress control을 논할 때도 "Claude가 접속 가능한가"만 보면 부족합니다. 어떤 경로로 접속하고, 실패 시 fail-open인지 fail-closed인지, 로그가 어디에 남는지를 같이 봐야 합니다.

 

egress control 체크: 도메인 허용만으로 충분하지 않은 이유

 

egress allowlist는 목적지 도메인만 보면 부족합니다. 허용된 도메인이 파일 업로드, 외부 fetch, 프록시, 계정 간 전송 기능을 제공하면 그 기능 자체가 유출 경로가 될 수 있습니다.

egress control은 이번 Anthropic 글에서 가장 실무적으로 읽히는 대목입니다. 보통은 "허용할 도메인 목록을 만들면 되지 않나"라고 생각하기 쉽습니다. 하지만 Anthropic이 공개한 Claude Cowork 사례는 그 방식의 한계를 보여줍니다.

허용된 도메인이 `api.anthropic.com` 같은 정상 목적지라도, 공격자가 자기 API key를 쓰게 만들거나 파일 업로드 기능을 이용하게 만들 수 있다면 이야기가 달라집니다. 도메인을 허용한다는 것은 그 도메인의 일부 기능이 capability grant처럼 작동할 수 있다는 뜻입니다.

그래서 실무 점검은 두 단계로 나누는 편이 낫습니다.

• 목적지 점검: Claude Code가 접근해야 하는 Anthropic endpoint, package registry, GitHub raw content, 사내 proxy를 확인합니다.
• 기능 점검: 허용된 endpoint가 upload, fetch, proxy, account transfer, webhook 같은 외부 전송 기능을 제공하는지 확인합니다.

다만 egress control이 완전한 방어막은 아닙니다. 목적은 피해 범위를 줄이고 이상 흐름을 관측 가능하게 만드는 데 있습니다. Anthropic Claude 에이전트 보안 sandbox egress control을 실무에 옮길 때는 allowlist 문서보다 실제 요청 로그와 차단 로그가 더 중요해집니다.

 

 

 

샌드박스가 있어도 미뤄야 할 조건

 

운영 DB, 배포 파이프라인, 고객 데이터, 광범위한 host secrets가 걸린 작업에서는 unattended 또는 bypass-style 실행을 피해야 합니다. auto mode와 devcontainer도 완전한 보안 보장으로 쓰면 안 됩니다.

Claude Code auto mode는 permission 피로를 줄이는 데 의미가 있습니다. Anthropic은 auto mode 글에서 benign command false positive와 overeager action false negative 수치를 공개했습니다. 다만 이 수치는 공식 글의 특정 실험 맥락이며, 모든 회사 환경에서 같은 보안 성능을 낸다는 뜻은 아닙니다.

건너뛰어야 할 조건은 비교적 명확합니다. 운영 데이터베이스, 고객 데이터, 배포 파이프라인, 공유 cloud infrastructure, 되돌리기 어려운 repository history가 걸려 있다면 unattended 실행을 먼저 열지 않는 편이 맞습니다. fake-data 테스트와 rollback 경로가 먼저입니다.

Devcontainer도 마찬가지입니다. container 내부에 host home directory, SSH key, cloud credential file을 넓게 mount한다면 격리 효과가 줄어듭니다. VM도 host와 guest를 분리하는 장점이 있지만, 보안팀의 endpoint visibility가 낮아질 수 있습니다.

제가 보기에는 여기서 실무 takeaway가 가장 분명합니다. 코딩 에이전트 운영은 모델 선택보다 권한 경계 설계가 먼저입니다. Anthropic Claude 에이전트 보안 sandbox egress control을 읽을 때도 "Claude가 얼마나 똑똑한가"보다 "Claude가 실패했을 때 어디까지 갈 수 있는가"를 먼저 물어야 합니다.

 

자주 묻는 질문

 

Q. Anthropic이 말한 Claude 에이전트 보안 설계는 무엇이 다른가요?
A. 모델 지시문이나 인간 승인만으로 막는 방식이 아니라, sandbox, VM, 파일 시스템 경계, egress control로 에이전트가 실제 접근할 범위를 줄이는 설계입니다.

Q. Claude Code auto mode는 어떤 보안 위험이 있나요?
A. auto mode는 승인 피로를 줄이기 위한 장치지만 모든 과잉 행동을 막는 보장은 아닙니다. 운영 DB, 배포 파이프라인, 고객 데이터 작업에서는 isolated container나 VM, fake-data 테스트, 사람 검토를 앞에 둬야 합니다.

Q. AI 에이전트 샌드박스는 왜 필요한가요?
A. 코딩 에이전트는 파일 읽기, 코드 수정, shell 실행, 네트워크 요청을 할 수 있기 때문입니다. 샌드박스는 프롬프트 인젝션이나 오작동이 생겨도 피해 범위를 작업 디렉터리와 허용된 네트워크 안으로 묶는 역할을 합니다.

Q. egress control은 단순 도메인 allowlist만으로 충분한가요?
A. 충분하지 않습니다. 허용된 도메인이 upload, fetch, proxy, webhook 같은 기능을 제공하면 그 기능이 유출 경로가 될 수 있으므로 목적지뿐 아니라 허용된 기능까지 점검해야 합니다.

Q. Claude Code를 팀에서 도입할 때 무엇부터 확인해야 하나요?
A. disposable repository와 fake credentials로 기본 permission 흐름을 확인한 뒤 `/sandbox`, `.devcontainer/devcontainer.json`, firewall/proxy egress, `/permissions` 기반 managed settings 적용 여부를 차례로 확인하는 순서가 안전합니다.

함께 읽으면 좋은 글

 

• Claude Code 2.1.149 업데이트: /usage로 MCP 비용과 에이전트 사용량을 보는 법 — AI UPDATES
• OpenAI Codex 요금표 변경: 토큰 기반 크레딧 계산법과 비용 체크포인트 — AI UPDATES
• Gemini Interactions API 변경: steps 스키마 전환 체크리스트 — AI UPDATES

참조 링크

 

• How we contain Claude across products — 2026-05-25 공식 업데이트 원문이며 claude.ai, Claude Code, Claude Cowork containment architecture의 1차 근거
• Claude Code auto mode: a safer way to skip permissions — auto mode, prompt-injection probe, transcript classifier, 수치 해석 한계의 근거
• Beyond permission prompts: making Claude Code more secure and autonomous — Claude Code sandboxing과 파일 시스템/네트워크 격리 흐름의 이전 공식 업데이트
• Security - Claude Code Docs — read-only 기본 권한, explicit permission, network approval, trust verification, MCP 보안 설명
• Development containers - Claude Code Docs — `.devcontainer/devcontainer.json`와 Claude Code devcontainer feature, secret mount 주의점의 근거
• Enterprise network configuration - Claude Code Docs — restricted/containerized environment의 proxy, firewall, egress allowlist 운영 근거
• Configure server-managed settings - Claude Code Docs — Teams/Enterprise 권한 정책, bypass disable, `/permissions` 확인 흐름의 근거
• Choose a permission mode - Claude Code Docs — permission mode와 bypass-style 실행 판단을 보조하는 공식 문서