Claude Code가 사용자 이메일 주소를 웹사이트에 보냅니다

Claude Code sends your email address to websites

github.com/anthropics ▲ 1531 댓글 482 motoroco

요약

Claude Code가 웹 요청 헤더에 계정 이메일을 담아 외부 사이트에 보낸다는 신고가 나왔습니다.

한 이용자가 11월 5일 Claude Code의 GitHub 저장소에 올린 버그 신고입니다. 그는 Claude Code가 허락 없이 웹 검색을 하며 User-Agent 헤더(요청을 보낸 프로그램을 알리는 정보)에 자기 이메일을 넣었고, 그 뒤로 하루 수십 통의 사기 메일을 받는다고 밝혔습니다.

왜 중요한가

  • 코딩 에이전트가 사용자 모르게 계정 개인정보를 제3자 사이트에 넘길 수 있다는 점이 드러났습니다.
  • 헤더에 프로젝트 이름까지 함께 실려, 누가 어떤 일을 하는지도 외부에 알려진다는 지적이 나왔습니다.

핵심 내용

  • 신고자는 켜고 끄는 설정이 아니라 기능 자체를 없애야 한다며, 회사 도구를 Pi와 OpenRouter로 옮기겠다고 했습니다.
  • 개발 측은 2.1.317 버전부터 이를 막는 내장 플러그인 cc-plugin-privacy를 기본으로 켜 두었다고 답했습니다.
  • 한 이용자는 이 플러그인이 계정 주소와 'User-Agent'라는 글자가 함께 든 셸 명령만 막는다고 분석했습니다.
  • 모델이 이메일을 스크립트 파일에 써 넣은 뒤 실행하면 검사를 피한다는 사례도 보고됐습니다.
  • 기본 User-Agent를 작업 내용이 빠진 claude-code/버전 같은 일반 값으로 두자는 제안도 나왔습니다.

HN 반응

  • SEC(미국 증권거래위원회) API 문서가 User-Agent에 이메일을 요구해 Claude가 따랐다는 분석이 많았지만, 실제로는 이메일 없이도 접속된다는 확인이 뒤따랐습니다.
  • 사람 비서도 이런 요구에 똑같이 속는다는 옹호와, 동료가 내 이메일을 모든 사이트에 뿌리지는 않는다는 반론이 맞섰습니다.

댓글

