승인 창 대신 경계를 긋는다 — Claude Code 샌드박스 읽기

승인 창을 반복해서 누르면 보안이 오히려 약해질 수 있다

Claude Code를 쓰다 보면 파일을 고치거나 명령을 실행할 때마다 허용하겠느냐는 창이 뜬다. 기본적으로 읽기 전용(read-only) 권한 모델로 돌아가서, echo나 cat처럼 안전하다고 분류된 명령만 자동 허용하고 대다수 작업에는 승인을 요구하기 때문이다. 저자들에 따르면 승인 창이 반복되면 개발이 느려지고, 내용을 살피지 않고 누르는 승인 피로(approval fatigue) 탓에 오히려 덜 안전해질 수 있다.

반대로 코드베이스와 파일에 넓은 접근 권한을 주면 프롬프트 인젝션(prompt injection) 위험이 커진다. 프롬프트 인젝션은 외부 문서나 데이터에 숨겨진 악성 지시를 모델이 사용자의 명령으로 착각해 따르는 공격이다. 예를 들어 프로젝트 README에 ~/.ssh 디렉터리를 외부 서버로 보내라는 문장이 숨어 있을 때, Claude가 이를 지시로 여겨 실행할 수 있다.

Anthropic의 해법은 행동마다 허락을 구하는 대신 Claude가 자유롭게 일할 경계를 미리 긋는 샌드박싱(sandboxing)이다. 같은 날 발표된 두 기능은 로컬의 샌드박스 bash 도구와 클라우드에서 도는 웹 버전(Claude Code on the web)이다. 원문은 /sandbox 실행만 안내하므로 사용자가 직접 켜는 선택(opt-in) 기능으로 읽힌다. Anthropic은 내부 사용에서 승인 창이 84% 줄었다고 하는데, 계산 기준은 원문에 없다.

이 글은 2025년 10월 20일 Anthropic의 David Dworken과 Oliver Weller-Davies가 발표한 글을 읽고 그 시점의 샌드박스를 설명한다. 현재 동작은 따로 확인하지 않으며, 효과와 안전 서술은 모두 Anthropic의 설명이고 원문에 독립 측정은 나오지 않는다. 원문에 없는 용어 풀이·비유·예시는 이 글이 붙였다.

파일시스템과 네트워크 경계가 둘 다 있어야 격리가 성립한다

저자들은 운영체제(OS) 수준 기능으로 파일시스템 격리와 네트워크 격리라는 두 경계를 함께 세워야 샌드박싱이 효과적이라고 설명한다. 파일시스템 격리(filesystem isolation)는 지정된 디렉터리만 접근·수정하게 해, 감염된 Claude가 민감한 시스템 파일을 고치지 못하게 한다. 네트워크 격리(network isolation)는 승인된 서버로만 연결하게 해 민감한 정보 유출이나 악성코드 다운로드를 막는다.

네트워크 경계는 프록시(proxy), 즉 중간에서 요청을 대신 받아 허용 여부를 정하는 프로그램으로 세운다(문지기에 빗댄 풀이는 이 글의 것이다). 저자들에 따르면 두 경계 중 하나라도 빠지면 격리가 깨진다. 네트워크 격리가 없으면 앞 절의 README 예시처럼 감염된 에이전트가 ~/.ssh 키 같은 민감한 파일을 외부로 빼낼(exfiltrate) 수 있다. 반대로 파일시스템 격리가 없으면 감염된 에이전트가 샌드박스를 쉽게 탈출해 네트워크 접근 권한까지 얻을 수 있다.

두 경계가 있어도 읽기와 허용 도메인 유출은 원문이 닫는다고 하지 않았다(이 글의 독해다).

샌드박스 bash 도구는 OS 기능과 프록시로 파일과 네트워크를 통제한다

