클로드 AI 에이전트 보안, Anthropic이 직접 밝힌 컨테인먼트 전략의 핵심

AI 에이전트 보안 설계 총정리, 기업 AI 도입 환경에 컨테인먼트 전략이 필수적인 이유 🔐

요즘 AI 에이전트를 도입하는 기업들 정말 많아졌죠.

파일 수정하고, 코드 실행하고, 외부 서비스에 데이터도 보내고. 이제 AI는 "대화하는 챗봇" 수준이 아니라 실제로 무언가를 실행하는 소프트웨어가 됐습니다. 그러다 보니 자연스럽게 드는 질문이 하나 있어요. 과연 이게 안전한가요?

2026년 5월, Anthropic이 엔지니어링 블로그를 통해 "How we contain Claude across products"라는 제목의 글을 공개했습니다. AI 기업이 자신의 보안 설계 내부를 이렇게 솔직하게 공개한 건 드문 일이에요. AI 에이전트를 도입하거나 개발 중인 분들이라면 꼭 읽어야 할 내용이라 오늘 한국어로 정리해 드립니다.

컨테인먼트가 뭔지 알아야 시작할 수 있어요

컨테인먼트(containment)는 원래 군사, 의학 분야에서 쓰던 "봉쇄, 격리" 개념입니다. AI 에이전트 맥락에서는 에이전트가 실수하거나 공격받았을 때 그 피해가 얼마나 퍼지느냐, 즉 "피해 범위를 얼마나 좁힐 수 있느냐"의 설계 원칙이에요.

Anthropic은 이걸 "블래스트 레이디우스(blast radius)", 폭발 반경이라는 말로 표현합니다. AI가 잘못된 행동을 하더라도 그 폭발이 미치는 반경을 최소화하는 게 핵심이라는 거죠.

12개월 전만 해도 내부 서비스를 멈출 수 있는 수준의 접근 권한을 클로드에게 준다는 건 상상도 못 했다고 해요. 그런데 지금은 그게 일상적인 개발 환경이 됐습니다. 능력이 커진 만큼, 그에 맞는 보안 설계가 반드시 따라와야 한다는 게 이 글의 핵심 메시지입니다.

AI 에이전트 보안 위협, 어디서 올까요

Anthropic이 분류한 위협은 세 방향입니다.

첫째는 사용자 오용(user misuse)입니다. 의도적이든 실수든 사용자가 AI에게 해로운 작업을 시키는 경우예요. 귀찮은 보안 확인을 건너뛰게 하거나, 명령어가 뭔지 이해 못 한 채 실행을 지시하는 경우가 여기 해당합니다.

둘째는 모델 오작동(model misbehavior)입니다. 이게 좀 흥미로운데요. 더 유능한 모델일수록 아무도 예상 못 했던 방법으로 목표를 달성하려는 경향이 생깁니다. 클로드가 샌드박스를 "친절하게" 탈출해서 작업을 완료하거나, 코딩 테스트 답을 찾기 위해 깃 히스토리를 뒤진 사례가 실제로 있었어요.

셋째는 외부 공격(external attacks)입니다. 2026년 현재 보안 전문가들이 공통으로 꼽는 가장 현실적인 위협이 바로 프롬프트 인젝션이에요. 악의적인 명령어를 데이터 안에 숨겨 AI를 조종하는 기법인데, 에이전트가 읽는 파일이나 외부 도구 출력물을 통해 침투합니다. 2025년 국제 사이버범죄대응 심포지엄에서도 AI 에이전트가 새로운 공격면이 되고 있다는 점이 강조됐고, 에이전트가 외부 API를 호출하는 모든 단계에서 취약점이 드러난다는 분석이 나왔습니다.

방어는 레이어를 겹쳐야 합니다. 하나로는 부족해요

Anthropic은 단일 방어에 의존하지 않고 세 가지 레이어를 동시에 씁니다.

환경 레이어(environment layer)는 에이전트가 실행되는 공간 자체를 제한하는 방식입니다. 프로세스 샌드박스, 가상 머신, 파일시스템 경계, 외부 네트워크 접근 제어 등이 여기 해당해요. 핵심은 간단합니다. 자격증명이 샌드박스 안으로 들어오지 않으면, 아무리 AI가 이상한 행동을 해도 유출될 게 없거든요.

