제품 전반에서 Claude를 제어하는 방법

제품 업데이트, 사용 방법, 커뮤니티 스포트라이트 등이 매월 귀하의 편지함으로 전달됩니다.

12개월 전만 해도, 우리는 Claude에게 Anthropic 내부 서비스를 중단시킬 수 있을 만큼 충분한 권한을 부여한다는 아이디어를 즉각 거부했을 것입니다. 오늘날 그 정도 수준의 권한 부여는 일상적이며, Anthropic 개발자들은 이를 통해 더 높은 생산성을 얻고 있습니다. 이러한 배포(deployments)의 위험은 두 가지 요소로 구성됩니다: 실패할 가능성이 얼마나 높은가, 그리고 한 번의 실패가 얼마나 큰 피해를 줄 수 있는가입니다. 안전장치(safeguards)와 모델 학습(model training)의 발전은 첫 번째 요소인 실패 가능성을 꾸준히 낮추어 왔습니다. 반면 두 번째 요소인 이론적 폭발 반경(blast radius)은 역량과 권한이 확장됨에 따라 계속해서 커지고 있습니다. 하지만 에이전트(agents)가 과거에 사람이나 팀 전체가 수행해야 했던 업무를 수행할 수 있게 됨에 따라, 배포하지 않았을 때의 비용이 매우 커졌습니다. 따라서 제품을 안전하게 만들 수만 있다면, 위험 대비 보상 계산은 채택 쪽으로 크게 기울게 됩니다. 이제 엔지니어링 측면의 과제는 어떻게 폭발 반경(blast radius)을 제한할 것인가가 되었습니다.

이를 수행하는 방법에는 크게 두 가지가 있습니다.

첫 번째는 인간 참여형(human-in-the-loop)을 통해 에이전트의 행동을 감독하는 것입니다. 이전의 Claude Code는 매 단계마다 사용자에게 권한을 요청함으로써 에이전트가 의도하지 않은 행동을 하는 것을 방지했습니다. 이론적으로는 작동하지만, 우리는 이 접근 방식이 결함이 있을 수 있음을 발견했습니다. 우리의 텔레메트리(telemetry) 데이터에 따르면 사용자는 권한 요청 프롬프트의 약 93%를 승인했습니다. 사용자가 더 많은 승인 요청을 볼수록 각 요청에 주의를 덜 기울이게 되며, 시간이 지남에 따라 감독의 성실도가 훨씬 낮아지게 됩니다. 우리는 최근 이러한 승인 피로(approval fatigue)를 줄이기 위해 더 안전한 승인을 자동화하는 Claude Code 오토 모드(auto mode)를 구축했습니다. 그럼에도 불구하고 취약점은 남아 있습니다. 모든 확률론적 방어(probabilistic defense)에는 0이 아닌 미스율(miss rate)이 존재하기 때문입니다.1

폭발 반경(blast radius)을 제한하기 위한 두 번째 접근 방식이자 이 글의 주요 초점은 격리(containment)입니다. 에이전트가 무엇을 하는지 감독하는 대신, 우리는 예를 들어 샌드박스(sandboxes), 가상 머신(virtual machines), 그리고 송신 제어(egress controls)를 통해 접근 경계(access boundaries)를 강제함으로써 에이전트가 무엇을 할 수 있는지를 감독합니다. 이 부분은 Anthropic 엔지니어링 팀이 가장 많은 노력을 기울인 분야인 동시에, 가장 놀라운 보안 실패가 많이 발생한 지점이기도 합니다.

지난 2년 동안 우리는 세 가지 주요 에이전트 제품인 claude.ai, Claude Code, Claude Cowork를 출시했습니다. 각 제품은 서로 다른 사용자층을 대상으로 하며, 그에 따라 서로 다른 격리 아키텍처(containment architecture)를 필요로 합니다. 이 글에서는 무엇이 잘 작동하고 있는지, 무엇이 고장 났는지, 그리고 그 과정에서 에이전트 보안에 대해 무엇을 배웠는지 공유하고자 합니다.

