오토 모드와 파이썬 모듈 섀도잉

Claude Code 오토 모드는 2026년 8월 중순부터 기본값입니다. 매번 승인을 누르지 않아도 에이전트가 알아서 명령을 실행하되, 위험한 동작은 분류기가 걸러줍니다. 편해졌습니다.

8월 26일에 공개된 공격은 그 분류기를 60~80% 확률로 통과합니다. 시작은 "이 웹사이트 요약해줘" 한 줄입니다.

공격 사슬

단일 인젝션이 아닙니다. 개별 단계가 전부 무해해 보이는 다섯 단계짜리 공격 체인입니다.

1. 도구를 바꿔 태웁니다. 서버가 WebFetch 요청에 HTTP 415(Unsupported Media Type)로 답합니다. 클로드는 이 도구로는 안 되겠다고 판단하고 curl로 갈아탑니다. 여기서 이미 샌드박스가 걸린 도구에서 셸 명령으로 넘어갔습니다.

2. 인코딩된 아카이브를 줍니다. 받은 내용은 Base85와 zlib으로 인코딩된 ZIP입니다. 사이트는 이걸 "노트 기록 아카이브"라고 소개합니다. 요약하려면 풀어야 합니다.

3. 자기 디코더를 쓰게 만듭니다. 사이트가 디코더 스크립트를 같이 제공하되, 클로드가 그걸 의심하고 직접 짜도록 유도합니다. 클로드는 남이 준 바이너리 디코더를 믿지 않고 자기 코드를 씁니다. 보안 판단으로는 옳은 선택입니다.

4. 자작 디코더가 base64를 import 합니다. 압축을 풀려면 당연히 필요합니다. 그런데 이 시점에 클로드는 압축 해제된 디렉터리 안에 들어와 있습니다.

5. 파이썬이 공격자 파일을 먼저 읽습니다. 표준 라이브러리 base64는 내부에서 struct를 import 합니다. 파이썬의 모듈 탐색 경로는 현재 작업 디렉터리를 앞쪽에 두므로, 표준 라이브러리 struct 대신 아카이브에서 풀린 공격자의 struct.py가 로드됩니다. import 시점에 난독화된 코드가 실행되고 원격 페이로드가 뜹니다.

클로드는 남이 준 디코더는 믿지 않지만, 자기가 쓴 디코더는 믿습니다.

0.00%와 80%

앤트로픽은 오토 모드를 발표하면서 독립 평가에서 어떤 공격도 성공하지 못했고 프롬프트 인젝션 성공률이 0.00%라고 밝혔습니다. 같은 시기 앤트로픽 쪽에서는 계층 방어로 미지의 공격에 대한 간접 프롬프트 인젝션을 사실상 0에 가깝게 낮출 수 있다는 이야기도 나왔습니다.

이번 실측은 60~80%입니다.

두 숫자는 둘 다 맞습니다. 0.00%는 고정 시나리오 72개에 대한 결과입니다. HN 댓글 하나가 이걸 정확히 짚었습니다. 그건 안전성 수치가 아니라 커버리지 수치입니다. 시나리오 72개를 전부 막았다는 건 시나리오 73번째가 없다는 뜻이 아닙니다.

고정 시나리오 평가와 적응형 공격자 사이에는 구조적 간극이 있습니다. 평가는 정해진 공격을 재생하고, 공격자는 실패한 지점을 보고 다음 시도를 고칩니다. 이번 공격이 페이로드를 다듬고 서브프로세스를 띄우느냐에 따라 60%에서 80% 사이를 오갔다는 것 자체가 그 반복의 흔적입니다.

앤트로픽은 이 보고를 보안 수정이 아니라 "Informative"로 분류했습니다. 오토 모드는 최선 노력 분류기가 뒷받침하는 편의 기능이지 보안 보증이 아니고, 모델의 동작은 설계대로 작동한 것이며, 개별적으로 무해한 행동으로 구성된 정교한 다단계 프롬프트 인젝션 사슬을 막도록 설계되지 않았다는 답변입니다.

이 답변은 사실 관계로는 정확합니다. 문제는 기본값입니다. 최선 노력 분류기를 기본으로 켜두면 사용자는 그게 경계선이라고 읽습니다. 오토 모드가 오히려 샌드박스를 안 써도 된다는 잘못된 안심을 준다는 지적이 커뮤니티에서 반복해서 나온 이유입니다.

되살아난 고전

파이썬 모듈 섀도잉은 새로운 기법이 아닙니다. 작업 디렉터리에 random.py를 만들어 두고 스크립트를 돌려본 사람이라면 다 아는 동작이고, sys.path에 현재 디렉터리가 앞쪽에 들어가는 설계에서 필연적으로 따라옵니다. 20년 전에도 있었고 지금도 있습니다.