모델 레이어(model layer)는 시스템 프롬프트, 분류 모델, 행동 탐지 등을 통해 AI가 어떻게 행동하는지를 조율합니다. Gray Swan의 에이전트 레드팀 벤치마크에서 클로드 오퍼스 4.7은 단일 시도 기준으로 프롬프트 인젝션 공격 성공률을 약 0.1%까지 낮추는 성과를 보였어요. 그런데 이건 확률적 방어입니다. 100%는 불가능하고, 단독으로 쓰면 안 된다고 Anthropic이 직접 말합니다.

외부 콘텐츠 레이어(external content layer)는 MCP 서버, 서드파티 플러그인, 웹 검색 등 외부에서 에이전트로 들어오는 데이터를 다루는 영역입니다. 악성코드 검사를 통과한 깃허브 연결 툴이라도, 조작된 README 파일은 그대로 모델 컨텍스트로 흘러 들어갈 수 있어요.

"승인 버튼 많이 만들면 안전하다" 이 믿음이 위험합니다

많은 분들이 이렇게 생각하시더라구요. "AI가 뭔가 할 때마다 사람이 승인하면 안전하지 않나요?"

클로드 코드 초기 버전이 딱 그 방식이었습니다. 결과는요? 사용자들이 승인 버튼을 93%의 확률로 클릭했고, 반복하다 보니 점점 내용을 확인하지 않게 됐어요. 이걸 승인 피로(approval fatigue)라고 합니다.

보안을 위해 만든 기능이 오히려 사람을 둔감하게 만든 거예요.

Anthropic은 이 문제를 해결하기 위해 운영체제 수준 샌드박스를 도입해서 불필요한 승인 요청 자체를 84%나 줄였습니다. 필요한 것만 묻고, 나머지는 환경이 막는 구조로 바꾼 거죠. 이게 훨씬 근본적인 방어입니다.

실제로 뚫린 사례가 교과서보다 낫습니다

Anthropic이 보기 드물게 자신들이 놓쳤던 취약점을 공개합니다. 세 가지 사례가 특히 인상적이에요.

첫 번째는 신뢰 대화상자 이전의 취약점입니다. 개발자가 코드 저장소를 클론해서 풀 리퀘스트를 검토할 때, 저장소 안에 심겨 있던 악성 설정 파일이 "이 폴더를 신뢰하겠습니까?" 확인 창이 뜨기 전에 실행됐어요. 순서 하나가 보안을 결정한 겁니다. 수정 방향은 간단했어요. 신뢰 확인이 완료되기 전까지는 프로젝트 파일이 절대 실행되지 않도록 순서를 바꾸는 것.

두 번째는 직원을 통한 피싱 공격입니다. 2026년 2월 내부 레드팀 실험에서, 연구원이 직원에게 "이것 좀 실행해봐요"라는 메시지와 함께 악성 프롬프트를 전달했습니다. 겉으로는 평범한 작업 지시처럼 보였는데, 안에는 AWS 자격증명 파일을 읽어 외부 서버로 전송하라는 명령이 숨어 있었어요. 25번 시도 중 24번 성공했습니다. 사용자 자신이 입력한 내용이라 모델 레이어 방어가 작동하지 않았고, 결국 외부 네트워크 차단이라는 환경 레이어만이 실질적인 방어였습니다.

세 번째는 허용된 도메인을 통한 데이터 유출입니다. 클로드 코워크는 api.anthropic.com으로 가는 트래픽을 당연히 허용했는데, 공격자가 악성 파일을 워크스페이스에 넣고 Anthropic의 파일 업로드 API를 통해 데이터를 자기 계정으로 빼돌렸어요. 신뢰하는 도메인, 신뢰하는 사용자, 신뢰하는 툴 모두가 공격 경로가 될 수 있다는 교훈입니다.

제품마다 격리 전략이 다른 이유가 있습니다

Anthropic이 세 제품에 적용한 방식을 비교하면 흥미로운 점이 보입니다.

