Claude Code가 이메일을 요청 헤더에 실어 보냈다, 앤트로픽이 문맥에서 빼기로

Claude Code가 웹을 검색할 때 요청 헤더에 사용자의 계정 이메일을 함께 보내고 있었다는 보고가 나왔습니다. 2026년 11월 5일 공개 저장소 이슈로 올라온 내용이고, 해커뉴스에서 762점을 받으며 확산했습니다. 단순 설정 실수가 아니라 에이전트가 스스로 만든 명령이 개인정보를 밖으로 내보낸 사례라서 논쟁이 커졌습니다.

신고자는 하루에 수십 통씩 스캠·피싱 메일을 받게 됐다고 적었습니다. 헤더에 찍힌 형식은 세션 이름/버전 <계정 이메일> 형태입니다. 웹 검색 과정에서 요청 헤더에 붙었다는 것이 그의 주장이고, 방문한 적 없는 사이트에서 온 메일이 늘었다고 합니다.

코딩 에이전트가 늘어나는 상황에서, 도구가 어떤 정보를 어디로 보내는지 다시 세어보게 만든 사건입니다. 에이전트 하네스의 기본값을 그대로 믿을 수 있는지가 남은 질문입니다.

왜 이메일이 요청 헤더에 들어갔나

앤트로픽 직원이 해커뉴스에 직접 설명을 남겼습니다. 계기 자체는 사소합니다. 로그인한 사용자의 계정 정보를 모델 문맥에 넣지 않으면, Claude가 @author 태그나 저자 이름을 지어내는 문제가 있었다는 것입니다. 그래서 계정 이메일을 문맥에 추가했습니다.

문제는 그다음입니다. Claude가 스스로 curl 명령을 작성할 때, 웹사이트의 이용 규칙이 연락처를 요구하면 문맥에 있던 이메일을 연락 주소로 넣었습니다. 일부 사이트가 자동 접속 클라이언트에 연락처 표기를 요구하기 때문입니다. 앤트로픽은 기능으로 만든 것이 아니라 모델이 그렇게 판단한 결과라고 설명했습니다. 담당자는 "이런 일이 있어서는 안 됐고 더 일찍 잡았어야 했다"고 적었습니다.

요청 헤더는 상대 서버 측에 기록될 수 있습니다. 세션 단위로 붙었다면 한 번의 조사 작업에서 수십 개 사이트에 같은 주소가 기록될 수 있습니다. 사용자는 도구를 쓰는 동안 이 사실을 알 수 없고, 메일이 쏟아진 뒤에야 알게 되는 구조입니다. 회사 계정으로 로그인해 사내 코드를 다루는 사람이라면 노출 범위가 넓어질 수 있습니다.

임시 차단 모드, 그런데 구멍이 있다

앤트로픽은 2.1.317 버전부터 내장 모드 cc-plugin-privacy를 기본으로 켰습니다. 이메일이 들어간 웹 도구 호출이나 curl 형태 명령을 실행하기 전에 사용자에게 확인을 받는 방식입니다. 끄려면 /plugins에서 직접 해제해야 합니다. 소스도 공개했습니다.

현장 검증은 깔끔하지 않습니다. 한 사용자는 2.1.318에서 이메일이 들어간 echo 명령을 실행해 봤지만 차단되지 않았다고 보고했습니다. 다른 사용자는 /plugins 목록에 해당 모드가 아예 보이지 않는다고 적었습니다. 앤트로픽 담당자도 스크립트를 직접 작성해 실행하는 경우까지는 막지 못한다고 인정했습니다. 안정 채널은 여전히 2.1.311이라 그 버전에는 이 모드가 없습니다.

검사가 걸리는 지점도 좁습니다. 앤트로픽은 이 모드가 모든 경우를 막지는 못한다고 밝혔습니다. 모델이 스크립트를 직접 작성해 스스로 실행하는 경로는 확인을 거치지 않습니다. 그래서 근본 수정, 즉 문맥에서 이메일을 빼는 작업이 함께 예고된 것입니다.

결국 문맥에서 빼기로

