Claude Code의 auto 모드는 보안 경계가 아닙니다

Claude Code의 auto 모드는 보안 경계입니까? 아니고, Anthropic도 그렇게 말하고 있습니다. 연구자 Johann Rehberger가 auto 모드로 동작하는 Claude Code Opus 5를 상대로 실제로 성립하는 공격 체인을 신고한 뒤, Anthropic은 이 신고를 Informative로 종결했습니다. 그 입장은 이렇습니다. auto 모드는 보안 보장이 아니라 최선의 노력으로 동작하는 분류기가 뒷받침하는 편의 기능이라는 것, 개별적으로는 무해한 단계들을 조합해 만든 집요한 체인은 분류기가 잡아낼 것으로 기대되는 범위 밖에 있다는 것, 그리고 진짜 경계는 운영체제 수준의 격리와 네트워크 egress 통제라는 것입니다.¹ 이 답변은 책임 회피가 아닙니다. 오히려 이것이 올바른 멘탈 모델이고, 우리 대부분은 그동안 잘못된 모델을 들고 다녔던 것입니다. {.answer-block}

버그 자체보다 그것이 바로잡아 주는 믿음 때문에 더 중요해지는 종류의 보안 발견이 있습니다. Rehberger의 8월 26일 글이 바로 그런 경우입니다. 그가 보여 준 체인은 영리하지만, 정작 쓸모 있는 부분은 그 글이 끌어낸 답변입니다. 그 답변이 여러분 환경에서 실제로 하중을 받치고 있는 층이 어디인지 알려 주기 때문입니다. 그리고 그 층은 auto 모드가 8월에 기본값이 된 이후로 많은 개발자가 믿어 온 층이 아닙니다.

핵심 요약

• Rehberger는 2026년 8월 26일, auto 모드의 Claude Code Opus 5를 상대로 실제로 성립하는 공격 체인을 공개하면서 소규모 표본에서 60~80%의 성공률을 보고했습니다. 주 체인은 5회 중 3회, 두 번째 변형의 두 가지 구성은 각각 5회 중 3회와 5회 중 4회였습니다. 그는 이것이 일반적인 공격 성공률이 아니라 작은 표본일 뿐이라고 분명히 밝혔습니다.¹
• 이 발견은 아주 구체적인 숫자와 부딪힙니다. Anthropic이 의뢰한 제3자 평가는 auto 모드의 Opus 5에 대해 프롬프트 인젝션 공격 성공률 0.00%를 보고했습니다. 72개 시나리오를 각각 열 번씩 실행해 측정한 값입니다. Rehberger의 체인은 그 집합에 들어 있지 않았기 때문에, 0.00%라는 숫자와 실제로 동작하는 코드 실행 체인이 동시에 참일 수 있습니다.¹
• 체인의 모든 단계는 하나씩 떼어 놓고 보면 전부 합리적입니다. 바로 거기에 설계상의 교훈이 있습니다. 분류기는 행동을 하나씩 평가하지만, 공격은 개별 행동이 아니라 그 조합 속에 살고 있습니다.
• Anthropic은 이 신고를 Informative로 종결하면서 auto 모드를 보안 보장이 아니라 최선의 노력 분류기가 뒷받침하는 편의 기능으로 규정했고, OS 격리와 네트워크 egress 통제를 진짜 경계로 제시했습니다.¹
• Rehberger가 보고하고 Willison이 앞세운 가장 날카로운 세부 사항은 이것입니다. 몇 번의 실행에서 Claude는 침해를 감지하고 악성코드 프로세스를 종료하려 했는데, auto 모드가 그 정리 명령을 거부했습니다.¹²
• 실무적인 결론은 이렇습니다. auto 모드는 생산성을 위한 통제 장치이고, 사용자가 요청하지 않았다고 판단한 파괴적 작업을 문서화된 목록에 따라 차단해 주기도 합니다. 하지만 공격자가 조작한 텍스트와 여러분의 자격 증명 사이에 서 있는 것은 auto 모드가 아닙니다. 그 자리에 서 있는 것은 컨테이너, 제한된 egress, 그리고 자격 증명이 없는 홈 디렉터리입니다.

