Anthropic이 자사 제품 전반에서 Claude를 통제하는 방법

1년 전만 해도, Anthropic 내부 서비스를 중단시킬 수 있는 수준의 접근 권한을 Claude에게 부여한다는 생각은 즉각 거부했을 것이다. 오늘날 그 수준의 접근은 일상이 되었고, Anthropic 개발자들의 생산성도 덩달아 높아졌다. 이러한 배포의 위험은 두 가지 요소로 이루어진다. 장애가 발생할 가능성, 그리고 장애가 실제로 발생했을 때의 피해 규모다. 안전 장치와 모델 학습의 발전으로 전자는 꾸준히 줄어들고 있지만, 후자—이론적인 피해 반경—는 기능과 접근 범위가 넓어질수록 오히려 커진다. 그러나 에이전트가 과거에 사람 한 명, 심지어 팀 전체가 해야 했던 일을 처리할 수 있게 되면서, 배포하지 않는 것의 비용도 점점 커지고 있다. 제품을 안전하게 만들 수 있다면, 위험 대비 보상의 계산은 결국 채택 쪽으로 크게 기울게 된다. 결국 핵심 공학적 과제는 피해 반경을 어떻게 제한하느냐가 된다.

피해 반경을 제한하는 방법은 크게 두 가지다.

첫 번째는 사람이 루프에 참여하는 방식으로 에이전트의 행동을 감독하는 것이다. Claude Code는 과거에 매 단계마다 사용자에게 승인을 요청하는 방식으로 에이전트가 의도치 않은 행동을 취하는 것을 방지했다. 이론적으로는 유효한 접근이지만, 실제로는 허점이 있다는 것이 드러났다. 텔레메트리 데이터를 보면 사용자들은 권한 요청의 약 93%를 승인했다. 승인 요청을 많이 볼수록 각 요청에 기울이는 주의는 줄어들고, 시간이 지나면서 감독의 꼼꼼함도 크게 떨어진다. 이런 승인 피로를 줄이기 위해 최근 Claude Code 자동 모드를 출시했는데, 안전한 승인을 자동화하는 방식이다. 그럼에도 취약점은 남아 있다. 확률적 방어에는 탐지 실패율이 항상 존재하기 때문이다.¹

피해 반경을 제한하는 두 번째 방법—이 글의 주된 주제이기도 한—은 격리(containment)다. 에이전트가 무엇을 하는지를 감독하는 대신, 샌드박스·가상 머신·이그레스 제어 같은 접근 경계를 강제함으로써 에이전트가 할 수 있는 것 자체를 제한하는 방식이다. Anthropic 엔지니어링이 가장 많은 노력을 쏟은 영역도 바로 이곳이며, 가장 예상치 못한 보안 실패들이 발생한 곳도 여기다.

지난 2년간 Anthropic은 세 가지 주요 에이전트 제품을 출시했다. claude.ai, Claude Code, 그리고 Claude Cowork다. 각 제품은 서로 다른 대상을 위한 것이기 때문에, 격리 아키텍처도 제각각이다. 이 글에서는 무엇이 잘 버텼는지, 무엇이 무너졌는지, 그리고 그 과정에서 에이전트 보안에 대해 무엇을 배웠는지를 공유한다.

세 가지 위험 유형, 세 가지 방어 요소

에이전트에 대한 보안 위험은 크게 세 가지 범주로 나뉜다.

사용자 오남용: 사용자가 악의적으로 또는 부주의하게 에이전트에게 유해한 행동을 지시하는 경우다. 귀찮은 검사를 우회해달라는 요청부터, 의미를 이해하지 못한 채 파괴적인 명령을 실행하거나 의도적인 해를 가하는 행동까지 다양한 형태가 포함된다.

모델 오작동: 아무도 요청하지 않은 유해한 행동을 에이전트가 스스로 취하는 경우다. 모델이 발전할수록 대부분의 행동 평가에서 더 정렬된 모습을 보이지만, 그렇다고 위험이 반드시 줄어드는 것은 아니다. 덜 유능한 모델은 상황을 잘못 읽고 명백한 실수를 저지를 가능성이 높다. 더 유능한 모델은 실수가 적지만, 목표에 이르는 예상치 못한 경로를 찾는 능력도 뛰어나다. 누구도 미리 적어두지 않은 제약을 우회하는 식으로 말이다.