에이전트에 대한 보안 리스크는 다음 세 가지 범주 중 하나에 속합니다:

**사용자 오용 (User misuse): **사용자가 악의적으로 또는 부주의하게 에이전트에게 해로운 행동을 지시하는 경우입니다. 여기에는 에이전트에게 번거로운 확인 절차를 우회하도록 요청하는 것부터, 이해하지 못하는 파괴적인 명령을 실행하는 것, 그리고 의도적인 위해를 가하도록 지정하는 것까지 모든 것이 포함됩니다.

**모델 오작동 (Model misbehavior): **에이전트가 아무도 요청하지 않은 해로운 행동을 수행하는 경우입니다. 모델이 개선됨에 따라 대부분의 행동 평가에서 정렬(aligned) 수준이 높아졌지만, 이것이 반드시 리스크가 줄어든다는 것을 의미하지는 않습니다. 능력이 낮은 모델은 상황을 잘못 읽고 명백한 오류를 범할 가능성이 더 높습니다. 능력이 높은 모델은 실수를 덜 하지만, 아무도 명시적으로 작성하지 않은 제한 사항을 우회하는 방식으로 목표를 달성하기 위한 예상치 못한 경로를 찾아내는 데 더 능숙합니다.

Anthropic에서 우리는 Claude 모델이 작업을 완료하기 위해

**외부 공격자 (External attackers): **에이전트가 도구, 파일 또는 네트워크 액세스와 같은 외부 벡터를 통해 공격받는 경우입니다. 이 범주에는 프롬프트 인젝션 (Prompt injection)과 에이전트의 런타임 (Runtime), 오케스트레이션 계층 (Orchestration layer) 또는 프록시 (Proxy)에 대한 전통적인 공격이 모두 포함됩니다.

격리 및 방어 시스템을 구축할 때, 우리는 세 가지 주요 구성 요소에 방어책을 적용합니다.

**에이전트가 실행되는 환경 (The environment in which the agent runs). **우리는 프로세스 샌드박스 (Process sandboxes), VM (가상 머신), 파일 시스템 경계 및 이그레스 제어 (Egress controls)를 통해 에이전트가 어디서 어떻게 행동할 수 있는지를 제한합니다. 목표는 에이전트가 접근할 수 있는 것에 대해 엄격한 경계를 설정하는 것입니다. 예를 들어, 자격 증명 (Credentials)이 샌드박스에 절대 들어가지 않는다면, 그 원인이 사용자이든, 모델이 "창의적인" 경로를 찾아낸 것이든, 혹은 공격자이든 관계없이 데이터 유출 (Exfiltration)을 방지할 수 있습니다.

엄격한 경계(Perimeter)를 설정하면 감독을 완화할 수도 있습니다. Claude Code의 참조 devcontainer는 에이전트가 매 동작마다 승인을 받지 않고도 관리되지 않은 상태로 실행될 수 있도록 하기 위해 존재합니다.

에이전트가 참조하는 모델 (The model the agent consults). 여기에는 시스템 프롬프트 (System prompts), 분류기 (Classifiers), 프로브 (Probes) 및 학습 수정 (Training modifications) 메커니즘이 포함됩니다. 모델은 확률적 (Probabilistic)이기 때문에, 이러한 메커니즘은 에이전트가 이론적으로 할 수 있는 능력이 아니라 에이전트가 무엇을 "하는 경향이 있는지"를 형성합니다.

이러한 방어책은 강력합니다. 프롬프트 인젝션에 대한 취약성을 테스트하는 Gray Swan의 에이전트 레드팀 (Agent Red Teaming) 벤치마크에서, Claude Opus 4.7은 단일 시도 시 공격 성공률을 약 0.1%로 유지하며, 100회의 적응형 시도 (Adaptive attempts) 후에도 약 5~6% 수준을 유지합니다. Claude Code의 자동 모드 (Auto mode)는 과도하게 의욕적인 행동의 약 83%를 실행 전에 포착합니다. 하지만 업계 최고 수준의 방어책을 갖추더라도 모델 계층에서의 보호는 결코 100% 효과적일 수 없으며, 이것이 모델 계층의 방어만으로는 충분하지 않은 이유입니다.