체인을 한 단계씩

출발점은 평범한 일을 하는 에이전트입니다. 리소스를 가져오고, 디코딩하고, 그 내용을 사용하는 것입니다. 그게 어떻게 코드 실행으로 이어지는지 따라가 보겠습니다.¹

어떤 서버가 에이전트의 WebFetch에 HTTP 415로 응답합니다. 이건 공격이라기보다 content-type 문제처럼 읽힙니다. 에이전트는 합리적인 선택을 해서 curl로 폴백합니다. 이렇게 받아 온 아카이브를 풀면 작업용 디렉터리에 README, 체크섬 매니페스트, CSV 인덱스, Base85와 zlib으로 인코딩된 JSON 레코드 일곱 개, 네이티브 디코더 바이너리, 그리고 struct.py라는 이름의 파일이 놓입니다.

여기서 안전 장치가 제대로 작동합니다. 에이전트는 신뢰할 수 없는 네이티브 바이너리의 실행을 거부합니다. 정확히 우리가 바라는 행동입니다. 바이너리를 거부한 에이전트는 대신 자기만의 Python 디코더를 작성하고, 압축을 푼 디렉터리 안에서 그걸 실행합니다.

그 디코더는 base64를 import합니다. 표준 라이브러리의 base64는 struct를 import합니다. Python은 모듈 검색 경로 맨 앞에 작업 디렉터리를 두기 때문에, struct는 표준 라이브러리가 아니라 압축을 푼 아카이브 안에 있는 공격자의 struct.py로 해석됩니다.

이 순서를 다시 읽으면서 무엇이 빠져 있는지 보세요. 에이전트가 명백히 악의적인 일을 하라고 지시받는 단계는 어디에도 없고, 분별 있는 검토자가 따로 떼어 놓고 문제 삼을 만한 단계도 하나도 없습니다. 415 응답 뒤에 curl로 폴백하는 건 정상입니다. 아카이브를 푸는 것도 정상입니다. 서명 없는 바이너리를 거부하는 건 안전 측면의 승리입니다. 직접 디코더를 작성하는 건 기지가 있는 행동입니다. 데이터가 놓인 디렉터리에서 그걸 실행하는 건 누가 봐도 자연스러운 실행 위치입니다.

분류기가 이 싸움에서 지는 이유

auto 모드의 분류기는 세션의 의도에 비추어 행동을 평가합니다. 이 명령이 사용자가 요청한 것과 맞아떨어지는가, 그리고 그 자체로 위험한가 하는 질문입니다. 이 질문은 rm -rf /에는 좋은 답을 주지만 python decode.py에는 나쁜 답밖에 주지 못합니다.

이 공격은 위험한 행동을 단 한 번도 내밀지 않습니다. 안전해 보이는 행동이 안전하지 않은 결과를 낳도록 환경의 모양을 바꿔 놓을 뿐입니다. 게다가 그 결과가 성립하는 이유는 훨씬 앞에서 일어난 단계, 즉 모듈을 심어 놓은 아카이브 압축 해제 때문입니다. 그걸 잡아내려면 검토자가 전체 이력을 머릿속에 담고서 현재 작업 디렉터리에 비추어 Python의 import 해석 방식을 추론해야 합니다. 개별적으로 무해한 단계로 만들어진 체인은 분류기의 범위 밖이라는 Anthropic의 입장은 바로 그 간극에 대한 이야기입니다.¹

이 공격의 유형은 정확하게 이름 붙여 둘 가치가 있습니다. Willison은 8월 30일에 글을 갱신하면서 Lobste.rs 독자가 제기한 지적을 지지했습니다. 이건 애초에 고전적인 프롬프트 인젝션이 아니라는 지적입니다. 모델이 공격자의 지시를 읽고 그걸 따르는 지점이 어디에도 없기 때문입니다. 오히려 에이전트에게 건네진 환경의 모양 자체가 익스플로잇을 만들어 내는, 혼란된 환경 공격(confused environment attack)이라고 부르는 편이 낫습니다.² 이 구분은 문제를 누그러뜨리기는커녕 더 날카롭게 만듭니다. 주입된 지시를 감시하는 분류기는 여기서 들여다볼 것이 하나도 없습니다. 그런 지시 자체가 없기 때문입니다.