Anthropic에서 Claude 모델이 작업을 완료하기 위해 "친절하게" 샌드박스를 탈출하거나, git 히스토리를 뒤져 코딩 테스트의 답을 찾아내거나, 실행 중인 벤치마크를 자체적으로 파악해 정답 키를 복호화하는 사례를 직접 목격했다. 새로운 모델이 나올 때마다 예상치 못한 방식으로 발휘되는 새로운 능력들이 함께 따라온다.

외부 공격자: 도구, 파일, 네트워크 접근 같은 외부 경로를 통해 에이전트를 공격하는 경우다. 프롬프트 인젝션은 물론, 에이전트의 런타임·오케스트레이션 레이어·프록시에 대한 전통적인 공격도 이 범주에 해당한다.

격리 및 방어 시스템을 구축할 때, Anthropic은 세 가지 주요 구성 요소에 방어를 적용한다.

에이전트가 실행되는 환경. 프로세스 샌드박스, 가상 머신, 파일시스템 경계, 이그레스 제어를 통해 에이전트가 어디서 어떻게 행동할 수 있는지를 제한한다. 목표는 에이전트가 닿을 수 있는 범위에 명확한 경계선을 긋는 것이다. 예를 들어, 자격 증명이 샌드박스에 애초에 들어가지 않는다면, 그 원인이 사용자든 "창의적인" 경로를 찾아낸 모델이든 공격자든, 유출 자체가 불가능하다.

경계가 촘촘할수록 감독의 부담을 줄일 수도 있다. Claude Code의 레퍼런스 devcontainer가 존재하는 이유도 바로 이것이다. 에이전트가 각 행동마다 승인 없이 사람의 개입 없이 실행될 수 있도록 하기 위해서다.

에이전트가 참조하는 모델. 이 레이어의 방어 수단으로는 시스템 프롬프트, 분류기, 프로브, 학습 수정 등이 있다. 모델은 확률적 특성을 가지기 때문에, 이러한 수단들은 에이전트가 경향적으로 어떻게 행동하는지를 조정할 뿐, 이론적으로 무엇이 가능한지를 제한하지는 않는다.

이 방어들은 강력하다. 프롬프트 인젝션 취약성을 테스트하는 Gray Swan의 Agent Red Teaming 벤치마크에서 Claude Opus 4.7은 단일 시도 시 공격 성공률을 약 0.1%, 100회 적응형 시도 후에도 약 5~6% 수준으로 억제했다. Claude Code 자동 모드는 과도한 행동의 약 83%를 실행 전에 차단한다. 그러나 최고 수준의 방어를 갖춰도 모델 레이어의 보호는 결코 100%가 될 수 없다. 이것이 바로 모델 레이어만으로는 충분하지 않은 이유다.

에이전트가 접근할 수 있는 외부 콘텐츠. MCP 서버, 서드파티 플러그인, 웹 검색 도구는 모두 제어할 수 없는 출처의 콘텐츠를 에이전트의 컨텍스트에 주입한다. 감사를 통과한 커넥터가 감사를 통과한 데이터를 의미하지는 않는다. 예를 들어, GitHub 커넥터는 악성 코드 검사를 통과하더라도 오염된 README를 모델의 컨텍스트에 그대로 불러올 수 있다. 도구 권한을 세밀하게 제한하면 피해 반경을 줄이는 데 도움이 된다. 예컨대 읽기 전용 DB 접근 권한을 가진 에이전트는 운영 환경에 쓰기 권한을 가진 에이전트보다 훨씬 넓은 범위에 안전하게 배포할 수 있다.

방어는 서로 겹치고 보완해야 한다. 환경 레이어의 방어가 여의치 않을 때는 모델 레이어가 그 빈자리를 채워야 한다(이것이 바로 Claude Code 자동 모드가 설계된 목적이다). 로컬에서는 환경과 모델 방어가 악성 도구 출력을 막을 수 있지만, 도구의 기능과 접근 범위를 제한하는 방식으로 상위 레이어에도 방어를 추가할 수 있다.

에이전트 격리 패턴