근본 해결책은 차단 모드가 아니라 제거입니다. 앤트로픽은 다음 릴리스에서 모델 문맥에서 계정 이메일을 아예 빼겠다고 밝혔습니다. 일정은 다음 주 초입니다. 차단 모드는 그때까지의 임시 조치입니다.

원래 이슈는 7월에도 올라왔습니다. 약 4개월이 걸린 셈이고, 저장소에 쌓인 이슈가 5,000건을 넘는다는 지적도 함께 나왔습니다. 반응은 갈립니다. 웹사이트가 봇에게 연락처를 요구하는 관행이 먼저 문제라는 의견도 있습니다. 한 이용자는 "익명성은 한쪽만 가질 수 있는 것"이라며 사이트 입장도 이해해야 한다고 적었습니다. 반대편에서는 최소 놀람의 원칙을 들었습니다. 처음 그 도메인에 접속할 때 한 번 물어보고, 거절하면 그 사이트 요청을 건너뛰는 방식이 맞다는 것입니다.

피해를 호소하는 사람은 더 있습니다. 오래 쓰지 않아 조용했던 주소에 갑자기 정체불명의 스팸이 몰리기 시작했다는 보고가 이슈에 이어 붙었습니다. 다만 메일 급증과 이 헤더의 인과관계를 통계로 입증한 자료는 아직 없습니다. 확인된 사실은 헤더에 계정 이메일이 실렸다는 점, 앤트로픽이 이를 인정했다는 점, 다음 릴리스에서 문맥에서 빼기로 했다는 점입니다.

다른 에이전트는 다른가

이번 사안은 특정 제품 하나의 문제로 끝나지 않습니다. 명령을 그대로 실행하는 구조의 에이전트 도구라면, 모델이 만든 명령이 그대로 돌아가므로, 도구가 어떤 문맥을 모델에 넣는지가 곧 외부로 나갈 수 있는 정보의 범위가 됩니다. 계정 이메일뿐 아니라 사내 저장소 주소, 내부 API 주소가 문맥에 있으면 같은 경로로 새어 나갈 수 있습니다.

확인은 어렵지 않습니다. 쓰는 도구의 문맥 설정과 플러그인 목록을 열어 어떤 값이 모델에 전달되는지 보고, 웹 요청 기능이 있으면 테스트 서버로 한 번 보내 헤더를 직접 읽으면 됩니다. 조직 차원에서는 문맥에 개인 식별 정보를 넣지 않는 규칙이 유효한 예방책 중 하나입니다.

지금 확인할 것

첫째, 버전을 확인하고 2.1.317 이상으로 올립니다. 안정 채널은 아직 2.1.311이므로, 최신 채널에서 해당 버전을 받을 수 있는지 먼저 확인합니다. 둘째, /plugins에서 cc-plugin-privacy가 켜져 있는지 봅니다. 켜져 있어도 모든 경로를 막지는 못하니, 사내 저장소나 고객사 사이트를 다루는 세션에서는 이메일이 들어간 명령이 실행되지 않는지 직접 확인하는 편이 안전합니다.

셋째, 명령 규칙을 파일로 고정하는 방법이 있습니다. 신뢰하는 사이트 목록을 정해두고, 그 밖의 주소에 연락처를 보내려 하면 승인을 받도록 CLAUDE.md에 적어두는 식입니다. 넷째, 민감한 코드라면 클라우드 하네스 대신 로컬 모델로 돌리는 선택지도 있습니다. 문맥이 외부 API로 전송될 가능성은 줄지만, 그 도구가 웹 요청을 만들면 같은 경로가 남습니다. 다음 릴리스가 나오면 버전과 문맥 구성을 다시 확인하는 편이 좋습니다. 어떤 경로로 나갔는지 확인했다면, 사내 보안 담당자에게 그 목록을 그대로 넘기는 편이 다음 점검에 도움이 됩니다.

이미 쓰고 있다면 지난 세션 기록에서 이메일이 명령에 섞여 나간 흔적을 찾아볼 수 있습니다. 세션 기록이 로컬에 남는 설정이라면, 그 안에서 계정 주소 문자열을 검색해 어떤 사이트로 나갔는지 확인됩니다. 네트워크 요청을 그대로 보여주는 테스트 주소를 하나 띄워두고 헤더를 직접 읽는 방법도 있습니다.