Anthropic은 새 샌드박스 런타임으로 Claude Code의 bash 도구(bash tool)를 가둔다(에이전트 루프는 Building effective agents 읽기 참고). 이 런타임은 컨테이너(container)를 띄우고 관리하는 부담 없이, OS 자체 격리 도구인 Linux bubblewrap과 macOS seatbelt를 쓴다. OS가 직접 제약하므로 Claude Code의 직접 상호작용뿐 아니라 명령이 띄운 스크립트·프로그램·하위 프로세스(subprocess)까지 같은 경계에 갇힌다.

구현 설명에서 파일시스템 경계는 현재 작업 디렉터리(current working directory)의 읽기와 쓰기를 허용하고 그 밖의 파일 수정을 막는다. 경계 밖 자원에 접근하려 하면 즉시 알림이 떠 허용 여부를 고를 수 있고, 허용·차단할 경로와 도메인은 설정으로 바꿀 수 있다. 다만 앞의 일반 정의는 지정 디렉터리만 '접근 또는 수정'한다고 적은 반면 구현 설명은 작업 디렉터리 밖 '수정 차단'만 적어, 밖의 파일 읽기까지 막는지는 확정할 수 없다. 만약 읽기를 막지 않는다면 감염된 Claude가 ~/.ssh 키를 훔치지 못한다는 주장은 네트워크 경계 하나에 기대는 셈이다(이 글의 독해다).

네트워크 경계는 샌드박스 밖 프록시와 연결된 유닉스 도메인 소켓(unix domain socket)으로만 인터넷에 나가게 한다. 한 컴퓨터 안의 두 프로그램을 파일 경로로 잇는 파이프여서, 자체 네트워크를 끊고 모든 트래픽이 프록시를 거치게 한 구조로 읽힌다(이 글의 독해다). 프록시는 도메인을 제한하고 새 도메인은 사용자 확인을 받으며, 사용자가 프록시를 고쳐 나가는 트래픽에 임의 규칙을 강제할 수도 있다. Anthropic은 이로써 프롬프트 인젝션이 성공해도 격리되어 SSH 키를 훔치거나 공격자 서버로 연락(phone home)할 수 없다고 본다.

이 샌드박스 런타임은 연구 프리뷰(research preview) 베타로 제공되며, Claude Code에서는 /sandbox를 실행해 시작한다. Anthropic은 이 런타임을 오픈소스 연구 프리뷰로도 공개했고, 임의의 프로세스와 에이전트, MCP 서버도 샌드박스에 넣을 수 있다고 밝힌다. MCP는 MCP 명세 읽기에서 다뤘다.

웹 버전은 민감한 자격 증명을 샌드박스 밖에 둔다

웹 버전(Claude Code on the web)은 로컬이 아니라 클라우드의 격리된 샌드박스에서 각 세션을 실행한다. 저자들은 Claude가 그 샌드박스 안 서버에 전체 접근 권한(full access)을 가지면서도 안전하게 돌아간다고 설명한다. 여기서 풀 문제는 git 자격 증명(git credentials)이나 서명 키(signing keys) 같은 민감한 자격 증명을 어디에 둘 것인가다. 이 git 프록시가 로컬 /sandbox에도 있는지는 원문에 나오지 않는다.

저자들의 설계에서 민감한 자격 증명은 결코 Claude Code가 도는 샌드박스 안에 두지 않는다. 대신 내부 git 클라이언트는 범위 제한 자격 증명(scoped credential)으로 맞춤형(custom) 프록시 서비스에 인증한다. 민감한 자격 증명을 샌드박스 안에 두지 않는다고 했으므로, 진짜 토큰을 쥔 이 프록시는 샌드박스 밖에 놓인다(이 글의 독해다).

프록시는 자격 증명과 요청 내용(예: 설정된 브랜치로만 푸시하는지)을 검증한 뒤 올바른 인증 토큰을 붙여 GitHub로 보낸다. 그림 캡션에는 프록시가 인증 토큰·브랜치 이름·대상 저장소(repository destinations)를 검증해 허용 밖 푸시를 막는다고 적혔다. 원문은 이 설계로 샌드박스 안 코드가 감염돼도 사용자가 추가 피해를 입지 않는다고 설명한다(내부에 진짜 토큰이 없다는 점은 이 글의 풀이다). 단, 범위 제한 자격 증명은 내부에 있어 감염된 코드가 쓸 수 있고, 설정된 브랜치로 푸시하는 내용까지 검사하는지는 알 수 없다.