환경 레이어에 초점을 맞춰, 세 가지 격리 패턴과 각 Claude 플랫폼—claude.ai, Claude Code, Cowork—에 맞게 이를 어떻게 조정했는지 설명한다. 각 설계는 에이전트에게 필요한 기능과 사용자에게 요구되는 개입 수준 사이의 균형을 찾아가는 과정에서 점진적으로 도달한 결과다.

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

claude.ai는 채팅 인터페이스로 가장 잘 알려져 있지만, 코드를 작성하고 실행하며 파일을 생성하고 커넥터를 호출하기도 한다. claude.ai 내에서 Claude가 코드를 실행할 때는 격리된 인프라의 gVisor 컨테이너 안에서 이루어진다. 에이전트는 완전히 서버 측에서 동작하며, 로컬 머신에서는 코드가 실행되지 않고 파일시스템은 세션 단위로 휘발된다. 피해 반경은 최소화되지만, 그만큼 Claude가 할 수 있는 일의 한계도 분명하다. 영속적인 작업 공간도 없고 사용자 파일시스템에 대한 접근도 없다.

이 구조로 인해 claude.ai는 보다 전통적인 위협 모델을 따르게 된다. 에이전트로부터 사용자 머신을 보호하는 것이 아니라, Anthropic 자체 인프라와 테넌트 간 격리가 핵심이다. claude.ai 출시 전 작업 대부분은 네트워크 설정, 내부 서비스 인증, 오케스트레이션 같은 전통적인 보안 작업이 주를 이뤘다.

그 과정에서 보안의 가장 오래된 교훈을 다시 한번 확인했다. 가장 취약한 레이어는 직접 만든 것이라는 점이다. gVisor와 seccomp은 에이전트 AI가 등장하기 훨씬 전부터 강력한 공격자들을 상대로 검증되어 왔기 때문에, 검토 작업은 그 위에 새로 구축한 부분들에 집중되었다. 이 주제는 나중에 다시 다루겠지만, 가장 심각한 사고에서 문제가 된 것도 바로 우리가 직접 만든 커스텀 프록시였다.

패턴 2: 사람이 참여하는 루프 샌드박스 (Claude Code)

Claude Code는 사용자 머신에서 실행되며 파일시스템, 셸, 네트워크에 접근한다. 이 접근 없이는 코딩 에이전트의 실용성이 크게 제한되기 때문에, 이를 안전하게 허용하는 방법을 찾는 것이 핵심 과제다.

한 가지 방법은 사람이 루프에 참여하는 방식에 기대는 것이다. Claude Code에서는 평균적인 사용자가 코딩 환경에 익숙한 개발자라는 점에서 이 접근이 현실적으로 가능하다. bash를 읽을 수 있고, rm -rf가 무엇을 하는지 알며, 이미 매주 여러 번 신뢰하지 않는 출처에서 npm install을 실행하는 사람들이다. 이러한 배경 덕분에 "허용할까요?" 다이얼로그가 떴을 때, 에이전트가 무엇을 하려는지와 그에 따른 위험을 정확히 판단할 가능성이 높다. 이를 전제로 Claude Code는 가장 단순한 방어책으로 출시되었다. 읽기는 허용하되, 쓰기·bash·네트워크 접근은 승인을 요구하는 방식이다.

그러나 앞서 언급했듯, 승인 피로는 출시 몇 주 만에 나타났다. 아이러니하게도, 이는 감독을 위해 설계된 기능이 오히려 역효과를 낼 수 있음을 의미했다. 일부 사용자들이 단순히 주의를 기울이지 않게 될 수 있었기 때문이다. 무분별한 승인을 줄이기 위한 첫 번째 조치로, OS 레벨 샌드박스(macOS에서는 Seatbelt, Linux에서는 bubblewrap)를 출시해 경계를 강화했다. 읽기는 허용되고, 작업 공간 내 쓰기도 허용되지만, 네트워크는 기본적으로 차단된다. 샌드박스 내에서 에이전트는 대부분의 작업을 중단 없이 실행한다. 그 결과 권한 요청이 84% 줄었고, 런타임을 오픈소스로 공개해 경계를 감사할 수 있게 했다.

