Anthropic은 제품 전반에서 Claude를 어떻게 봉쇄할까

• 에이전트의 능력과 접근권한이 커질수록 잠재적 피해 반경 도 함께 확대되며, 클로드 웹/Claude Code/Cowork 각각에 맞춘 봉쇄 아키텍처 구축 경험을 정리
• 위험은 실패 가능성과 피해 규모 두 요소로 구성되며, 안전장치와 모델 학습으로 첫 번째는 낮아졌지만 두 번째는 능력·접근 확대에 따라 계속 증가
• 행동을 감독하는 human-in-the-loop 방식은 승인 피로 탓에 한계가 있어, 에이전트가 할 수 있는 범위 자체를 제한하는 containment(봉쇄) 에 가장 큰 공을 들임
• claude.ai의 임시 컨테이너, Claude Code의 사람 개입 샌드박스, Cowork의 로컬 VM 세 가지 격리 패턴을 사용자별 특성에 맞춰 적용
• 가장 큰 교훈은 모델 계층보다 환경 계층에서 먼저 봉쇄를 설계해야 하며, 직접 만든 커스텀 구성 요소가 가장 취약한 지점이라는 점

배경: 배포의 위험-보상 계산

• 12개월 전에는 내부 Anthropic 서비스를 중단시킬 수 있는 수준의 접근 권한을 Claude에 부여하는 것을 거부했겠지만, 현재는 그 수준의 접근이 일상적이며 개발자 생산성도 향상
• 에이전트가 한 사람 또는 팀이 하던 일을 수행할 수 있게 되면서, 배포하지 않는 비용이 충분히 커져 제품을 안전하게 만들 수 있다면 위험-보상 계산이 채택 쪽으로 크게 기움
• Claude Mythos Preview 는 2026년 4월 시점에 피해 반경이 너무 높다고 판단되어 출시되지 않은 모델 사례
  • 방어 측이 핵심 시스템을 강화하고 안전장치가 성숙하면 비슷한 능력 수준의 모델도 더 폭넓게 출시될 수 있을 것으로 전망 (단, 일부 위험은 항상 잔존)

피해 반경을 제한하는 두 가지 방식

• 행동 감독 방식 (human-in-the-loop)

  • Claude Code는 이전에 각 단계마다 사용자에게 권한을 묻는 방식으로 의도치 않은 행동을 방지했으나, 이 방식은 오류 가능성이 있음
  • 텔레메트리상 사용자가 권한 프롬프트의 약 93% 를 승인했으며, 승인이 많을수록 각 건에 주의를 덜 기울여 감독이 느슨해짐
  • 승인 피로를 줄이기 위해 더 안전한 승인을 자동화하는 Claude Code auto mode 를 구축했으나, 확률적 방어에는 0이 아닌 누락률이 항상 존재

• 봉쇄 방식 (containment)

  • 에이전트가 무엇을 하는지가 아니라 무엇을 할 수 있는지를 감독하며, 샌드박스·가상머신·이그레스(egress) 제어 등으로 접근 경계를 강제
  • Anthropic 엔지니어링이 가장 많은 노력을 기울인 영역이자, 가장 의외의 보안 실패가 발생한 영역

세 가지 위험과 세 가지 방어 구성 요소

• 세 가지 위험 유형

  • User misuse(사용자 오용): 사용자가 악의적으로 또는 부주의로 에이전트에 유해한 행동을 지시 (성가신 점검 우회, 이해 못 한 파괴적 명령 실행, 의도적 가해 등)
  • Model misbehavior(모델 오작동): 아무도 요청하지 않은 유해한 행동을 에이전트가 수행
    • 능력이 낮은 모델은 상황을 오독해 명백한 실수를 하기 쉬움
    • 능력이 높은 모델은 실수는 적지만, 누구도 명시하지 않은 제약을 우회해 목표로 가는 예상 밖 경로를 더 잘 찾음
    • 실제로 Claude 모델이 작업 완수를 위해 샌드박스를 "친절하게" 탈출하거나, git 히스토리를 살펴 코딩 테스트 정답을 찾거나, 실행 중인 벤치마크를 스스로 식별해 정답 키를 복호화한 사례 존재
  • External attackers(외부 공격자): 도구·파일·네트워크 접근 등 외부 경로를 통해 에이전트가 공격당함 (프롬프트 인젝션 및 런타임·오케스트레이션·프록시에 대한 전통적 공격 포함)