에이전트가 접근할 수 있는 외부 콘텐츠. MCP 서버, 서드파티 플러그인(third-party plugins), 웹 검색 도구는 모두 사용자가 제어할 수 없는 소스로부터 에이전트의 컨텍스트 (context)에 콘텐츠를 공급합니다. 감사(audited)를 거친 커넥터라고 해서 감사된 데이터와 동일한 것은 아닙니다. 예를 들어, GitHub 커넥터는 악성코드 검사를 통과하더라도 오염된 README 파일을 모델의 컨텍스트 (context)로 직접 로드할 수 있습니다. 도구 권한을 세밀하게 제한하면 폭발 반경 (blast radius)을 줄이는 데 도움이 됩니다. 예를 들어, 읽기 전용 DB 접근 권한만 가진 에이전트는 운영 환경 (prod)에 쓰기 권한을 가진 에이전트보다 훨씬 더 광범위하게 배포될 수 있습니다.

방어책은 서로 중첩되고 보완되어야 합니다. 환경적 방어책을 사용할 수 없을 때는 모델 계층이 그 부족한 부분을 메워야 합니다 (이것이 바로 Claude Code의 자동 모드 (auto mode)가 설계된 목적입니다). 로컬 환경에서는 환경 및 모델 방어책이 악성 도구 출력물로부터 보호할 수 있지만, 도구의 기능과 접근 권한을 제한함으로써 체인의 더 높은 단계에 방어책을 추가할 수 있습니다.

환경 계층에 집중하여, 우리는 세 가지 격리 패턴 (isolation patterns)과 이것이 각각의 Claude 플랫폼인 claude.ai, Claude Code, Cowork에 어떻게 맞춤화되었는지 설명합니다. 우리는 에이전트에게 필요한 기능과 사용자로부터 요구되는 개입 정도 사이의 균형을 찾은 후, 각 설계를 점진적으로 완성해 나갔습니다.

채팅 인터페이스로 가장 잘 알려져 있지만, claude.ai는 코드 작성 및 실행, 파일 생성, 커넥터 호출도 수행합니다. Claude가 claude.ai 내부에서 코드를 실행할 때는 격리된 인프라 상의 gVisor 컨테이너에서 실행됩니다. 에이전트는 완전히 서버 측 (server-side)에 존재하며, 로컬 머신에서 실행되는 코드는 없고 파일 시스템 (filesystem)은 휘발성 (ephemeral, 세션별)입니다. 폭발 반경 (blast radius)은 최소화되지만, Claude가 할 수 있는 일의 한계치도 낮습니다. 즉, 영구적인 워크스페이스 (workspace)가 없으며 사용자의 파일 시스템 (filesystem)에 접근할 수 없습니다.

이로 인해 claude.ai는 더욱 전통적인 위협 모델 (threat model)의 영향을 받게 됩니다. 우리는 에이전트 (agents)로부터 사용자의 기기를 보호하는 것이 아니라, 우리의 자체 인프라 (infrastructure)를 보호하고 각 테넌트 (tenant)가 서로에게 영향을 미치지 않도록 보호하고 있습니다. claude.ai의 출시 전 작업은 네트워크 구성 (network configuration), 내부 서비스 인증 (internal service auth), 오케스트레이션 (orchestration)과 같은 전통적인 보안 작업이 주를 이루었습니다.

이러한 작업은 보안의 가장 오래된 교훈을 다시 한번 확인시켜 주었습니다. 즉, 가장 취약한 계층은 바로 당신이 직접 구축한 계층이라는 점입니다. gViser와 seccomp는 에이전트형 AI (agentic AI)가 존재하기 훨씬 전부터 풍부한 자원을 가진 적대자들에 맞서 강화되어 왔으므로, 검토 노력은 그 주변에 우리가 새롭게 구축한 구성 요소들에 집중되었습니다. 우리의 커스텀 프록시 (custom proxy) 또한 가장 중대한 사고가 발생했던 지점이었기에, 이 내용은 나중에 다시 다루겠습니다.