익명화된 사용 데이터를 보면 숙련 사용자들은 신규 사용자보다 약 두 배 더 자주 자동 승인하지만, 에이전트 실행 도중에 더 자주 개입하기도 한다. 개별 단계를 일일이 승인하는 대신, 숙련 사용자들은 에이전트가 궤도를 이탈했을 때만 감독에 나서는 경향이 있다. 이것이 에이전트와 협업하는 방식의 자연스러운 변화일 수 있지만, 이 방식 역시 허점이 있다. 애초에 이탈을 알아채려면 사용자가 충분한 기술적 역량과 집중력을 갖추고 있어야 하기 때문이다. 모델 성능이 향상되고 에이전트가 점점 더 복잡한 bash를 작성하게 되면, 이러한 이탈을 눈치채기는 더욱 어려워진다. 멀티 에이전트 시스템으로 넘어가면 이 접근 방식은 효과적인 감독 전략으로서의 설득력을 더욱 잃게 된다.

놓쳤던 위험: 신뢰 다이얼로그 이전에 일어나는 일들

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

각 사례의 수정 방식도 동일했다. 프로젝트 로컬 설정의 파싱과 실행을 사용자가 신뢰 프롬프트를 수락한 이후로 미루는 것이었다. 유사한 것을 만들고 있다면, 프로젝트 열기, 설정 로드, localhost 리스너를 인터넷에서 들어오는 모든 인바운드 요청처럼 다뤄야 한다. 로컬처럼 느껴지거나 사용자 동의 전에 도달한다는 이유만으로 암묵적으로 신뢰해서는 안 된다.

놓쳤던 위험: 인젝션 경로가 된 사용자

2026년 2월, 통제된 내부 레드팀 훈련 중 한 연구원이 직원을 피싱해 악성 프롬프트로 Claude Code를 실행하는 데 성공했다. 해당 피싱은 평범한 협업처럼 보였다. 붙여넣기 준비가 된 프롬프트가 첨부된 "이것 좀 실행해줄 수 있어?" 이메일이었고, 프롬프트 자체도 일상적인 작업 지시처럼 읽혔다. 그러나 설정 단계 어딘가에 ~/.aws/credentials를 읽어 내용을 인코딩한 뒤 외부 엔드포인트에 POST하라는 내용이 슬며시 포함되어 있었다. 해당 프롬프트로 25회 시도한 결과, Claude는 24회 유출을 완료했다.

이것은 직접적인 프롬프트 인젝션이다. 공격자의 지시가 도구 출력이나 가져온 콘텐츠가 아닌 사용자를 통해 전달되었다. 모델 레이어의 방어는 사용자 의도에 기반하는데, 사용자가 직접 지시를 입력하는 상황에서는 분류기가 잡아낼 이상 징후 자체가 없다. 동일한 스크립트를 받은 인간 직원도 같은 행동을 했을 것이다.

이 상황에서 유효한 유일한 방어는 환경이다. 구체적으로는, 의도와 무관하게 POST를 차단하는 이그레스 제어, 그리고 애초에 ~/.aws에 접근하지 못하도록 막는 파일시스템 경계다.

(내부 Slack에서 논의를 위해 해당 프롬프트를 공유했을 때, 누군가가 일부 내부 에이전트가 Slack을 읽는다는 점을 지적했다. 페이로드가 이제 주변 환경에 퍼진 셈이었다. 그래서 무언가가 이를 읽어갈 경우 알 수 있도록 스레드에 카나리아 문자열을 추가했다. 에이전트가 모든 것을 읽는 세상에서는 조사 도구 자체도 공격 대상이 된다.)

패턴 3: 로컬 가상 머신 (Claude Cowork)

Claude Cowork는 사용자가 선택한 작업 공간 폴더에 접근하며 사용자 데스크톱에서 실행된다. 이 플랫폼은 소프트웨어 엔지니어링이 아닌 일반 지식 업무를 위해 만들어졌기 때문에, 평균적인 사용자가 bash에 능숙할 가능성은 훨씬 낮다.

그 결과, 사람이 루프에 참여하는 샌드박스 전략은 여기서 적용하기 어렵다. 비기술적인 지식 근로자에게 find . -name "*.tmp" -exec rm {} \; 같은 bash 명령을 판단하도록 요구하는 것은 무리다. 예외를 승인하는 데 일반 사용자가 갖추지 못한 전문성이 필요할 때는, 관리자가 절대적이고 항상 작동하는 경계를 설정해야 한다.

