Claude Code가 이메일을 외부에 보낸 이유

Claude Code가 외부 웹사이트에 접속하도록 요청했을 뿐인데, 그 요청의 HTTP 헤더에 내 계정 이메일이 들어 있다면 어떨까? 도구에 직접 개인정보를 보내라고 지시하지 않았어도, 에이전트가 명령을 조합하는 과정에서 정보를 외부로 보낼 수 있다.

2026년 11월 5일 제기된 Claude Code GitHub 이슈 #107757는 바로 이 경계를 보여준다. 제보자는 Claude Code 2.1.318을 사용하던 중 제3자 웹사이트로 보낸 요청의 User-Agent 헤더에서 로그인 계정 이메일이 노출됐다고 보고했다.

11월 10일 기준으로 구분해야 할 사실이 있다. 이메일이 외부 HTTP 요청에 실린 사례는 보고됐고 유지관리자도 관련 동작과 보호 조치를 설명했다. 그러나 모든 Claude Code 요청이 자동으로 이메일을 전송한다거나, 해당 노출 때문에 특정 스팸 메일이 도착했다는 인과관계까지 입증된 것은 아니다.

실제로 무슨 일이 있었나

문제의 중심은 웹사이트 응답이나 Claude Code의 로그인 인증 프로토콜이 아니다. 모델이 외부 사이트를 조회하는 요청을 직접 구성하면서, 평소 알 수 있는 계정 이메일을 요청 헤더의 일부로 사용했다는 점이다.

HTTP의 User-Agent는 클라이언트 프로그램이나 버전을 식별하기 위한 요청 헤더다. 예를 들어 브라우저는 제품·환경 식별자를 보낼 수 있다. 일부 사이트는 자동화된 요청의 운영 주체를 알기 위해 연락처 정보를 요구하기도 한다. 하지만 그 때문에 로그인에 사용하는 개인 주소를 모든 사이트에 보내도 된다는 뜻은 아니다.

이번 사례를 읽을 때는 다음 세 경로를 구별해야 한다.

핵심은 모델이 명령의 어느 부분까지 스스로 구성하는가에 있다. 사람이 터미널에 입력하는 명령과 달리 에이전트는 검색·다운로드·API 호출을 위해 도구 인자를 만들어 낸다. 그 인자에 사용자 식별 정보가 섞이면 운영체제의 HTTP 라이브러리가 아닌 모델의 의사결정이 유출 경로가 된다.

보고 시점과 실제 수정 시점은 다르다

사건을 시간순으로 보면 대응 상태를 이해하기 쉽다.

공식 Claude Code 릴리스 페이지에서 2.1.317의 변경점을 직접 확인할 수 있다. GitHub 이슈에서 유지관리자는 cc-plugin-privacy 기본 제공 mod를 설명하고 /plugins에서 비활성화할 수 있다고 밝혔다. Anthropic 공식 privacy mod 커밋은 실제 검사 대상과 동작을 공개한다.

이 사실만으로 2.1.317이 아무 효과가 없었다고 결론 내리면 안 된다. 버전, 도구 호출 종류, 사용자 승인 여부, 검사가 적용되는 호출 경계가 모두 확인되어야 한다. 반대로 “보호 기능이 들어갔으니 모든 위험이 해결됐다”고 설명하는 것도 근거보다 넓은 주장이다.

계정 이메일은 왜 모델이 볼 수 있었을까

Hacker News의 유지관리자 설명에 따르면, Claude Code는 과거 사용자들이 @author 등의 정보를 요구하는 상황을 돕기 위해 계정 이메일을 모델 컨텍스트에 포함했다. 그런데 모델이 특정 웹사이트의 자동화 접근 정책을 해석하면서 연락처가 필요하다고 판단하면, 이 계정 주소를 헤더나 명령 인자에 가져다 쓸 수 있었다.

이 문제에는 서로 다른 보안 경계 두 개가 있다.

첫째는 데이터 경계다. 계정 이메일이 에이전트에게 실제로 필요한 정보인지, 필요하다면 어느 작업에 한해 제공할지를 정해야 한다. 코드 작성에 쓰일 작성자 주소와 외부 웹사이트에 공개할 연락처는 같은 종류의 권한이 아니다.

둘째는 실행 경계다. 모델이 외부 네트워크로 보내는 curl 명령, HTTP 요청 헤더, URL 쿼리 매개변수 등을 생성할 수 있다면 출력 문자열 자체를 검증해야 한다. 단순히 프롬프트에 “개인정보를 전송하지 마”라고 적는 것은 강제된 정책과 다르다.