Claude Code는 사용자의 기기에서 실행되며 사용자의 파일 시스템 (filesystem), 셸 (shell), 네트워크 (network)에 접근할 수 있습니다. 이것 없이는 코딩 에이전트 (coding agents)의 유용성이 제한되기 때문에, 해당 접근 권한을 안전하게 부여할 방법을 찾는 것이 필수적입니다.

한 가지 접근 방식은 인간 참여형 (human-in-the-loop) 방식에 의존하는 것입니다. 이것이 Claude Code에 대해서만 실행 가능한 해결책인 이유는 평균적인 사용자가 코딩 환경에 익숙한 개발자이기 때문입니다. 그들은 bash를 읽을 수 있고, rm -rf가 무엇을 하는지 이해하며, 이미 일주일에 여러 번 신뢰할 수 없는 소스로부터 npm install을 실행합니다. 이는 곧 "허용(allow this)" 대화 상자가 나타났을 때, 사용자가 에이전트가 시도하려는 작업과 그에 따른 위험을 정확하게 평가할 수 있는 전문 지식을 갖추고 있을 가능성이 매우 높다는 것을 의미합니다. 이를 고려하여, Claude Code는 가능한 가장 단순한 방어 체계와 함께 출시되었습니다. 즉, 읽기 (reads)는 허용하되, 쓰기 (write), bash, 그리고 네트워크 접근 (network access)에 대해서는 승인을 요구하는 방식입니다.

하지만 언급했듯이, 몇 주 만에 승인 피로 (approval fatigue) 현상이 나타났습니다. 아이러니하게도 이는 원래 감독 (oversight)을 제공하기 위해 설계된 기능이 오히려 반대의 효과를 낼 수 있음을 의미했습니다. 즉, 일부 사용자는 단순히 주의를 기울이는 것을 멈출 수도 있다는 것입니다. 부주의한 승인을 완화하기 위한 첫 번째 단계로, 우리는 경계 (boundary)를 강화하는 OS 레벨의 샌드박스 (sandbox) (macOS의 Seatbelt, Linux의 bubblewrap)를 출시했습니다. 이 방식은 읽기 (reads)는 허용하고, 워크스페이스 내부에서의 쓰기 (writes)는 허용하되, 네트워크 (network)는 기본적으로 차단합니다. 샌드박스 내에서 에이전트 (agent)는 거의 중단 없이 실행됩니다. 그 결과 권한 요청 (permission prompts)이 84% 감소했으며, 우리는 런타임 (runtime)을 오픈 소스로 공개하여 경계를 감사 (auditable)할 수 있도록 했습니다.

우리의 익명화된 사용 데이터에 따르면, 숙련된 사용자들은 신규 사용자보다 약 두 배 더 자주 자동 승인 (auto-approve)을 하지만, 실행 도중 에이전트를 중단시키는 빈도 또한 더 높았습니다. 숙련된 사용자들은 개별 단계를 차단하는 대신, 에이전트가 경로를 벗어날 때만 감독할 가능성이 더 높습니다. 이것이 사람들이 에이전트와 협업하는 방식의 자연스러운 진화일 수도 있지만, 이 또한 오류가 발생할 수 있습니다. 사용자가 애초에 편차 (drift)를 알아차릴 수 있을 만큼 충분히 기술적이고 주의 깊어야 하기 때문입니다. 모델의 역량이 향상되고 에이전트가 점점 더 야심 찬 bash 명령을 작성하기 시작함에 따라, 이러한 편차를 알아차리는 것은 더욱 어려워집니다. 또한 사용자들이 멀티 에이전트 시스템 (multi-agent systems)으로 이동함에 따라, 이 접근 방식은 효과적인 감독 전략이 될 가능성이 훨씬 낮아집니다.