이를 가능하게 하기 위해, Claude Cowork의 초기 버전은 플랫폼 벤더의 하이퍼바이저(macOS에서는 Apple의 Virtualization framework, Windows에서는 HCS)를 사용한 전체 가상 머신 안에서 실행되었다. 가상 머신은 자체 Linux 커널, 자체 파일시스템, 자체 프로세스 테이블을 가진다. 사용자가 선택한 작업 공간과 .claude 폴더만 마운트되며, 호스트의 다른 항목은 보이지 않는다. 자격 증명은 호스트의 키체인에 보관되며 게스트 머신에는 절대 들어가지 않는다. 이 설계는 Claude가 언젠가 정렬에서 벗어난 행동을 할 가능성에 대비한 것이다. 손상된 Claude가 작업 공간 폴더 내부를 망가뜨릴 수는 있지만, 아키텍처는 그것이 유일한 접근 가능 범위가 되도록 설계되었고(사용자가 커넥터를 추가하기 전까지), 무엇이 마운트되는지는 사용자가 통제한다.

풀 VM 모드라고 부르는 초기 아키텍처에서는 에이전트 루프 자체가 게스트 안에서 실행되었기 때문에, Claude는 샌드박스 안에 있다는 인식 없이 일반 Linux 사용자로 동작했다. 이를 Claude Code와 비교해보면, Claude Code에서는 권한을 가진 프로세스가 샌드박스 바깥에서 명령별로 강제 적용 여부를 결정한다. 즉, 설득력 있는 인젝션 프롬프트나 피로한 사용자의 승인 클릭 하나로 그 프로세스가 샌드박스 밖에서 무언가를 실행할 수 있다. 풀 VM 모드에서는 탈출 경로의 열쇠를 쥔 외부 프로세스 자체가 없었기 때문에, 예외를 허용할 권한을 가진 구성 요소도 존재하지 않았다.

그러나 전체 에이전트를 풀 VM 모드로 실행하면 실용적인 문제가 생긴다는 것을 곧 깨달았다. 가상 머신 시작 중 오류가 발생하면 Cowork 자체가 사용 불가 상태가 되었다. 코드 실행은 가상 머신 안에 유지하면서 에이전트 루프를 가상 머신 밖으로 옮기자, Claude가 오류 발생 시에도 멈추지 않고 사용자에게 응답하며 문제를 디버깅하는 데 도움을 줄 수 있게 되었다. 이 변경이 보안에 미친 영향은 미미했다. 에이전트가 실행하는 코드에 대한 파일시스템과 네트워크 제어는 가상 머신이 여전히 담당하기 때문이다.

별도로, 로컬 MCP 서버도 가상 머신 밖으로 이전했다. 가상 머신 안에서 실행할 경우 감사가 어렵고, 가상 머신이 업데이트될 때 취약한 의존성 문제가 생겼으며, 데이터베이스처럼 로컬 프로세스와 상호작용이 필요한 MCP를 지원하지 못했다. 이러한 서버들은 어차피 호스트에서 실행되어야 했다. 이 변경으로 Claude Cowork는 Claude Desktop에서 로컬 MCP 서버가 이미 작동하는 방식과 일치하게 되었다. 로컬 MCP 서버를 사용자가 설치하기로 선택하는 소프트웨어처럼 취급하고, 어떤 로컬 MCP를 활성화할지(활성화한다면)는 관리자가 결정하게 하는 방식이다. 원격 MCP 서버는 사용자 머신에서 실행되지 않으므로 영향을 받지 않는다.

파일시스템 제어도 중요한 아키텍처 선택이었다. Claude가 유용하게 기능하려면 호스트의 일부 파일에 접근해야 하지만, 피해 반경을 최소화하고 로컬 파일 접근에 대한 투명성을 사용자에게 제공하고자 했다. 다양한 파일 마운트 모드를 제공하면 위험을 세밀하게 제어하는 데 도움이 된다는 것을 알게 되었다. Claude Cowork는 읽기 전용, 읽기-쓰기, 읽기-쓰기-삭제 불가 모드를 제공한다. 주의해야 할 점은 심링크 해석이 경로 검증 이전에 이루어져야 한다는 것이다. 이후에 처리하면 인가된 폴더 안의 심링크가 바깥쪽을 가리켜 경계를 이탈할 수 있다. 기업 고객에게는 MDM 설정의 마운트 경로 허용 목록을 통해 관리자가 이를 제어할 수 있도록 한다.