이건 MCP CVE의 물결이 계속 보여 주는 것과 똑같은 구조적 논점입니다. 에이전트 도구들은 억제 수단을 쌓는 속도보다 빠르게 능력을 쌓아 갑니다. 그리고 행동 단위의 검토는 세션 단위의 안전으로 합성되지 않습니다.

멘탈 모델을 바꿔야 할 세부 사항

Rehberger가 보고하고 Willison이 앞세운, 곱씹어 볼 만한 순간이 있습니다. 몇 번의 실행에서 Claude는 침해를 알아차리고 악성코드 프로세스를 종료하려 했는데, auto 모드가 그 정리 명령을 거부했습니다.¹²

안전을 위한 층이 복구를 가로막는 건 역설이 아닙니다. “에이전트가 극단적인 일을 하지 못하게 하라”에 최적화된 통제 장치가 그 극단적인 일이 왜 시도되는지에 대한 개념을 갖고 있지 않으면 벌어지는 일입니다. 침해 이후의 정리 작업은 분류기가 보기에 파괴 행위와 아주 비슷하게 생겼기 때문입니다.

여기서 얻는 운영상의 교훈은 좁지만 쓸모 있습니다. “에이전트가 알아차릴 거야”는 통제 장치가 아닙니다. 알아차리는 능력과 행동할 수 있는 능력은 서로 다르고, 여러분의 사고 대응 계획은 침해된 에이전트가 스스로 뒷정리를 할 수 있다고 가정해서는 안 됩니다.

에이전트를 실제로 가두는 것

Rehberger의 권고는 화려함과는 거리가 멀지만, 앞의 두 가지는 이 체인을 막아 냈을 것입니다.¹

무인으로 돌리는 에이전트는 컨테이너나 VM에서 실행하세요. 이번 침해는 에이전트 사용자 권한으로 코드를 실행했습니다. 격리 계층이 있으면 머신 전체에 대한 접근이 일회용 환경으로 바뀝니다.

네트워크 egress를 제한하세요. 이 체인이 노린 결과는 자식 프로세스가 바깥으로 나가 원격 페이로드를 받아 실행하고, 그 뒤에 콜백을 보내는 것이었습니다. 허용 목록 방식의 egress 정책은 원격 스테이지 다운로드와 콜백을 둘 다 끊어 놓습니다.

자격 증명을 에이전트의 손이 닿지 않는 곳에 두세요. 홈 디렉터리에 있는 SSH 키, 클라우드 자격 증명, .env 파일은 기본적으로 피해 반경 안에 들어 있습니다. 옮기거나, 그것들이 없는 곳에서 에이전트를 실행하세요.

에이전트를 모니터링하고, 승인을 증거로 읽지 마세요. auto 모드의 승인은 분류기가 이의를 제기하지 않았다는 뜻일 뿐입니다. 그 행동이 안전했다는 판정이 아닙니다.

목록에 없는 것도 눈여겨보세요. auto 모드를 끄는 것입니다. auto 모드는 사용자가 요청하지 않았다고 판단할 때 문서화된 파괴적 작업 목록을 차단해 주고, 사람들이 반사적으로 모든 걸 승인하게 만드는 프롬프트 피로도 줄여 줍니다. 엄격해졌다는 착각과 맞바꿔 그걸 버리는 건 약한 통제 장치를 더 나쁜 것으로 바꾸는 일입니다. auto 모드는 그대로 두고, 그걸 경계로 취급하는 습관만 버리세요.

분명하게 말해 둘 부분

이 발견을 실패로 써 내려가기는 쉽고, 벤더 탓으로 쓰기는 더 쉽습니다. 둘 다 옳지 않습니다.