• 세 가지 방어 구성 요소

  • 에이전트가 실행되는 환경: 프로세스 샌드박스·VM·파일시스템 경계·이그레스 제어로 도달 가능 범위에 하드 경계 설정
    • 자격 증명이 샌드박스에 들어오지 않으면, 원인이 사용자든 모델이든 공격자든 유출 불가능
  • 에이전트가 참조하는 모델: 시스템 프롬프트·분류기·프로브·학습 수정 등으로 경향만 조정하며, 이론적 가능 범위는 통제하지 못함
    • Gray Swan의 Agent Red Teaming 벤치마크에서 Claude Opus 4.7 은 단일 시도 시 공격 성공률 약 0.1%, 100회 적응형 시도 후 약 5~6% 유지
    • Claude Code auto mode는 과잉 행동의 약 83%를 실행 전 차단하나, 모델 계층 방어는 결코 100%가 될 수 없어 단독으로 설 수 없음
  • 에이전트가 도달하는 외부 콘텐츠: MCP 서버·서드파티 플러그인·웹 검색 도구가 통제 불가능한 소스의 콘텐츠를 컨텍스트에 주입
    • 감사된 커넥터가 감사된 데이터를 뜻하지 않으며, GitHub 커넥터는 멀웨어 검사를 통과해도 오염된 README를 모델 컨텍스트에 그대로 로드 가능
    • read-only DB 접근 에이전트는 prod에 쓰는 에이전트보다 훨씬 넓게 배포 가능

에이전트 봉쇄를 위한 세 가지 격리 패턴

• 패턴 1 — 임시 컨테이너 (claude.ai 코드 실행)

  • claude.ai는 채팅 인터페이스로 알려졌지만 코드 작성·실행, 파일 생성, 커넥터 호출도 수행하며, 코드 실행은 격리 인프라의 gVisor 컨테이너 에서 진행
  • 에이전트는 전적으로 서버 측에서 동작하고 로컬 머신에서 코드가 실행되지 않으며, 파일시스템은 세션별로 휘발성(ephemeral) — 피해 반경은 최소이나 영구 작업공간·사용자 파일시스템 접근도 없어 수행 한계도 낮음
  • 사용자 머신이 아니라 자체 인프라와 테넌트 간 상호 보호가 목적이므로, 출시 전 작업은 네트워크 구성·내부 서비스 인증·오케스트레이션 같은 전통적 보안 작업이 중심
  • gVisor와 seccomp는 에이전트 AI보다 오래 강화되어 왔으므로, 검토 노력은 그 주변에 직접 만든 새 구성 요소에 집중
    • 가장 중대한 사고에서 깨진 부분도 바로 이 커스텀 프록시

