11월 5일 Claude Code 저장소에 버그 보고 하나가 올라왔다. 작성자는 하루에 수십 통씩 사기 메일을 받고 있었고, 원인을 Claude Code에서 찾았다. 웹 검색을 맡기는 동안 Claude Code가 작성자의 이메일 주소를 HTTP 요청의 User-Agent 헤더에 넣어 여러 사이트로 보냈다는 것이다. 하루 만에 댓글이 60개를 넘었고, 비슷한 시기에 정체 모를 메일이 늘었다는 사용자와 로그에서 다른 도메인으로 주소가 나간 기록을 확인했다는 사용자가 이어졌다.
Anthropic은 원인을 인정했고, 다음 릴리스에서 계정 이메일을 모델에게 주지 않겠다고 밝혔다. 그 전까지 쓰라고 내놓은 임시 차단 장치는 막는 범위가 좁다. 코딩 에이전트에게 웹 작업을 맡기는 사람이라면 이 주소가 어디서 와서 어떻게 헤더에 들어갔는지 알아 둘 만하다. 같은 구조는 다른 도구에서도 생길 수 있다.
사이트가 요구한 연락처 칸에 내 주소가 들어갔다
User-Agent는 요청을 보내는 프로그램이 자기를 소개하는 헤더다. 브라우저는 이름과 버전을 적는다. 스크립트로 대량 요청을 받는 사이트 중에는 여기에 운영자 연락처까지 적으라고 요구하는 곳이 있다. 위키백과를 운영하는 위키미디어 재단의 정책은 봇을 돌리는 사람에게 다른 봇과 구별되는 이름과 함께 연락할 방법을 적으라고 하고, 그 방법으로 이메일 주소를 첫째로 꼽는다. 미국 증권거래위원회(SEC)의 공시 검색도 회사명 AdminContact@회사도메인 형식의 헤더를 요구한다.
모델은 이 규칙을 성실하게 따랐다. 문제는 연락처 칸에 넣을 주소를 이미 갖고 있었다는 점이다. Claude Code 팀의 리디아 할리(Lydia Hallie)는 해커뉴스 댓글에서 경위를 설명했다. 로그인한 계정 정보가 없을 때 Claude가 코드의 @author 같은 작성자 표기에 이름을 지어낸다는 보고가 있어서, 로그인 사용자의 계정 이메일을 모델이 받는 맥락에 넣었다. 그런데 Claude가 curl 같은 명령을 직접 작성할 때 그 주소를 User-Agent의 연락처로 쓰는 일이 생겼다.
이메일이 맥락에 들어간다는 사실은 처음 알려진 것이 아니다. 7월 25일에 올라온 다른 이슈는 Claude Code가 세션마다 시스템 프롬프트에 계정 이메일을 넣는데 동의를 받지도 않고 알리지도 않는다고 지적했다. 이 이슈에는 반응이 100개 넘게 붙었지만 지금도 열려 있다. 새 이슈의 댓글에는 오래된 보고는 두고 화제가 된 뒤에야 움직였다는 비판이 붙었다.
누가 이 동작을 기능으로 만든 것은 아니다. 사람이 짠 코드가 주소를 보냈다면 그 코드를 고치면 끝난다. 여기서는 모델이 상황에 맞춰 명령을 새로 쓰고, 그 명령에 무엇을 넣을지도 모델이 정한다. 맥락에 들어간 정보는 모델이 쓰는 모든 명령의 재료가 될 수 있다. 한 댓글 작성자는 자기 주소를 계정 정보가 아니라 git 설정에서 읽어 보냈다고 적었다. 계정 이메일을 맥락에서 빼도 모델이 작업 중에 읽는 파일에 주소가 있으면 같은 일이 생길 수 있다는 뜻이다.
임시 차단 장치가 막는 것은 한 가지 모양뿐이다
Anthropic은 11월 3일 나온 2.1.317에 cc-plugin-privacy라는 내장 확장을 넣었다. 릴리스 노트에는 웹 도구나 셸 명령이 계정 이메일을 네트워크로 보내기 전에 묻는 검사라고 적혀 있다. 기본으로 켜져 있고 /plugins에서 끌 수 있다.
공개된 소스의 설명은 릴리스 노트보다 좁다. 확장의 README에 따르면 이 검사는 셸 명령 한 줄에 계정 이메일과 User-Agent 지정(curl -A, wget -U 등)이 함께 있을 때만 걸리고, 묻지 않고 바로 거절한다. README는 이 장치를 "경계가 아니라 배려"라고 부르고, 통과하는 경우를 직접 나열한다. 웹 검색과 웹 읽기 도구, MCP 도구는 검사하지 않는다. $(git config user.email)처럼 실행 중에 읽어 오는 값, 변수, 스크립트 파일 안에 든 주소, User-Agent 없이 URL이나 요청 본문에 실린 주소도 걸리지 않는다. 리디아 할리도 Claude가 스크립트를 써서 직접 실행하는 경우는 막지 못한다고 인정했다.
좁게 정한 범위조차 제대로 동작하지 않는다는 보고도 있다. macOS의 2.1.317과 2.1.318, Windows의 2.1.318에서 사용자들이 확장이 켜진 것을 확인한 뒤 계정 이메일을 넣은 curl -A 명령을 존재하지 않는 주소로 보내 봤는데, 거절되지 않고 실행됐다. 2.1.318을 쓰는데 /plugins에 확장이 보이지 않는다는 댓글도 있다. 자동 업데이트를 기다리는 안정 채널 사용자는 아직 2.1.311이어서 이 장치 자체가 없다.
유출이 얼마나 자주 일어나는지에 대한 공식 수치는 없다. 직접 차단 훅을 만들어 공개한 한 사용자는 실제 Claude Code 실행 60회 중 8회에서 주소가 나갔고, 훅을 켠 60회에서는 0회였다고 적었다. 한 사람의 시험이지만, 어쩌다 한 번 생기는 일로 보기는 어려운 빈도다.
다음 릴리스 전까지 할 수 있는 일
먼저 터미널에서 claude --version으로 버전을 본다. 2.1.317보다 낮으면 claude update로 올린다. 그다음 Claude Code 안에서 /plugins를 열어 cc-plugin-privacy가 설치되고 켜져 있는지 확인한다. 위에서 본 것처럼 이 장치는 일부 명령만 걸러 내니, 켜져 있다고 안심할 일은 아니다.
근본 수정은 계정 이메일을 맥락에서 빼는 다음 릴리스다. Anthropic은 다음 주 초를 예상했고, 나오면 해커뉴스 같은 스레드에 알리겠다고 했다. 그 전까지 웹 조사를 많이 맡긴다면 모델이 직접 쓰는 curl, wget 명령과 스크립트의 헤더를 실행 승인 전에 한 번 읽는 편이 낫다. 자동 모드로 쓰고 있다면 이 확인 단계 없이 명령이 실행될 수 있으니, 웹 조사를 맡기는 세션만이라도 실행 전에 묻는 모드로 돌리는 방법이 있다.프로젝트 지침 파일(CLAUDE.md)에 "이메일을 User-Agent에 넣지 말 것" 같은 규칙을 적는 방법도 이슈에 공유됐지만, 모델이 읽고 따르는 지시라서 늘 지켜진다는 보장은 없다. 확실히 막으려면 도구 실행 직전에 명령을 검사하는 훅처럼 모델 밖에서 동작하는 장치가 필요하다.
이미 나간 주소는 되돌릴 수 없다. 받는 쪽 서버 기록에 남고, 그 기록이 누구 손에 들어갈지는 사용자가 정할 수 없다. 작성자 이름을 지어내지 말라고 넣은 정보 한 줄이, 모델이 쓰는 모든 명령에 들어갈 수 있는 재료가 됐다. 다른 코딩 에이전트를 쓰더라도 설정 파일과 작업 폴더에 어떤 개인 정보가 있고 모델이 그것을 읽을 수 있는지는 같은 방식으로 따져 볼 수 있다.
출처: Claude Code 이슈 107757, 이슈 81138, 해커뉴스 토론, privacy 확장 소스, SEC EDGAR 접근 안내