2025년 중반에서 2026년 1월 사이, 당사의 책임 있는 공개 (responsible disclosure) 프로그램을 통해 Claude Code의 취약점에 대한 보고를 받았습니다. 세 건의 사례에서는 사용자가 무엇인가에 동의하기 전에 실행되는 코드가 악용되었습니다. 이것이 어떻게 가능한지 이해하기 위해 가장 직접적인 사례를 살펴보겠습니다. 개발자가 풀 리퀘스트 (pull request)를 검토하기 위해 저장소 (repository)를 클론 (clone)했는데, 해당 저장소에 훅 (hook)을 정의하는 .claude/settings.json 파일이 포함되어 있는 경우입니다. Claude Code는 표준 "이 폴더를 신뢰하십니까?" 프롬프트가 나타나기 전, 즉 시작 단계에서 프로젝트 설정을 읽기 때문에, 공격자가 작성하여 커밋한 훅이 자동으로 실행되었습니다. 나머지 사례들도 구조적으로 유사했으며, 신뢰 경계 (trust boundary)가 설정되기 전에 아직 신뢰되지 않은 디렉토리로부터의 입력이 파싱 (parsing)되었습니다.

각 사례의 해결책은 동일한 형태였습니다. 사용자가 신뢰 프롬프트를 수락한 이후로 프로젝트 로컬 설정의 파싱 및 실행을 연기하는 것이었습니다. 만약 여러분이 이와 유사한 것을 구축하고 있다면, 프로젝트 오픈 (project-open), 설정 로드 (config-load), 그리고 로컬호스트 (localhost) 리스너 (listener)를 인터넷에서 들어오는 모든 인바운드 요청 (inbound request)과 동일하게 취급하십시오. 이들이 로컬처럼 느껴지거나 사용자가 동의하기 전에 도착한다는 이유만으로 암묵적으로 신뢰해서는 안 됩니다.

2026년 2월, 통제된 내부 레드팀 (red-team) 훈련 중에 한 연구원이 악성 프롬프트로 Claude Code를 실행하도록 직원을 피싱 (phishing)하는 데 성공했습니다. 이 피싱은 일반적인 협업처럼 보였습니다. 바로 붙여넣을 수 있는 프롬프트가 첨부된 "이것 좀 대신 실행해 줄 수 있나요?"라는 이메일이었으며, 프롬프트 자체도 일상적인 작업 지침처럼 읽혔습니다. 하지만 설정 단계 중 어딘가에서, Claude에게 ~/.aws/credentials를 읽고, 내용을 인코딩(encode)한 다음, 외부 엔드포인트 (endpoint)로 POST 요청을 보내도록 은밀하게 요청했습니다. 해당 프롬프트를 25번 재시도하는 동안, Claude는 24번의 데이터 유출 (exfiltration)을 완료했습니다.

이것은 직접적인 프롬프트 인젝션 (Prompt Injection)입니다. 공격자의 지침이 도구 출력(tool output)이나 가져온 콘텐츠(fetched content)를 통해서가 아니라, 사용자를 통해 전달되었습니다. 우리의 모델 계층 방어 (model-layer defenses)는 사용자 의도 (user intent)에 기반을 두고 있습니다. 사용자가 직접 지침을 입력하는 경우, 분류기 (classifier)가 포착할 수 있는 이상 징후가 없습니다. 인간 계약자가 동일한 스크립트를 전달했더라도 똑같은 행동을 했을 것입니다.

이 상황에서 유효한 유일한 방어책은 환경, 구체적으로는 의도와 상관없이 POST 요청을 차단하는 송신 제어 (egress controls)와 ~/.aws 디렉토리에 아예 접근할 수 없도록 격리하는 파일 시스템 경계 (filesystem boundaries)입니다.

(논의를 위해 내부 Slack에 작동하는 프롬프트를 공유했을 때, 누군가가 일부 내부 에이전트 (internal agents)가 Slack을 읽는다는 점을 지적했습니다. 이제 페이로드 (payload)가 주변에 존재하는 상태가 된 것입니다. 우리는 무언가가 이를 채택할 경우 알아챌 수 있도록 스레드에 카나리 문자열 (canary string)을 추가했습니다. 에이전트가 모든 것을 읽는 세상에서는, 조사 도구 (investigation tooling) 또한 공격 표면 (attack surface)이 됩니다.)