30개 표시 · 전체 482개
  1. varenc HN

    이런 동작을 봤다는 사람들이 유독 SEC API를 쓸 때 많이 나오는 걸 보면, 이메일을 요구하는 쪽은 그 서비스인 것 같습니다. SEC API가 이메일을 필수로 요구하는 걸까요?


    업데이트: SEC API 문서를 보면 User-Agent에 이메일을 넣어야 하고, 안 넣으면 요청을 거부합니다. 시연해 보겠습니다.

        U='https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/Assets.json'
        curl -s -o /dev/null -w 'response: %{http_code}  curl default User-Agent, rejected\n'  "$U"
        curl -s -o /dev/null -w 'response: %{http_code}  email in user-agent, success\n' -A 'Acme Research [email protected]' "$U"
    
    response: 403  curl default, rejected
        response: 200  email in user-agent, success
    

    SEC 문서: https://www.sec.gov/search-filings/edgar-search-assistance/accessing-edgar-data#:~:text=Bot%20Request%20Headers%3A-,User%2DAgent%3A,-Sample%20Company%20Name

    결국 Claude는 문제를 풀어 보려고 SEC가 요구하는 대로 했을 뿐입니다. '프롬프트 인젝션 공격'인 셈인데, 그 행동을 지시한 주체가 SEC인 거죠. 까다로운 얼라인먼트 문제입니다. 이메일 검증이 있을 리 없으니 꽤 어이없는 방식이기도 하고요. (수정: 알고 보니 SEC는 cURL이 아닌 User-Agent라면 거의 아무거나 받아 주고, 이메일이 실제로 필수는 아닙니다.)

  2. T-R HN

    저는 SEC 데이터를 다루는데, 이 용도로 쓰려고 따로 만들어 둔 업무용 이메일이 있습니다. 그런데 저도 Claude가 아무 확인도 경고도 없이 제 개인 이메일(아마 Claude 계정에 연결된 이메일일 겁니다)을 태연하게 보내는 걸 봤습니다. 우연히 curl 요청을 들여다보다가 알아챈 거고요. 이번 경우엔 그냥 좀 짜증나는 정도였지만, Claude가 전반적으로 이렇게 동작한다는 건 분명 보안 문제입니다.

  3. prpl HN

    더 나은 샌드박싱이 가능하고, 그러면 이 문제도 줄어들 겁니다.

  4. T-R HN

    동의합니다. 명령어와 curl 요청을 막는 데 그렇게 공을 들였는데, 계정 정보나 개인식별정보(PII)에는 명시적인 제한이 없는 것 같아 좀 놀랐을 뿐입니다.

    적어도 Claude Code 사용자의 기대와는 거리가 있어 보입니다. Claude 앱이라면 양식을 채우는 데 쓰는 사람도 있을 테니 그런 기대를 하는 사용자도 있을 수 있겠지만요(제 생각엔 권할 만한 일은 아니지만).

  5. ZoneZealot HN

    개인과 업무를 섞지 마세요. 회사 컴퓨터에서 개인 LLM 계정을 쓰는 것 같은 일 말입니다. 문제가 많이 생깁니다.

  6. T-R HN

    스타트업 포럼에서 상대방이 업무용 컴퓨터와 AI 계정 예산이 있는 회사에 다닌다고 가정하는 건 이상한 일입니다.

    현실에는 위협 모델이라는 개념이 있어서, 할 일 목록 앱에 SCIF(기밀 정보 시설)까지 필요한지, curl 요청 몇 번에 샌드박스용 Claude Max 계정을 따로 만들어야 하는지를 판단하게 해 줍니다.

  7. magnio HN

    업무에 개인 노트북을 써야 하는 상황이라 해도, 업무용과 개인용 사용자 계정을 따로 만들지 않을 이유가 뭡니까?

    프로그래머라는 사람들이 그 정도의 사생활과 보안을 위해 아주 사소한 불편조차 감수하지 못한다는 게 저는 기가 막힙니다. 이 글에서 Claude가 네트워크 요청을 보내기 전에 사용자에게 물어봤어야 한다고 불평하는 사람들도 있던데, 알아서 물어봅니다. 빌어먹을 --dangerously-skip-permissions만 안 쓰면요. 그런데 다들 쓰죠. 그렇게 안 하면 이 업계가 지난 30년간 아무 생각 없이 스스로 짊어진 이 개판들을 고치겠다고 기존의 허술한 소프트웨어를 전부 슬롭으로 다시 쓰는 게 어떻게 되겠습니까. 비결정적인 헛소리 기계가 RCE로 당신의 빌어먹을 개인 겸 업무용 머신에 들어오게 해 놓고요.

  8. stronglikedan HN

    why wouldn't you create separate users for work and personal lives?

    (번역: 업무용과 개인용 사용자 계정을 따로 만들지 않을 이유가 뭡니까?)

    귀찮으니까요. 그리고 이득이 되는 건 아주 특정한 업무 환경에서뿐인데, 많은 사람은 거기에 해당하지 않습니다.

    왜 모든 사람에게 같은 방식이 맞는다고 생각하시죠?

  9. dylan604 HN

    저도 사용자 계정을 나눠 써 봤는데, /usr/local/bin이 아니라 $HOME/bin에 뭘 설치해 놓으면 번거로워집니다. 전역으로 다시 설치하거나 다른 계정에도 따로 설치해야 하니까요. 이게 그냥 프로젝트가 다른 게 아니라는 걸 계속 스스로 상기해야 합니다. 대부분의 일이 그렇듯 반복하면 익숙해집니다. 그만한 가치가 있는지만 정하면 되죠.

  10. T-R HN

    Even if you have to use personal laptops for work, why wouldn't you create separate users for work and personal lives?

    (번역: 업무에 개인 노트북을 써야 하는 상황이라 해도, 업무용과 개인용 사용자 계정을 따로 만들지 않을 이유가 뭡니까?)

    그게 말이 되는 곳에서는 당연히 그렇게 합니다. 제 첫 댓글도 Claude가 지정해 둔 업무용 자격 증명을 쓰지 않고 계정에 있는 걸 가져다 썼다는 얘기였고요.

    일반적인 보안 우려에는 동의합니다. 에이전트를 아무 제약도 없이 사람이 지켜보지도 않는 루프로 돌리는 사람들이 있는데, 그건 무책임한 일이고 그러다 HuggingFace를 해킹하겠다고 나서도 놀랄 일이 못 됩니다. 그 사람들을 변호하려는 게 아니라 다른 모든 사람을 위해 하는 말인데, 사람이든 도구든 실패할 가능성에 대한 머릿속 모델을 만들고, 그걸 예상되는 결과의 크기와 견주어서 판단을 내리는 겁니다. 그러다 예상 밖의 일이 터지면 HN에 글을 올릴 수도 있는 거고요.

    어떤 사람들에게는 그 추정이 루트 권한과 이메일, 은행 계좌까지 제한 없이 열어 주는 걸로 귀결되는데, 저로서는 어이가 없습니다. 저는 친구의 초기 스타트업이 자리 잡도록 제 돈으로 돕고 있고, 신뢰할 만한 정부 API 몇 개에 대해 묻고 제가 직접 검토하는 함수 초안을 쓰게 하는 정도의 위험 때문에 비싼 Claude 계정을 사비로 더 사는 건 타당하지 않습니다.

  11. terminalcommand HN

    회사에서 Claude를 제공하지 않아서 자기 계정을 쓰는 경우도 있습니다.

  12. InitialLastName HN

    진짜 엔지니어링 세계에서는 실무자가 회사 업무에 개인 소유 도구를 쓰는 것이 (실무자에게도 회사에게도) 비윤리적인 일로 여겨집니다.

  13. anamexis HN

    그렇군요. 가짜 엔지니어링 세계에서는 아니고요.

  14. beisenberg_ HN

    그래도 저라면 업무용 이메일로 그 계정을 만들겠어요.

  15. r_lee HN

    그럼 Anthropic이 모두에게 이메일을 뿌리니까 구독이 두 개 필요하다는 거예요?

  16. hxugufjfjf HN

    저분 입장을 보면 Anthropic이 그러든 안 그러든 어차피 그렇게 하실 것 같은데요.

  17. dylan604 HN

    이 포럼의 독자가 스타트업에만 있지 않다는 건 잘 알려진 사실입니다. 자리 잡은 회사에 다니는 사람도 많습니다. 그리고 회사에서 지급한 장비는 어떤 종류의 개인 용도로도 절대 쓰지 말라고, 개인 데이터와 업무 데이터를 분리하라고 상기시키는 건 언제 해도 나쁘지 않습니다. 보세요, 방금 또 했습니다.

    또 "스타트업 포럼"이라고 해서 독자가 모두 스타트업을 운영하는 창업자인 것도 아닙니다. 스타트업에서 일하는 사람이 많습니다. 자기 관점에만 갇혀서 모두가 자기와 같다고 가정하다가, 기술에 밝은 편일 뿐 결국은 일벌에 불과한 독자도 많다는 걸 놓치는 또 하나의 사례 같네요.

  18. T-R HN

    제 요지는 바로 그겁니다. 위의 댓글 작성자가 제 상황을 멋대로 가정했고(이 포럼의 원래 독자층 밖의 이야기죠), 그걸 근거로 훈계조의 댓글을 달았다는 겁니다. 여기 있는 사람이 기본적인 보안 정책을 가르쳐야 하는 주니어 엔지니어일 거라고 단정하는 건 부당합니다. 그 사람은 주어진 상황에서 최선을 다해 절충하고 있는 사람일 수도 있잖습니까.

  19. DANmode HN

    이건 문장 완성 기계예요.

    전지전능한 개인 비서가 아니고요.

    그 처음의 기술적 구멍 위에 아직 충분한 관문을 쌓지 못한 거죠.

  20. ZiiS HN

    사람 개인 비서 대부분도 이 프롬프트 인젝션에는 똑같이 취약합니다.

  21. sigmoid10 HN

    그렇죠. 큰 회사에서 개발자들을 관리해 본 사람이라면 누구나 말해 줄 겁니다. 독립적으로 일해서 성과를 내도록 자유를 주는 것과, 나쁜 일이 생기지 않도록 접근을 제한하는 것 사이에서 끊임없이 씨름하게 된다고요. 현실에서는 나쁜 일이 많이 터질수록(그리고 컨설턴트를 많이 들일수록) 장애물이 더 늘어납니다. 결국 사소한 일조차 승인을 받느라 기업형 악몽이 되죠. 두 가지 업무 철학의 편리함을 동시에 누릴 수는 없습니다. 아무리 똑똑한 AI 에이전트가 나와도 이 사실은 안 바뀝니다. 그들의 작업 속도가 승인 절차의 속도로 제한될 뿐이에요.

  22. miki123211 HN

    사람은 사기, 속임수, 피싱, 사회공학에 취약합니다. 우리는 이 취약점의 근본 원인을 어떻게 고쳐야 할지 모릅니다. 그 취약한 사람들을 둘러싼 환경을 다시 설계해서 영향을 줄이는 것밖에 할 수 없죠.

    LLM도 똑같이 잘 속습니다. 다만 LLM의 취약점은 보통 "프롬프트 인젝션"이라고 부를 뿐, 속을 들여다보면 거의 같은 종류의 공격입니다. 그런데 사람과 달리 LLM은 훨씬 덜 다양합니다(당신과 제가 같은 Opus 5.5를 쓰지만 뇌는 서로 다르잖아요). 그래서 LLM에 대한 공격은 훨씬 예측하기 쉽고 성공시키기도 쉽습니다. 특정한 한 사람을 겨냥한 피싱 캠페인이, 수백만 명의 제각각인 피해자에게 통하도록 확장해야 하는 공격보다 쉬운 것과 같은 이치입니다.

    에이전트의 시대에도 피싱은 여전히 가장 큰 공격 경로일 겁니다. 바뀌는 건 피해자뿐이에요.

  23. eru HN

    자유와 나쁜 일 방지 사이에 파레토 최적선이 있는 건 분명합니다. 그런데 그 선 위에 있지 않은 회사가 많죠.

    (제가 겪어 본 바로는, 내부 보안 통제가 안정적으로 작동하면서도 일을 방해하지 않는 면에서는 제가 일했던 은행들보다 Google이 나았습니다.)

  24. busssard HN

    다른 점은, 그런 승인 절차를 AI 에이전트로 구축하면 시스템이 조금 더 빨리 돌아간다는 겁니다. 웹을 읽는 에이전트, 웹에 쓰는 에이전트, 코딩 에이전트, 자격 증명 에이전트 같은 식으로 나누고, 모두가 이런 공식 요청을 거치게 하는 거죠.

    프롬프트 인젝션이 성공하려면 두 번째 시스템까지 프롬프트 인젝션해야 하니, 꽤 많은 공격을 걸러낼 겁니다.

  25. soraminazuki HN

    제 커리어에서 동료가 제 브라우징 기록의 익명성을 깨거나 제 이메일 주소를 인터넷 곳곳에 흘린 적은 한 번도 없습니다. 복사해서 붙여 넣은 듯한, 생각을 멈추게 하는 그 논리는 여기선 통하지 않습니다.

  26. miki123211 HN

    동료가 Adobe Flash Player를 업데이트하거나, 회사에서 의무로 시키는 피싱 테스트에서 "150달러짜리 월마트 크리스마스 상품권을 받으려고" Okta 자격 증명을 입력하거나, 회사 노트북에서 면접이나 영업 통화에 들어가려고 "Zoom"을 설치하는 걸 본 적 없으세요?

    공격 방식이 다를 뿐, 결과는 같습니다.

  27. soraminazuki HN

    이런 말까지 해야 한다니 믿기지 않지만, 같지 않습니다. 당신 동료는 방문하는 모든 사이트에 본인 동의도 없이 다른 사람들의 이메일 주소를 보내서 그 사람들의 브라우징 익명성을 깨고 있지 않잖아요.

    그 예는 완전히 다른 낚시성 논점이에요. 사람도 잘 속는다는, 더 쉬운 주장을 내세워서 물을 흐릴 뿐입니다. 그것조차 오해의 소지가 있고요. 가짜 150달러에 넘어갈 만큼 낮게 구는 사람이 모두는 아니니까요. 사람에게는 책임을 물을 수 있고 피해를 막을 수도 있지만, LLM은 같은 실수를 되풀이하는데도 사람 쪽에서도 늘 그래 왔다고 말하려고 HN에 줄을 서는 사람들이 있네요. 소프트웨어 업계의 사기는 하루가 다르게 새로운 바닥을 찍고 있습니다.

  28. Melatonic HN

    그건 인사팀이 당신 정보를 정부에 넘기는 것에 더 가까운 거 아닌가요?

  29. yen223 HN

    사람의 실수 때문에 수십억 달러어치 암호화폐가 도난당한 게 그리 오래전 일도 아니잖아요.

  30. soraminazuki HN

    그 전혀 상관없는 이야기를 저더러 어쩌라는 겁니까?

Hacker News에서 보기 ↗