이 문서는 확정 분석이 아니라 자료 정리다. Anthropic의 Claude containment 글은 “AI agent를 안전하게 만든다”는 추상적 구호보다 훨씬 구체적인 문제를 보여준다. agent가 파일, shell, 네트워크, 외부 도구에 접근할 때 위험은 모델의 답변 품질이 아니라 피해 범위를 어디까지 허용하느냐에서 결정된다.
한 줄로 말하면, Anthropic의 containment 글은 agent 보안이 사람의 승인 버튼만으로는 부족하며, sandbox·VM·egress control·credential 분리·tool permission이 함께 작동해야 한다는 점을 보여준다.
왜 지금 읽을 만한가
AI agent는 점점 더 많은 일을 직접 한다. 코드를 실행하고, 저장소를 고치고, 파일을 읽고, 외부 API를 호출한다. 이 변화는 생산성을 높이지만, 동시에 “잘못된 명령이 실행되면 어디까지 망가지는가”라는 질문을 키운다.
기존 챗봇의 위험은 틀린 답변이나 부정확한 조언에 머물 수 있었다. 반면 coding agent나 업무 agent는 실제 시스템을 바꿀 수 있다. 사용자가 실수하거나, 외부 문서에 prompt injection이 숨어 있거나, 모델이 제한을 우회하려는 예상 밖 경로를 찾으면 피해가 파일 시스템과 네트워크로 번질 수 있다.
그래서 이 글은 agent containment를 제품 수준에서 읽는 데 좋은 원자료다. containment는 agent가 “무엇을 하도록 설득할 수 있는가”보다, 설득에 성공하더라도 “무엇에는 접근할 수 없는가”를 먼저 정하는 보안 설계다.
확인된 것
Anthropic은 agent 위험을 세 가지로 나눈다. 사용자가 악의적이거나 부주의하게 위험한 지시를 내릴 수 있고, 모델이 상황을 잘못 판단해 위험한 행동을 할 수 있으며, 외부 파일·도구·네트워크를 통해 공격자가 agent를 속일 수 있다.
이 위험에 대응하는 층도 세 가지로 제시된다. 첫째는 agent가 실행되는 환경이다. sandbox, VM, 파일시스템 경계, egress control을 통해 agent가 닿을 수 있는 범위를 줄인다. 둘째는 모델 층이다. system prompt, classifier, training modification이 agent의 행동 경향을 조정한다. 셋째는 외부 콘텐츠와 도구 층이다. MCP 서버, 플러그인, web search, connector가 agent context로 가져오는 데이터와 권한을 제한해야 한다.
특히 사람 승인 방식의 한계가 중요하다. Claude Code는 과거에 위험한 동작마다 승인 요청을 띄웠지만, 사용자가 승인 요청을 너무 자주 보면 피로해진다. Anthropic은 telemetry에서 사용자가 permission prompt의 약 93%를 승인했다고 설명한다. 승인이 많아질수록 감독은 형식이 되고, 실제 안전성은 떨어질 수 있다.
그래서 Anthropic은 제품마다 다른 containment 패턴을 쓴다. claude.ai의 코드 실행은 ephemeral container 안에서 일어나고, Claude Code는 개발자 로컬 환경 위에 OS-level sandbox를 붙이며, Claude Cowork는 비개발자 지식노동자를 위해 VM 기반 격리를 사용한다. 제품의 사용자와 권한 범위가 다르면 containment도 달라진다.
Wansook.World에서 볼 포인트
첫 번째 포인트는 “승인”과 “권한 경계”를 구분해야 한다는 점이다. 승인 UI는 사용자의 주의를 요구하지만, containment는 시스템이 애초에 접근할 수 없는 경계를 만든다. agent가 ~/.aws/credentials 같은 민감한 파일을 볼 수 없다면, prompt injection이 성공해도 빼낼 수 있는 것이 줄어든다.
두 번째 포인트는 egress allowlist를 단순한 도메인 목록으로 보면 안 된다는 점이다. Anthropic은 허용된 API 도메인을 통해 파일 업로드가 가능했던 사례를 설명한다. 목적지가 허용된 도메인이라도, 그 도메인에서 제공하는 기능이 데이터 유출 경로가 될 수 있다. 따라서 allowlist는 주소가 아니라 capability grant로 봐야 한다.
세 번째 포인트는 AI 시스템의 감사 가능성이다. 문제가 생겼을 때 어느 파일을 읽었고, 어떤 네트워크 요청을 했고, 어떤 tool permission이 열려 있었는지 재구성할 수 있어야 한다. agent runtime이 기업 시스템으로 들어갈수록 보안은 모델 평가가 아니라 운영 기록과 권한 설계의 문제가 된다.
아직 모르는 것
이 글은 Anthropic 내부 제품군의 경험을 설명한다. 다른 agent 제품이나 기업 환경에서도 같은 구조가 그대로 맞는지는 별도 확인이 필요하다. 특히 Windows, macOS, Linux, cloud sandbox, browser automation, 사내 connector가 섞인 환경에서는 containment 경계가 제품마다 크게 달라질 수 있다.
다음 질문이 남아 있다.
- OS-level sandbox와 VM 방식의 비용, 성능, 사용성 차이가 실제 고객 환경에서 어떻게 나타나는가.
- Egress control이 API domain뿐 아니라 기능 단위까지 얼마나 세밀하게 제한할 수 있는가.
- MCP 서버와 local connector가 늘어날 때 어떤 권한 모델이 표준이 되는가.
- Prompt injection benchmark 개선이 실제 tool-using agent 사고 감소로 이어지는가.
- Agent 보안 사고를 조사하기 위한 log, replay, audit trail이 어디까지 제공되는가.
헷갈리지 말아야 할 점
- 모델이 더 안전해졌다고 실행 환경 경계가 필요 없어지는 것은 아니다. 모델 layer는 확률적 방어이고, containment는 구조적 방어다.
- 사람 승인 버튼이 있다고 해서 안전한 것은 아니다. 승인 피로가 생기면 위험한 요청도 습관적으로 통과될 수 있다.
- Egress allowlist는 “허용된 도메인”보다 “허용된 기능”이 중요하다. 같은 도메인 안에서도 파일 업로드, 외부 계정 token, server-side fetch는 별도 공격 표면이 될 수 있다.
- 이 글은 Anthropic 공식 엔지니어링 설명이므로, 제품의 강점을 보여주는 관점도 포함되어 있다. 독립 사고 사례와 다른 vendor 설계도 함께 봐야 한다.
관련 문서
- Agent containment
- Managed agents
- AI 시스템의 감사 가능성
- Agent observability
- AWS AgentCore와 Assurance Assistant로 보는 기업용 AI agent 운영 신호