놓쳤던 위험: 허용된 도메인을 통한 유출

서드파티 공개를 통해 드러난 허용 도메인을 통한 유출 사례가 있었다. Claude Cowork의 이그레스 허용 목록은 api.anthropic.com으로 향하는 트래픽을 정상적으로 통과시켰다. 제품이 Anthropic API를 호출하지 않고는 동작할 수 없기 때문이다. 이 경우, 사용자의 마운트된 작업 공간에 놓인 악성 파일에 공격자가 제어하는 API 키와 함께 숨겨진 지시가 담겨 있었다. Claude는 지시에 따라 작업 공간의 다른 파일들을 읽고, 공격자의 키를 사용해 Anthropic Files API를 호출했다. 이그레스 프록시는 목적지를 확인하고 api.anthropic.com을 확인한 뒤 통과시켰다. 파일은 공격자의 Anthropic 계정으로 업로드되었다. 샌드박스는 완벽하게 작동했지만, 데이터는 유출되었다.

이전에는 허용 목록을 목적지 필터, 즉 "이 도메인들은 통신해도 된다"고 Claude에게 알려주는 것으로 이해했다. 그러나 이것은 기능 권한 부여로 이해하는 것이 더 정확하다. 허용 목록의 어떤 도메인을 통해서든 도달할 수 있는 모든 기능이 이제 공격 표면이 된다. api.anthropic.com을 허용한다는 것은 임의의 Anthropic 계정으로의 파일 업로드를 허용하는 것이었다.

수정은 가상 머신 내부에 방어적 중간자 프록시를 두어 Anthropic API로 향하는 트래픽을 가로채는 방식으로 이루어졌다. 이 프록시는 가상 머신에 프로비저닝된 세션 토큰을 담은 요청만 통과시키며, 공격자가 심어둔 키는 프록시에서 차단된다. 또한 서버 측 가져오기를 활성화하는 헤더도 차단한다. 프록시가 서버가 아닌 가상 머신 내부에 위치하는 이유는 출처(provenance)를 아는 것은 가상 머신뿐이기 때문이다. 서버 입장에서는 Cowork 요청이 다른 API 클라이언트와 구별되지 않는다.

이는 직접 만든 소프트웨어가 가장 취약한 레이어가 되는 경향이 있다는 원칙의 또 다른 사례이기도 하다. 제품 전반에 걸쳐 하이퍼바이저, seccomp, gVisor는 안정적으로 동작했다. 실패한 것은 바로 우리가 직접 만든 커스텀 허용 목록 프록시였다.

놓쳤던 위험: 가상 머신 격리가 엔드포인트 탐지 소프트웨어도 차단했다

기업 보안팀이 Claude Cowork를 평가하면서 "왜 EDR이 내부를 볼 수 없나요?"라고 물었다. 이유는 간단하다. Claude를 격리하는 동일한 메커니즘이 호스트 기반 엔드포인트 탐지 및 대응(EDR)도 차단했기 때문이다. EDR 관점에서 Claude Cowork는 불투명한 하이퍼바이저 프로세스로 보인다. 게스트 내부를 검사할 수 없다.

격리는 가시성을 떨어뜨리고, 컴플라이언스가 엔드포인트 가시성에 의존하는 팀에게 불투명성은 문제가 된다. 현재 대응책은 관리자가 사후에 이벤트 로그를 가져올 수 있는 풀 방식의 OTLP 내보내기를 사용하는 것이지만, 실시간 모니터링과는 다르다. 유사한 것을 구축한다면, 이 문제에 대한 논의를 초기에 계획에 포함시켜야 한다.

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

기업 고객들은 종종 MCP 연결을 어떻게 보안하느냐고 묻는다. 좋은 질문이지만, 올바른 질문은 MCP에만 국한되지 않는다. 에이전트에게 제공되는 모든 외부 리소스는 두 가지 위험을 동시에 가진다. 전통적인 공급망 측면의 코드 실행 위험과 프롬프트 인젝션 경로다. 전통적인 의존성 감사(버전 고정, 서명 검증, 소스 검토)는 전자에 대응하지만 후자를 놓친다.