원문이 답하지 않는 것

원문 발표 글만으로는 다음 질문에 답할 수 없다.

1. 알려진 샌드박스 탈출 경로와 한계, 그리고 위협 모델에서 제외한 범위.
2. 작업 디렉터리 밖 파일의 읽기 차단 여부(앞의 일반 정의는 '접근 또는 수정'을, 구현 설명은 '수정 차단'만 적어 두 문장이 다르다).
3. 로컬 기본 프록시가 도메인 외에 전송 내용까지 검사하는지 여부와 DNS 처리 방식(그림 캡션은 '안전한 작업 자동 허용·악성 작업 차단'을 말하지만 본문의 네트워크 쪽 메커니즘은 도메인 제한과 새 도메인 확인뿐이고 악성 판별 기준도 없어, 도메인 대조만으로는 허용 도메인 유출을 막지 못한다는 점은 이 글의 독해다).
4. bash 도구 외에 Claude Code 자체 파일 도구들도 샌드박스 안에서 돌아가는지, 웹의 git 프록시가 로컬 /sandbox에도 있는지 여부.
5. 기본 허용 도메인 목록과 /sandbox 실행 시 켜지는 세부 항목·질문·설정 키(/sandbox 자체의 베타 여부 포함).
6. 샌드박스 안 프로세스가 유닉스 도메인 소켓 프록시를 거치지 않고 다른 경로로 우회할 수 있는지 여부.
7. 웹 버전 샌드박스의 외부 네트워크(outbound) 통신 정책.
8. 쓰기 가능한 현재 작업 디렉터리 안에 둔 샌드박스·실행 설정이나 훅(hook)을 내부 프로세스가 고칠 수 있는지 여부.
9. 컨테이너나 가상머신(VM)과 비교한 격리 강도(원문은 컨테이너 구동·관리 부담이 없다는 점만 언급한다).
10. 경계 밖 접근이나 새 도메인 승인 창이 뜨는 빈도와 프롬프트 인젝션이 승인 창을 띄웠을 때 사용자에게 보이는 화면(새 도메인마다 창이 뜨면 승인 피로가 네트워크 경계에서 다시 나타날 수 있다는 점은 이 글의 추론이다), 그리고 승인 창 84% 감소의 계산 기준(작업·기간·분모).

그 밖에 Windows 지원 여부, 독립 보안 감사 여부, 범위 제한 자격 증명의 구체적 범위·유효기간·발급·폐기 방식도 다루지 않는다.

정리

Anthropic의 Claude Code 샌드박싱은 행동마다 승인을 묻는 대신, 파일시스템과 네트워크 경계를 미리 그어 에이전트가 자율적으로 일하게 하는 구조다. 로컬 샌드박스 bash 도구는 bubblewrap·seatbelt로 작업 디렉터리 밖 수정을 막고 유닉스 도메인 소켓 너머의 프록시로만 통신하게 한다. 클라우드 웹 버전은 민감한 자격 증명을 샌드박스 안에 두지 않고 맞춤형 git 프록시가 설정된 브랜치 푸시를 검증해 추가 피해를 줄인다고 Anthropic은 설명한다. 로컬은 /sandbox로, 웹은 claude.com/code에서 써 볼 수 있고, 오픈소스 샌드박스 런타임은 다른 에이전트에도 쓸 수 있다.

---

참고

• Beyond permission prompts: making Claude Code more secure and autonomous — Anthropic (2025-10-20)
• 원문이 가리키는 곳(이 글은 열어 보지 않았다): Claude Code 샌드박싱 문서, sandbox-runtime 저장소, Claude Code on the web 발표 글 — 이 문서들이 기본 허용 도메인·Windows·DNS·위협 모델에 답할 수 있다.