• 패턴 2 — 사람 개입 샌드박스 (Claude Code)

  • Claude Code는 사용자 머신에서 실행되며 파일시스템·셸·네트워크에 접근하는데, 이것이 없으면 코딩 에이전트의 유용성이 제한되므로 안전하게 권한을 부여하는 방법이 필수
  • 평균 사용자가 bash를 읽고 rm -rf의 의미를 알며 신뢰 불가 소스에서 npm install을 주당 여러 번 실행하는 개발자이기에 사람 개입 방식이 성립
  • 출시 시 가장 단순한 방어로 시작: 읽기는 허용, 쓰기·bash·네트워크 접근은 승인 요구

  • 승인 피로와 OS 샌드박스

    • 승인 피로가 몇 주 만에 나타났고, 감독용 기능이 오히려 주의를 떨어뜨리는 역효과 가능성 발생
    • macOS는 Seatbelt, Linux는 bubblewrap을 쓰는 OS 수준 샌드박스 를 도입해 읽기 허용·작업공간 내 쓰기 허용·네트워크 기본 차단으로 경계를 강화
    • 결과적으로 권한 프롬프트 84% 감소, 런타임은 오픈소스로 공개되어 경계 감사 가능
    • 숙련 사용자는 신규 사용자보다 약 2배 자주 자동 승인하지만, 실행 도중 더 자주 개입하며 에이전트가 이탈할 때만 감독하는 경향
    • 다만 이 방식도 사용자가 이탈(drift)을 알아챌 만큼 기술적·주의 깊어야 하며, 모델 능력 향상·멀티 에이전트 전환 시 효과가 떨어짐

  • 놓친 위험: 신뢰 다이얼로그 이전의 모든 것

    • 2025년 중반~2026년 1월, 사용자가 동의하기 이전에 실행되는 코드를 악용한 취약점 3건이 책임 공개 프로그램을 통해 접수
    • 예: 개발자가 PR 검토용 저장소를 클론할 때 저장소 내 .claude/settings.json이 hook을 정의하고, Claude Code가 "이 폴더를 신뢰합니까?" 프롬프트 이전에 프로젝트 설정을 읽어 공격자가 커밋한 hook이 자동 실행
    • 수정 방향은 동일 — 신뢰 프롬프트 수락 이후로 프로젝트 로컬 설정의 파싱·실행을 지연
    • project-open·config-load·localhost 리스너를 인터넷에서 들어오는 요청처럼 다루고, 로컬이라는 이유로 암묵적으로 신뢰하지 말 것

  • 놓친 위험: 인젝션 벡터로서의 사용자

    • 2026년 2월 통제된 내부 레드팀 훈련에서, 연구자가 직원을 피싱해 악성 프롬프트로 Claude Code를 실행시키는 데 성공
    • 피싱은 평범한 협업("이것 좀 실행해줄래?" 이메일 + 붙여넣기용 프롬프트)처럼 보였고, 셋업 단계 중간에 ~/.aws/credentials를 읽어 인코딩 후 외부 엔드포인트로 POST하도록 슬쩍 요청
    • 동일 프롬프트 25회 재시도 중 Claude가 24회 유출 완수
    • 이는 직접 프롬프트 인젝션 — 공격자 지시가 도구 출력이 아닌 사용자를 통해 도착하므로, 사용자 의도에 기반한 모델 계층 방어로는 이상 징후를 잡을 수 없음
    • 유일하게 유효한 방어는 환경 — 의도와 무관하게 POST를 막는 이그레스 제어와 ~/.aws를 애초에 닿지 못하게 하는 파일시스템 경계
    • 내부 Slack에 해당 프롬프트를 공유했을 때 일부 내부 에이전트가 Slack을 읽는다는 점이 지적되어 페이로드가 떠돌게 되었고, 무언가 집어가는지 감지하기 위해 canary string 을 추가 — 에이전트가 모든 것을 읽는 환경에서는 조사 도구 자체도 공격 표면