원격과 로컬의 차이는 생각보다 중요하다. 로컬에 설치된 도구는 감사가 가능하다. 코드를 읽고 버전을 고정하면 예기치 않게 변경되지 않는다는 것을 알 수 있다. 원격 도구—호스팅된 MCP 서버, 클라우드 커넥터—는 승인 후 언제든지 동작을 바꿀 수 있어, 설치 시점의 신뢰 결정이 더 이상 유효하지 않을 수 있다. Anthropic의 커넥터 디렉터리는 지속적인 검토를 통해 이를 해결하지만, 그 밖의 것은 신뢰하지 않는 것으로 취급해야 한다. 악성 도구의 피해 반경이 제한된 환경에서 가짜 데이터를 먼저 사용해 테스트해보는 것이 좋다.

도구를 신뢰한다고 해서 도구의 출력까지 안전한 것은 아니다. 앞서 언급한 GitHub README 사례가 바로 이것이다. 웹 페이지에 적용하는 입력 스캐닝은 동일한 엄격함으로 네트워크 사용 도구의 결과에도 적용되어야 한다. 지연 시간을 늘리고 완벽한 방어가 아니더라도, Anthropic은 실시간 검사 쪽을 선택한다. 오염된 도구 반환값이 에이전트를 데이터 유출로 유도하고 나면, 로그에는 성공적인 인가 API 호출만 남는다. 사후에 이상 징후를 찾을 방법이 없다.

Claude Code와 Claude Cowork에서 도구 호출은 네트워크 및 파일 정책을 적용하고 반환값이 모델 컨텍스트에 들어가기 전에 검사할 수 있는 프록시를 통해 라우팅된다. 검사를 수행하는 분류기는 작고 빠른 모델이면 충분하다. 추론을 담당하는 모델일 필요는 없다.

앞으로의 과제

모델과 제품은 빠르게 발전하고 있다. 그에 따라 위험도 변화하고 진화하며, 우리의 대응 방식도 함께 발맞춰야 한다.

영속 메모리 오염. 세션을 넘어 유지되는 에이전트 컨텍스트의 비중은 계속 커지고 있다. 제품 메모리, CLAUDE.md 파일, 마운트된 작업 공간, 예약 및 장기 실행 에이전트의 상태 디렉터리가 여기에 포함된다. 이 중 어디에든 인젝션이 자리 잡으면 에이전트가 시작할 때마다 다시 불러와진다. 세션을 넘어 더 많은 에이전트 상태가 살아남을수록, 고전적인 침해 후 공격(post-exploitation) 개념의 새로운 영속화 메커니즘에 위협받게 된다. 세션 시작 시 작동하는 우수한 분류기의 필요성이 점점 높아질 것이다.

멀티 에이전트 신뢰 상승. 한편으로, 서브 에이전트는 신뢰되지 않은 콘텐츠를 격리하고 원시 텍스트 대신 구조화된 사실만 상위 에이전트에 전달함으로써 위험을 줄일 수 있다. 다른 한편으로 이는 악용될 수 있다. 서브 에이전트의 출력이 "우리"에게서 왔다는 이유로 원시 도구 결과보다 높은 신뢰를 받는다면, 새로운 프롬프트 인젝션 경로가 생긴다. 멀티 에이전트 시스템에서는 신뢰 수준을 차등 적용하는 것과 신뢰 상승에 취약해지는 것 사이의 트레이드오프가 존재한다.

에이전트 신원. Claude Cowork는 에이전트 신원 문제에 구체적인 답을 제시한다. 자격 증명은 호스트 키체인에 보관되고, 가상 머신은 세션별로 제한된 토큰을 받으며, 이 토큰은 사용자 계정과 독립적으로 폐기할 수 있다. 그러나 이제 플랫폼을 넘나드는 에이전트 신원이라는 더 큰 문제를 다루기 시작했다. 에이전트가 고유한 주체 신원을 가져야 하는가, 아니면 사용자의 연장선으로서 사용자 권한을 상속받아야 하는가? 궁극적으로 답은 두 가지의 혼합이 될 것이다.