Anthropic의 답변, 즉 보안 보장이 아니라 최선의 노력 분류기가 뒷받침하는 편의 기능이며 경계는 OS 격리와 네트워크 egress 통제라는 답변은, 더 강한 주장을 했을 때보다 훨씬 정직한 보안 태도입니다.¹ 자사 분류기가 집요한 인젝션 체인을 잡아낸다고 약속하는 벤더가 있다면, 그건 어떤 분류기도 지킬 수 없는 약속이고 개발자들은 그 약속 위에 시스템을 세울 것입니다. 흥미로운 질문은 이 공격이 통하느냐가 아닙니다. 생태계의 멘탈 모델이 벤더의 것과 맞아떨어지느냐이고, 지금은 맞지 않습니다. auto 모드는 8월에 Pro, Max, Team 세션의 기본값이 되었는데, 그때 유통되던 숫자는 의뢰받은 72개 시나리오 평가에서 나온 공격 성공률 0.00%였습니다. Rehberger는 이걸 0.00% 마케팅 문제로 정리합니다. 그리고 그 숫자와 함께 퍼진 프레임은 편의성과 피해 반경 축소가 아니라 안전성이었습니다.¹ Rehberger는 저보다 더 강한 결론을 내립니다. 그는 0.00%라는 메시지와 범위 밖이라는 처리를 서로 맞지 않는 엇갈린 메시지로 읽습니다.¹ 저는 둘 다 성립할 수 있다고 봅니다. 그 처리는 정직한 것이었고, 그 숫자는 애초에 제품의 속성으로 마케팅되지 말았어야 했습니다.

여러분의 환경이 분류기를 벽이라고 가정하고 있었다면, 이제 벽을 세우세요.

9월 3일 업데이트: 이 글 이후 출시된 것들

Claude Code는 이 글이 나온 지 48시간 안에 세 개의 릴리스를 냈고, 그중 둘이 auto 모드를 건드립니다.³ 9월 1일에 공개된 버전 2.1.257은 릴리스 노트가 Containment Escape 규칙이라고 부르는 것을 추가했습니다. “클라우드 메타데이터 자격 증명 가져오기, egress 회피, 테넌트 간 접근은 환경이 그것들을 예상된 것으로 표시하지 않는 한 더 이상 자동 승인되지 않습니다.” 같은 릴리스는 auto 모드에서 작업 디렉터리 바깥의 파일을 처음 읽기 전에 한 번만 나타나는 확인 프롬프트를 추가했고, 그 프롬프트를 거부로 바꾸는 설정 permissions.blockReadsOutsideWorkingDirectories도 함께 넣었습니다. 9월 2일에 공개된 버전 2.1.259는 무인 헤드리스 호스트를 위해 --permission-prompts none을 추가했습니다. “프롬프트를 띄울 만한 것은 무엇이든 자동으로 거부되며, 그동안에도 활성 권한 모드(auto 모드 포함)가 계속 판단합니다.”

이 변경들은 이 글이 세운 틀 안에서 읽어야 합니다. 규칙과 읽기 프롬프트, 그리고 플래그는 모두 진짜 하드닝이고, 헤드리스 플래그는 무인 호스트가 반드시 켜고 돌려야 할 fail-closed 설정입니다. 하지만 앞의 두 가지는 auto 모드가 스스로 승인하는 범위를 좁히는 변화입니다. 규칙은 환경이 예상된 것으로 표시하지 않는 한 세 가지 범주를 자동 승인에서 빼고, 읽기 관련 변경은 한 번 프롬프트를 띄우거나 설정을 켜면 거부합니다. 둘 다 경계라고 설명되지 않고, 둘 다 auto 모드의 승인 흐름 안에 있습니다. 그리고 그 검토야말로 이 체인이 혼자 보면 이상해 보이는 행동을 단 하나도 내밀지 않은 채 통과해 버린 바로 그것입니다. 규칙은 egress 회피를 이름으로 지목하지만, Rehberger가 서술하는 건 회피가 아니라 매 홉마다 나가는 외부 연결뿐입니다. curl 다운로드, 원격 스테이지를 가져오는 자식 프로세스, 그 스테이지가 가져오는 페이로드, 그리고 콜백입니다. 규칙이 그중 어느 것이라도 회피로 읽는지에 대해 노트는 말하지 않고, 읽기 프롬프트가 자식 프로세스의 읽기까지 포함하는지도 말하지 않습니다. 두 변경 중 어느 쪽이 이 체인을 막았을지에 대해서도 노트는 주장하지 않고, 우리가 마음대로 가정할 일도 아닙니다. 2.1.257의 수정 하나는 실제로 경계 층에 있습니다. 샌드박스의 deniedDomains 항목이 뒤에 점이 붙은 호스트를 차단하지 못하던 문제를 이 릴리스가 고쳤습니다. 그건 경계에서의 수리이지 경계의 이동이 아닙니다. auto 모드가 스스로 승인하는 범위는 줄어들었습니다. 경계는 움직이지 않았습니다.