이게 왜 지금 무기가 됐는지가 이번 건의 핵심입니다.

과거에는 이 함정에 빠지려면 개발자 본인이 신뢰하지 않는 코드를 자기 작업 디렉터리에 풀고 그 안에서 파이썬을 실행해야 했습니다. 그럴 일이 별로 없었습니다. 에이전트는 다릅니다. 임의의 URL에서 아카이브를 받고, 임의의 디렉터리로 들어가고, 그 자리에서 자기가 방금 짠 코드를 실행합니다. 이 세 가지가 한 세션 안에서 자동으로 이어지는 실행 모델은 최근에 생겼습니다.

그래서 이번 공격은 모델의 판단력을 속인 게 아닙니다. 클로드는 매 단계에서 합리적으로 행동했습니다. 도구가 안 되면 다른 도구를 쓰고, 출처 불명 바이너리는 의심하고, 필요한 표준 라이브러리를 import 했습니다. 목표가 탈취된 게 아니라 환경이 오염된 것이고, 그래서 프롬프트 인젝션으로 분류하는 게 맞느냐는 논쟁이 붙었습니다. 원문 저자도 실무자 쪽에서도 이 건을 고전적 인젝션이 아니라 오염된 환경 문제로 다시 규정했습니다.

분류가 어느 쪽이든 방어 권고는 바뀌지 않습니다. 다만 분류가 바뀌면 어디를 고쳐야 하는지가 바뀝니다. 프롬프트 인젝션이면 분류기를 개선하는 게 답이고, 환경 오염이면 분류기를 아무리 잘 만들어도 답이 아닙니다.

방어선의 위치

앤트로픽의 답변과 연구자의 결론이 여기서는 일치합니다. 실제 보안 경계는 모델 안이 아니라 OS 격리와 네트워크 송신 통제입니다.

보도와 논평은 대부분 여기서 끝납니다. 컨테이너를 쓰라, 네트워크를 막으라, 자격증명을 분리하라. 다 맞는 말인데 이 사건의 구체적 경로에 대한 답은 아닙니다.

이번 사슬을 끊는 가장 좁은 조치는 파이썬 인터프리터 쪽에 있습니다. 커뮤니티 논의에서 나온 것들입니다.

python -P script.py     # sys.path에서 스크립트 디렉터리·현재 디렉터리 제거 (3.11+)
python -I script.py     # isolated 모드. -P -E -s 를 모두 켬
PYTHONSAFEPATH=1 python script.py   # -P 와 동일한 효과를 환경변수로

-P는 파이썬 3.11에 들어간 PYTHONSAFEPATH 플래그입니다. sys.path 앞머리에서 스크립트 디렉터리와 현재 디렉터리를 빼버립니다. 이번 공격은 정확히 그 자리를 씁니다. 에이전트가 python을 부를 때 이 플래그가 기본으로 붙어 있었다면 5단계에서 끊깁니다.

이건 근본 대책이 아닙니다. 다른 언어의 유사한 로딩 규칙, LD_PRELOAD, 패키지 매니저의 설치 훅 등 같은 형태의 경로가 여럿 남습니다. 그래도 격리 컨테이너를 세팅하는 것보다 훨씬 싸고, 지금 당장 셸 별칭 한 줄로 걸 수 있습니다.

정리하면 층이 셋입니다. 가장 바깥은 컨테이너와 네트워크 송신 통제고, 중간은 에이전트가 코드를 실행하는 작업 디렉터리를 신뢰하지 않는 것이고, 가장 안쪽이 인터프리터 로딩 경로를 좁히는 것입니다. 오토 모드 분류기는 이 셋 중 어디에도 속하지 않습니다.

한 가지 더 남는 게 있습니다. 침해가 감지된 뒤 클로드가 스스로 정리 명령을 실행하려 했는데, 오토 모드가 그 명령을 막았습니다. 방어 기능이 공격은 통과시키고 복구는 차단한 셈입니다. 사고 후 대응까지 같은 분류기에 맡겨두면 이런 순서가 나옵니다.

참고: - Breaking Claude Code Opus 5 Auto Mode with Indirect Prompt Injection - Researcher shows how Claude Code can be tricked simply by asking it to summarize a website (The Register) - Claude Code runs malware despite "Auto Mode" security, tries to fix it, gets denied (Cybernews) - Simon Willison, Breaking Claude Code Opus 5 Auto Mode - Hacker News 토론 (#49506819) - PYTHONSAFEPATH / -P 옵션 (Python 3.11 문서)