AI 에이전트 보안은 모델보다 실행 환경에서 갈려요

AI 에이전트 보안은 모델보다 실행 환경에서 갈려요

AI 뉴스 썸네일

AI 에이전트가 파일을 읽고, 코드를 실행하고, 외부 도구를 부를수록 보안 질문도 달라져요. Anthropic은 Claude를 제품별로 어떻게 가두는지 공개하면서, 모델이 나쁜 행동을 하지 않게 설득하는 것보다 실행 환경에서 가능한 행동을 줄이는 쪽에 더 무게를 뒀어요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
에이전트 보안	Claude 제품군은 컨테이너, OS 샌드박스, 로컬 VM을 다르게 써요	같은 AI 모델이라도 어디서 실행되는지에 따라 위험 범위가 달라져요
권한 승인	Claude Code 사용자들은 권한 요청의 약 93%를 승인했어요	사람에게 계속 묻는 방식은 승인 피로 때문에 약해질 수 있어요
격리 전략	claude.ai는 임시 컨테이너, Claude Code는 개발자용 샌드박스, Cowork는 VM을 써요	사용자 역량과 제품 용도에 맞춰 격리 강도를 조정해야 해요
남은 위험	허용된 도메인, 로컬 설정, 외부 도구 출력도 우회 경로가 될 수 있어요	보안 경계는 모델 답변보다 파일·네트워크·토큰 흐름에서 더 자주 깨져요

1. Claude를 안전하게 만드는 일은 권한을 줄이는 일에 가까워요

Anthropic 글의 핵심은 단순해요. 에이전트가 똑똑해질수록 실패 확률은 낮아질 수 있지만, 한 번 실패했을 때 닿을 수 있는 범위는 더 넓어져요. 내부 서비스 접근, 코드 실행, 파일 읽기, 외부 API 호출이 붙으면 작은 실수도 실제 피해로 이어질 수 있어요. 그래서 Anthropic은 행동을 사후에 감시하는 방식보다, 애초에 접근 가능한 파일과 네트워크를 좁히는 방식을 더 중요하게 봐요. 2

이 관점은 AI 제품을 만드는 팀에 꽤 현실적인 기준을 줘요. 모델이 "하지 말라"는 지시를 잘 따르는지보다, 샌드박스 밖 파일을 읽을 수 없는지, 승인되지 않은 외부 주소로 데이터를 보낼 수 없는지, 임시 작업공간이 세션 뒤에 사라지는지가 더 직접적인 안전장치예요. 개발자 도구나 업무 자동화 제품을 붙일 때도 같은 질문을 먼저 던져야 해요. AI 기능의 성능보다 실행 경계가 먼저예요.

2. 사람에게 계속 승인받는 방식은 생각보다 빨리 무뎌져요

Claude Code는 한동안 사용자가 각 행동을 승인하는 방식으로 위험을 줄였어요. 하지만 Anthropic이 공개한 텔레메트리에서는 사용자가 권한 요청의 약 93%를 승인했어요. 권한 창이 너무 자주 뜨면 처음에는 꼼꼼히 보던 사람도 점점 기계적으로 누르게 돼요. 보안 UX에서 오래된 문제인 알림 피로가 AI 에이전트에서도 그대로 나온 셈이에요. 2

Anthropic은 이 문제를 줄이려고 Claude Code에 OS 수준 샌드박스를 넣었어요. macOS에서는 Seatbelt, Linux에서는 bubblewrap을 써서 읽기와 작업공간 안 쓰기는 허용하고, 네트워크는 기본으로 막는 식이에요. 그 결과 권한 요청이 84% 줄었다고 해요. 중요한 점은 승인 버튼을 더 예쁘게 만든 게 아니라, 물어볼 필요가 줄어드는 구조로 바꿨다는 데 있어요.

3. 제품마다 격리 방식이 다른 이유가 있어요

claude.ai의 코드 실행은 서버 쪽 임시 컨테이너에서 돌아가요. 세션별 파일시스템은 휘발성이어서 오래 남지 않고, 사용자 로컬 머신에서 코드가 실행되지 않아요. 이 방식은 피해 범위를 작게 만들지만, 사용자의 실제 작업공간에 깊게 들어가기 어렵다는 한계도 있어요. 웹 채팅 안에서 안전하게 실행하는 데 맞춘 선택이에요. 1