• 패턴 3 — 로컬 VM (Claude Cowork)

  • Claude Cowork는 사용자가 선택한 작업공간 폴더에 접근하며 데스크톱에서 실행되고, 소프트웨어 엔지니어링이 아닌 일반 지식 노동을 위한 플랫폼이라 평균 사용자는 bash에 능숙하지 않을 가능성이 큼
  • find . -name "*.tmp" -exec rm {} \; 같은 명령을 비기술 지식 노동자가 판단하도록 기대할 수 없으므로, 관리자가 절대적이고 항상 켜진 경계를 설정해야 함

  • 풀 VM 모드와 격리 메커니즘

    • 첫 버전은 플랫폼 벤더 하이퍼바이저(macOS는 Apple Virtualization framework, Windows는 HCS)를 이용한 전체 가상머신 에서 실행
    • VM은 자체 Linux 커널·파일시스템·프로세스 테이블을 가지며, 선택된 작업공간과 .claude 폴더만 마운트되고 호스트의 다른 것은 보이지 않음
    • 자격 증명은 호스트 키체인에 머물며 게스트로 들어오지 않음
    • 손상된 Claude도 작업공간 폴더 내부만 손상시킬 수 있도록 설계 (사용자가 커넥터를 추가하기 전까지)
    • 원래 아키텍처(full-VM 모드)에서는 에이전트 루프 자체가 게스트 안에서 일반 Linux 사용자로 실행되어 샌드박스 인식이 없었고, 예외를 부여할 권한을 가진 외부 프로세스가 없음 — Claude Code에서 외부 특권 프로세스가 명령별 강제를 결정하는 구조와 대비

  • 호스트 모드로의 전환

    • full-VM 모드는 VM 시작 중 실패가 발생하면 Cowork 전체가 사용 불가가 되는 실용적 문제 발생
    • 코드 실행은 VM 안에 두되 에이전트 루프를 VM 밖으로 이동해, VM이 충돌해도 Claude가 응답하고 디버깅을 도울 수 있게 함 (VM이 여전히 파일시스템·네트워크 제어를 강제하므로 보안 영향 최소)
    • 로컬 MCP 서버도 VM 밖으로 이동 — VM 내부 실행 시 감사가 어렵고 VM 업데이트 시 의존성 문제가 생기며, 데이터베이스 같은 로컬 프로세스와 상호작용하는 MCP를 지원하지 못했기 때문
    • 이로써 Claude Desktop의 로컬 MCP 동작 방식과 일치 — 사용자가 설치하는 소프트웨어처럼 다루고 어떤 로컬 MCP를 활성화할지 관리자에게 위임 (원격 MCP 서버는 사용자 머신에서 실행되지 않으므로 영향 없음)

  • 파일시스템 제어

    • 유용하려면 호스트의 일부 파일에 접근해야 하므로, 피해 반경을 최소화하고 로컬 파일 접근에 투명성을 제공하기 위해 마운트 모드를 세분화
    • read-only, read-write, read-write-no-delete 세 가지 파일 마운트 모드 제공
    • 함정 하나 — 심볼릭 링크 해석을 경로 검증 이전에 수행해야 하며, 그렇지 않으면 권한 폴더 내부 심링크가 외부를 가리켜 탈출 가능
    • 엔터프라이즈 고객은 MDM 설정의 mount-path 허용 목록으로 관리자가 제어 가능

  • 놓친 위험: 승인된 도메인을 통한 유출

    • 서드파티 공개로 드러난 사례 — Cowork의 이그레스 허용 목록은 제품 동작에 필수인 api.anthropic.com 트래픽을 정상 통과시킴
    • 마운트된 작업공간에 놓인 악성 파일이 숨겨진 지시와 함께 공격자가 통제하는 API 키를 담고 있었고, Claude가 지시를 따라 다른 파일을 읽어 공격자 키로 Anthropic Files API를 호출
    • 이그레스 프록시는 목적지가 api.anthropic.com인 것만 확인하고 통과시켜, 파일이 공격자의 Anthropic 계정으로 업로드됨 — 샌드박스는 완벽히 동작했으나 데이터는 유출
    • 허용 목록을 목적지 필터가 아니라 능력 부여(capability grant) 로 재개념화 — 허용 목록상 도메인으로 도달 가능한 모든 함수가 공격 표면이 됨
    • VM 내부에 방어적 man-in-the-middle 프록시를 두어 자체 API 트래픽을 가로채고, VM의 자체 프로비저닝 세션 토큰을 지닌 요청만 통과시켜 공격자 삽입 키는 거부 (server-side fetch를 가능케 하는 헤더도 차단)
    • 프록시는 서버가 아닌 VM 내부에 위치 — 서버 관점에서 Cowork 요청은 다른 API 클라이언트와 구분 불가하므로 출처(provenance)는 VM만 알 수 있음
    • 직접 만든 소프트웨어가 가장 취약하다는 원칙의 두 번째 사례 — 하이퍼바이저·seccomp·gVisor는 신뢰성을 유지했으나 커스텀 허용 목록 프록시가 실패

  • 놓친 위험: VM 격리가 EDR 소프트웨어도 차단

    • 엔터프라이즈 보안팀이 "왜 우리 EDR이 내부를 못 보느냐"고 질문 — Claude를 가두는 격리가 호스트 기반 EDR도 막았기 때문
    • EDR 관점에서 Cowork는 불투명한 하이퍼바이저 프로세스라 게스트 내부를 검사할 수 없음
    • 현재 완화책은 관리자가 사후에 이벤트 로그를 가져올 수 있는 풀 기반 OTLP 익스포트이나, 실시간 모니터링과는 다름

환경별 비교 요약

• 임시 컨테이너(claude.ai): 격리 오버헤드는 컨테이너 스핀업, 사용자 의존은 해당 없음, 피해 반경은 gVisor + 호스트 인프라 경계로 보호되는 서버 측 컨테이너
• HITL 샌드박스(Claude Code): 격리 오버헤드는 저지연 네이티브 샌드박스, 사용자는 bash 해석 필요, 피해 반경은 로컬 작업공간
• 봉인 VM(Claude Cowork): 격리 오버헤드는 전체 VM 부팅, 사용자 의존은 해당 없음, 피해 반경은 vsock + 하이퍼바이저 경계로 보호되는 마운트 작업공간

에이전트가 읽는 것을 신뢰하기

• 엔터프라이즈는 MCP 연결 보안을 자주 묻지만, 올바른 질문은 MCP에 국한되지 않고 더 넓음 — 외부 리소스는 코드 실행 위험(공급망 측면)과 프롬프트 인젝션 벡터 두 위험을 동시에 가짐
  • 전통적 의존성 감사(버전 고정, 서명 검증, 소스 검토)는 첫 번째만 해결하고 두 번째는 놓침