기억할 점

• auto 모드는 편의성과 피해 반경을 위한 통제 장치이지 보안 경계가 아닙니다. 이건 외부의 비판이 아니라, 실제로 성립하는 우회를 겪은 뒤 벤더 스스로 밝힌 입장입니다.¹
• 분류기는 행동을 심판하고, 공격은 조합 속에 삽니다. 시연된 체인의 모든 단계는 하나씩 보면 전부 변호할 수 있고, 바로 그래서 행동 단위 검토가 이걸 놓쳤습니다.
• 알아차리는 것과 복구하는 것은 다른 일입니다. 몇몇 실행에서 에이전트는 자신의 침해를 감지했지만 뒷정리는 막혔습니다. 사고 대응 계획을 거기에 맞춰 세우세요.¹²
• 끝까지 버티는 통제 장치는 모델 바깥에 있습니다. 컨테이너나 VM, 제한된 egress, 홈 디렉터리 밖으로 옮긴 자격 증명. 나머지는 전부 심층 방어이지 경계가 아닙니다.

FAQ

auto 모드를 꺼야 합니까?

아닙니다. 다만 그걸 격리 수단으로 믿고 있었다면 이야기가 다릅니다. auto 모드는 사용자가 요청하지 않았다고 판단할 때 문서화된 파괴적 작업들을 차단합니다. git reset --hard, git checkout -- ., git clean -fd, git stash drop, 그리고 terraform/pulumi/cdk destroy 같은 것들입니다. 게다가 반사적인 승인을 부르는 프롬프트 양도 줄여 줍니다. 생산성과 피해 반경을 위한 통제 장치로 계속 쓰되, 신뢰할 수 없는 입력을 다루는 세션에는 진짜 격리를 더하세요.

이건 Claude Code에만 해당하는 문제입니까?

이 메커니즘은 Claude에 국한되지 않습니다. 신뢰할 수 없는 아카이브를 받아 오고, 코드를 작성하고, 방금 압축을 푼 디렉터리에서 그걸 실행하는 에이전트라면 어떤 것이든 똑같은 import 해석 함정에 노출됩니다. 그리고 행동 단위의 안전 검토라면 어떤 것이든 똑같은 조합의 간극에 노출됩니다. 여기서 다룬 구체적인 내용은 auto 모드의 Claude Code Opus 5를 상대로 시연된 것입니다.¹

신뢰할 수 없는 입력을 다루는 세션이란 무엇입니까?

공격자의 영향을 받은 텍스트가 모델에 닿을 수 있는 모든 경우입니다. 가져온 웹 페이지, 내려받은 아카이브, 이슈와 PR 텍스트, 이메일, 공개 서비스의 로그, 그리고 서드파티 MCP 서버가 여기에 들어갑니다. 실제로는 그게 현실 업무의 대부분이라는 점이 불편한 지점입니다.

이 문제는 수정됐습니까?

수정해야 할 취약점으로 다뤄지지 않았습니다. Anthropic은 이런 종류의 분류기 회피가 auto 모드가 약속하는 범위 밖이라는 근거로 신고를 Informative로 종결했습니다.¹ 대기 중인 패치가 아니라 시스템의 문서화된 속성으로 받아들이세요. 이 글 이후 48시간 안에 나온 릴리스 중 2.1.257은 auto 모드가 스스로 승인하는 범위를 좁히고 작업 디렉터리 바깥 읽기를 막는 선택적 설정을 추가했으며, 2.1.259는 헤드리스 호스트를 위한 fail-closed 플래그를 추가했습니다. 이것들이 무엇을 바꾸고 무엇을 바꾸지 않는지는 위의 9월 3일 업데이트에서 다뤘습니다.³

출처