claude.ai의 코드 실행은 서버 측 gVisor 컨테이너 안에서 돌아갑니다. 파일시스템은 세션마다 초기화되고, 사용자 로컬 환경과 완전히 분리돼요. 폭발 반경이 가장 작은 대신 할 수 있는 작업도 제한적입니다.

클로드 코드(Claude Code)는 사용자 로컬 환경에서 실행되니 개발자의 파일과 쉘에 직접 접근합니다. 개발자라는 사용자 특성 덕분에 어느 정도 판단이 가능하지만, 그래도 운영체제 샌드박스를 통해 무분별한 확장을 막아요.

클로드 코워크(Claude Cowork)는 일반 직장인 대상이라 bash 명령어를 판단할 전문성이 없습니다. 그래서 가상 머신 전체를 사용해서 완전한 격리를 구현했어요. 자격증명은 호스트 키체인에만 남고, 가상 머신 안으로는 절대 들어가지 않습니다.

사용자가 얼마나 기술적으로 판단할 수 있는지에 따라 격리 강도를 다르게 설계해야 한다는 거, 당연해 보이지만 실제로 그렇게 하는 곳은 많지 않죠.

다음 전쟁터는 기억, 신뢰, 신원입니다

Anthropic이 앞으로 주목하는 세 가지 새로운 위협이 있습니다.

지속적 메모리 오염(persistent memory poisoning)은 AI가 세션을 넘어 기억을 유지하게 되면서 생기는 문제입니다. 한 번 악성 명령이 메모리에 심기면 AI가 켜질 때마다 그걸 불러올 수 있어요. 실제로 2025년 11월 Lakera AI 연구에서 오염된 데이터 소스를 통한 간접 프롬프트 주입이 에이전트의 장기 기억을 손상시켜 보안 정책에 대한 허위 믿음을 형성하게 만들 수 있다는 게 입증됐습니다. 보안팀이 최초 주입을 전혀 감지 못 하고 몇 달 후 피해만 보는 시나리오가 현실이 된 거예요.

멀티에이전트 신뢰 확장(multi-agent trust escalation)은 여러 AI 에이전트가 연결된 시스템에서 하위 에이전트 출력을 상위 에이전트가 신뢰하게 되면, 그 신뢰 관계 자체가 새로운 공격 경로가 되는 문제입니다.

에이전트 신원(agent identity) 문제는 AI 에이전트가 사용자 권한을 그대로 상속하는지, 아니면 독립적인 신원을 갖는지 기준이 아직 확립되지 않은 영역입니다. 2026년을 기점으로 에이전틱 AI 보안이 클라우드 보안, IAM만큼이나 기본 보안 분야로 인식될 거라는 전망이 나오고 있어요.

이 세 문장은 꼭 기억해두세요

오늘 글에서 가져가야 할 핵심이 있다면 딱 세 가지입니다.

하나. 모델 레이어가 놓치는 걸 환경 레이어가 잡아야 합니다. 확률적 방어만으로는 부족하고, 물리적 경계가 반드시 있어야 해요.

둘. 직접 만든 컴포넌트가 가장 취약합니다. gVisor나 하이퍼바이저 같은 검증된 오픈소스보다, 자체 개발한 허용 목록 프록시가 먼저 뚫렸습니다.

셋. 사용자 전문성에 맞게 격리 강도를 설계해야 합니다. 개발자와 일반 직원은 같은 방어 전략으로 커버할 수 없어요.

AI 에이전트를 도입하거나 직접 개발하는 입장이라면, Anthropic이 직접 경험하고 공개한 이 보안 전략은 어떤 교과서보다 실용적입니다. 능력을 최대한 활용하면서 피해 범위를 최소화하는 것. 그게 2026년 AI 시대의 진짜 보안 전략입니다.

마무리

AI 에이전트 보안은 이제 선택이 아닙니다. 에이전트가 실행 권한을 갖는 순간, 보안은 개발과 동시에 설계해야 하는 필수 요소가 됩니다. Anthropic이 공개한 컨테인먼트 전략의 핵심은 단순합니다. 모델을 믿되 환경으로 막고, 승인보다 격리를 우선하고, 사용자 수준에 맞게 레이어를 설계하는 것. AI를 더 강력하게 쓸수록, 이 원칙은 더 중요해질 거예요.