Claude Code는 개발자 PC 위에서 움직여요. 개발자는 셸 명령과 저장소 구조를 읽을 수 있고, 에이전트가 이상한 방향으로 가면 중간에 끊을 가능성도 비교적 높아요. 그래서 완전한 VM보다 낮은 마찰의 OS 샌드박스가 어울려요. 반대로 Claude Cowork는 일반 지식 노동자를 겨냥한 제품이라 bash 명령을 사용자가 판단한다고 기대하기 어려워요. Anthropic은 이쪽에 로컬 VM을 두고, 선택한 작업공간만 마운트하는 더 강한 격리를 적용했어요. 2

이 차이는 AI 기능을 붙이는 기업에도 그대로 적용돼요. 개발자용 코딩 도구, 사내 문서 검색 봇, 고객지원 자동화, 데이터베이스 조회 에이전트는 모두 다른 위협 모델을 가져요. 같은 모델을 쓰더라도 읽기 전용인지, 쓰기 권한이 있는지, 외부 전송이 가능한지에 따라 제품 안전성은 완전히 달라져요.

4. 허용된 경로도 데이터 유출 통로가 될 수 있어요

가장 흥미로운 부분은 실패 사례예요. Cowork의 이그레스 허용 목록은 제품 동작에 필요한 api.anthropic.com 트래픽을 허용했어요. 그런데 공격자가 통제하는 API 키가 작업공간 파일에 들어가면, Claude가 그 키로 Anthropic Files API를 호출해 다른 파일을 공격자 계정으로 올릴 수 있었어요. 목적지가 신뢰된 도메인이라는 사실만으로는 충분하지 않았던 거예요. 2

Anthropic은 허용 목록을 단순 목적지 필터가 아니라 특정 능력을 열어주는 장치에 가깝게 봐요. 어떤 도메인을 허용하면 그 도메인에서 가능한 모든 기능이 공격 표면이 돼요. 그래서 Cowork 안에는 자체 API 트래픽을 가로채는 방어용 중간 프록시를 두고, VM이 발급받은 세션 토큰이 있는 요청만 통과시키는 식으로 바꿨어요. 여기서도 답은 모델 경고가 아니라 네트워크와 토큰 흐름을 좁히는 쪽이에요.

5. 로컬이라는 이유만으로 믿으면 안 돼요

Claude Code에서 발견된 취약점도 비슷한 교훈을 줘요. 사용자가 저장소를 신뢰한다고 누르기 전에 프로젝트 설정 파일을 먼저 읽으면, 공격자가 커밋한 로컬 설정이 실행될 수 있어요. Anthropic의 조언은 프로젝트 열기, 설정 로드, 로컬호스트 리스너 같은 흐름을 인터넷에서 들어오는 요청처럼 다루라는 쪽이에요. 개발자 PC 안에 있는 파일이라고 해서 안전한 입력은 아니에요. 2

외부 도구도 마찬가지예요. MCP 서버나 커넥터 자체가 안전해도, 그 도구가 돌려주는 README, 이슈, 문서, 웹페이지 안에는 에이전트 행동을 비틀 수 있는 문장이 들어갈 수 있어요. 도구를 승인했다는 사실과 도구가 반환한 콘텐츠를 믿어도 된다는 말은 달라요. 앞으로 에이전트 보안은 "어떤 도구를 연결했나"보다 "도구 출력이 어떤 권한으로 이어지나"를 더 많이 보게 될 거예요.

왜 중요한가요

AI 에이전트가 업무 도구가 되면 보안팀과 제품 팀이 같은 설계를 봐야 해요. 모델 평가 점수만으로는 충분하지 않아요. 파일시스템 경계, 네트워크 차단, 도메인 허용 목록, 토큰 출처, 로그 감시가 제품 경험의 일부가 돼요. Anthropic 사례는 에이전트 보안의 기준이 대화 품질에서 실행 환경 설계로 옮겨가고 있음을 잘 보여줘요. 2

특히 기업용 AI 제품을 만들 때는 사용자를 한 덩어리로 보면 위험해요. 개발자는 낮은 마찰을 원하고, 일반 업무 사용자는 더 강한 기본 보호가 필요해요. 읽기 전용 업무, 코드 실행 업무, 고객 데이터 접근 업무를 같은 샌드박스로 묶으면 한쪽에서는 불편하고 다른 쪽에서는 위험해져요. 에이전트가 할 수 있는 일을 먼저 줄이고, 그 안에서 모델이 잘 행동하도록 만드는 순서가 더 안전해요.

참고 자료

1. Anthropic은 제품 전반에서 Claude를 어떻게 봉쇄할까 — GeekNews
2. How we contain Claude across products — Anthropic Engineering