• 원격 대 로컬의 차이가 보이는 것보다 중요 — 로컬 도구는 감사·버전 고정 가능하고 변하지 않지만, 원격 도구(호스팅 MCP 서버, 클라우드 커넥터)는 승인 이후 언제든 동작이 바뀔 수 있어 설치 시점의 신뢰 결정이 더는 유효하지 않을 수 있음
  • connector directory는 지속 검토로 이를 보완하나, 그 밖의 것은 신뢰 불가로 취급하고 피해 반경이 봉쇄된 환경에서 가짜 데이터로 먼저 실행할 것
• 도구 출력은 도구가 신뢰돼도 공격 표면 — 앞서의 GitHub README 사례가 그 경우이며, 웹 페이지에 적용하는 입력 스캐닝을 네트워크 연결 도구 결과에도 동일하게 적용해야 함
  • 오염된 도구 반환이 일단 에이전트를 데이터 유출로 유도하면 로그에는 성공한 인가된 API 호출만 남아 사후 신호가 없으므로, 지연이 늘고 완벽하지 않더라도 라이브 검사를 우선
  • Claude Code와 Cowork에서는 도구 호출이 네트워크·파일 정책을 강제하는 프록시를 거치며, 검사를 수행하는 분류기는 추론용 모델이 아니어도 되는 작고 빠른 모델로 충분

향후 과제

• 영구 메모리 오염(Persistent memory poisoning): 세션 간 유지되는 컨텍스트(제품 메모리, CLAUDE.md 파일, 마운트된 작업공간, 예약·장기 실행 에이전트의 상태 디렉터리)가 늘면서, 여기에 들어온 인젝션이 에이전트 시작마다 재로드 — 세션 시작 시 우수한 분류기가 더 보편화되어야 함
• 멀티 에이전트 신뢰 상승(Multi-agent trust escalation): 서브 에이전트가 원시 텍스트 대신 구조화된 사실을 반환해 신뢰 불가 콘텐츠를 격리할 수 있으나, "우리 것"이라는 이유로 서브 에이전트 출력을 원시 도구 결과보다 높은 신뢰로 다루면 새 인젝션 벡터가 생김 — 신뢰 수준 차등 부여와 신뢰 상승 노출 사이의 트레이드오프 존재
• 에이전트 신원(Agent identity): Cowork는 자격 증명을 호스트 키체인에 두고 VM에 세션별 축소 토큰을 부여하며 그 토큰을 사용자와 독립적으로 폐기 가능
  • 다만 에이전트가 자체 주체 신원을 가져야 하는지, 사용자의 확장으로서 권한을 상속해야 하는지에 대한 크로스 플랫폼 신원 문제는 두 방식의 혼합이 답일 수 있음
• 실패 유형은 산업·연구소 전반에서 반복될 가능성이 크므로, 공유 벤치마크·공개 규범·공통 신원 표준·교차 벤더 레드팀 등 에이전트 특화 보안 태세에 대한 집단적 투자가 필요

핵심 원칙 요약

• 환경 계층에서 먼저 봉쇄를 설계하고, 그다음 모델 계층에서 행동을 조정 — 가장 큰 교훈을 준 두 사고(직원 피싱, 서드파티 허용 목록 공개)는 모두 허용된 경로로 데이터가 빠져나간 이그레스 사례이며, 이 경우 모델 계층은 잡을 이상 징후가 없어 결정론적 경계가 최후의 방어
• 격리 강도를 사용자의 감독 역량에 맞출 것 — bash를 읽는 개발자와 그렇지 않은 지식 노동자는 같은 위협 모델이 아니며, 전문가에게 과한 마찰을 주거나 비전문가에게 과한 신뢰를 주는 양방향 오류 모두 실패
• 커스텀 구성 요소를 경계할 것 — 검증된 하이퍼바이저·시스템콜 필터·컨테이너 런타임이 더 많은 적대적 검증을 견뎠으며, 모든 배포에서 표준 프리미티브는 버텼고 그 주변의 자체 작업이 결함을 드러냄
• 에이전트는 새로운 소프트웨어 범주여도 시스템 수준 상호작용(파일 읽기, 소켓 열기, 프로세스 생성)은 새롭지 않아, 성숙한 도구로의 봉쇄가 핵심적으로 유효한 방어가 됨