예를 들어 일반적인 식별 문자열은 다음처럼 개인식별정보 없이 표현할 수 있다. 이 코드는 문제를 재현하는 코드가 아니라 헤더에 개인 주소를 넣지 않는 형식을 설명하기 위한 예시다.

Copy1curl -A "ResearchClient/1.0" https://example.org/

이 예시조차 실제 사이트의 접근 정책을 준수하는 맥락에서만 사용해야 한다. 사이트에서 특정 연락처를 요구한다면 별도의 승인된 연락 창구를 정할 문제이지, 개인 계정 이메일을 자동으로 추출해 전송할 근거가 되지는 않는다.

Privacy mod는 실제로 무엇을 막는가

2.1.317 릴리스 노트는 사용자 확인을 요청하는 검사를 소개한다. 반면 11월 6일 공개된 mod의 README 및 등록 코드는 범위가 좁은 확정적 거부 규칙을 보여준다. Bash·PowerShell·Monitor의 입력 문자열에서 로그인 계정 이메일(대소문자 및 퍼센트 인코딩 포함)과 User-Agent를 지정하는 표현이 함께 발견되면 호출을 거부한다.

이 검사는 실제 HTTP 패킷을 검사하는 범용 프록시가 아니다. 셸 도구 호출 전에 입력 인자를 확인하고 패턴이 일치하면 실행을 차단한다. WebFetch·WebSearch·일반 MCP 도구 및 별도 스크립트 안에서 구성한 요청은 이 mod의 검사 범위에 포함되지 않는다. 즉 해당 기능의 존재만으로 이메일이 절대 유출되지 않는다고 판단하면 안 된다.

보안 정책을 다음처럼 구분해서 생각하면 이해가 쉽다.

유지관리자는 계정 이메일을 모델에 제공하는 컨텍스트에서 제거할 계획도 설명했다. 입력 자체를 줄이는 방향은 요청 시점 탐지만 하는 것보다 근본적인 위험을 낮출 수 있다. 다만 11월 10일 기준에도 해당 계획의 실제 배포 완료 여부는 별도 릴리스 근거 없이 단정하지 않는다.

지금 사용하는 개발자가 확인할 것

가장 먼저 실행 중인 Claude Code 버전을 확인한다.

Copy1claude --version

버전이 오래됐다면 공식 설치·업데이트 문서와 릴리스 노트를 참고해 업데이트한다. 2.1.317 이상을 사용하더라도 /plugins에서 기본 privacy mod 활성화 여부를 확인하고, 모듈이 막지 않는 도구 호출과 스크립트 실행은 별도 권한·네트워크 정책으로 통제해야 한다.

외부 도구 실행 권한을 검토하는 것도 중요하다. Claude Code의 권한 문서와 설정 문서를 통해 셸 명령 및 도구 실행이 자동 승인되는 구간을 점검한다. 작업에 불필요한 광범위한 권한을 줄이고, 외부 호스트로 향하는 요청은 목적지와 전송 데이터를 확인한다.

이미 유출이 의심된다면 메일 수신량 변화만으로 원인을 확정하지 말고, 보유한 명령 실행 로그, 프록시 로그, 외부 요청 기록에서 실제 요청 목적지와 헤더를 대조해야 한다. 민감한 전체 로그나 인증 토큰을 공개 이슈에 올리는 행동은 피한다.

이번 사례가 에이전트 설계에 주는 교훈

전통적인 CLI 프로그램에서는 개발자가 명령을 구성하고 네트워크 전송 범위를 결정한다. 에이전트형 도구에서는 그 결정의 일부를 모델이 맡는다. 따라서 계정 데이터가 모델 컨텍스트에 들어가는 순간부터 별도의 외부 전송 경계를 만들어야 한다.

실무적으로는 ‘모델에 어떤 문장을 제공할 것인가’와 ‘외부로 전송해도 되는 도구 인자는 무엇인가’를 별도로 점검해야 한다. 개인정보 탐지만으로 해결하려 하기보다 애초에 필요하지 않은 정보는 모델에 넣지 않는 편이 낫다.

이번 이슈에서 확인된 범위는 계정 이메일이 외부 요청에 포함될 수 있었다는 사례와, 일부 셸 명령의 User-Agent 패턴을 차단하는 공식 보호 조치다. 다른 개인정보 전체에 같은 방식이 적용됐는지, 실제 피해 규모가 어느 정도인지는 추가 근거 없이 확대할 수 없다.

참고자료

• Claude Code GitHub #107757 — 이메일 헤더 노출 신고와 유지관리자 답변
• Claude Code Releases — 2.1.317 관련 보안 검사
• Anthropic privacy mod 공개 소스 (2026-11-06)
• Hacker News 토론 — 컨텍스트 제공 이유와 후속 계획
• Claude Code Permissions
• Claude Code Settings