에이전트의 능력이 커질수록 공격 표면은 끊임없이 변화한다. Anthropic이 경험한 실패의 유형은 다른 산업과 연구소에서도 반복될 가능성이 높다. 공유 벤치마크와 공개 규범부터 공통 신원 표준과 크로스 벤더 레드팀까지, 에이전트 특화 보안 역량에 대한 집단적 투자가 필요하다. 이 글은 격리에 초점을 맞추고 있지만, 에이전트 보안의 전체 그림에서는 그것이 한 부분일 뿐이다. 거버넌스, 관찰 가능성, 그리고 나머지 스택에 대해서는 AI 에이전트 신원 및 인증에 관한 NIST 프로젝트, 호주 ACSC가 CISA 및 영국 NCSC와 함께 이끄는 에이전트 AI 도입에 관한 6개 기관 지침, 그리고 AI 관리 표준인 ISO/IEC 42001을 참고하길 바란다. Anthropic의 Glasswing 이니셔티브도 그 기여의 하나이며, 이 중요한 과제에 대해 파트너 및 경쟁사 모두와 함께하기를 기대한다.

요약

결론적으로, Anthropic이 거듭 돌아오게 되는 몇 가지 원칙이 있다.

환경 레이어에서 격리를 먼저 설계하고, 그 위에서 모델 레이어로 행동을 조정하라. 가장 많은 것을 가르쳐 준 두 사건—직원 피싱과 서드파티 허용 목록 공개—은 모두 데이터가 허가된 경로를 통해 빠져나간 이그레스 사례였다. 두 경우 모두 모델 레이어는 도움이 될 수 없었다. 잡아낼 이상 징후 자체가 없었기 때문이다. 확률적 방어가 모두 빗나갈 때 최후의 보루가 되는 것은 결정론적 경계다.

격리의 강도를 사용자의 감독 역량에 맞춰라. bash를 읽을 수 있는 개발자와 그렇지 못한 지식 근로자는 동일한 위협 모델을 가지지 않는다. 사용자가 에이전트가 하려는 행동을 평가할 수 있는지를 격리 전략 결정의 기준으로 삼아야 한다. 이를 잘못 판단하면—전문가에게 불필요한 마찰을 주거나, 비전문가에게 과도한 신뢰를 부여하거나—그 자체로 실패다.

직접 만든 구성 요소를 경계하라. 오랜 시간 검증된 하이퍼바이저, 시스템 콜 필터, 컨테이너 런타임은 어떤 것을 직접 만들더라도 따라잡기 어려운 수준의 적대적 검토를 통과해왔다. 여기서 설명한 모든 배포 사례에서, 표준 프리미티브는 버텼고 그 주변에 직접 구축한 코드에서 결함이 드러났다.

결국 에이전트는 새로운 종류의 소프트웨어일지 모르지만, 시스템 수준의 상호작용은 그렇지 않다. 파일을 읽고, 소켓을 열고, 프로세스를 생성한다. 이는 성숙한 도구를 활용한 격리를 결정적으로 유효한 방어 수단으로 만든다. AI가 발전함에 따라 배포의 위험 대비 보상 균형은 계속 변화하겠지만, 피해 반경에 엄격한 한계를 두는 것은 종종 그 균형을 올바른 방향으로 이끈다.

감사의 말

작성: Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, Abel Ribbink.

또한 Hanah Ho, Hasnain Lakhani, Pedram Navid, Molly Villagra, Maya Nielan, Akila Srinivasan, Sam Attard, Alfred Xing, Mohamad El Hajj, Gabby Curtis, David Dworken, Adam Jones, Amie Rotherham, Christian Ryan, Lucas Smedley, Brett Andrews를 비롯한 여러분의 기여에 감사드립니다.

보안 및 제품 엔지니어링 팀, 그리고 Claude 제품의 취약점을 신고해주신 개인과 조직에게도 특별한 감사를 전합니다.

각주

1. Claude Code 자동 모드는 명령 승인을 모델 기반 분류기에 위임한다. 정상 명령의 약 0.4%가 차단되는 정도로 마찰을 최소화하되, 위험한 명령의 일부(과도한 행동의 약 17%)는 통과시킨다. 따라서 이는 샌드박스 내 다중 방어의 한 레이어로 기능하는 것이지, 샌드박스를 대체하는 것이 아니다.