요약
Claude Code에서 “다시 묻지 않기”로 승인한 명령이 비밀번호째 저장돼 공개 GitHub 파일 1,122개에 노출됐습니다.
보안 업체 아피로가 공개 GitHub에 올라온 Claude Code 설정 파일 10만여 개를 모두 내려받아 분석했습니다. 발표 전 앤트로픽에도 알렸고, 발표 뒤 Claude Code 책임자 보리스 체르니가 HN에서 대책을 검토하겠다고 답했습니다.
왜 중요한가
- 모델과 상관없는 Claude Code 고유의 동작으로, 코딩 에이전트 16종 중 승인 명령을 통째로 파일에 남기는 것은 이것뿐이었습니다.
- 실제 비밀이 든 파일 중 215개는 gitleaks와 TruffleHog가 모두 놓쳐, 비밀 탐지 도구만으로는 막기 어렵습니다.
- 파일을 지워도 git 기록과 포크(저장소 복제본)에 남으므로, 한 번이라도 커밋했다면 비밀번호를 바꿔야 합니다.
핵심 내용
- 승인한 명령 문자열이 비밀번호를 포함한 채 프로젝트 폴더의 .claude/settings.local.json에 허용 규칙으로 저장됩니다.
- Claude Code는 이 파일을 개인 전역 gitignore에만 넣어서, 다른 컴퓨터나 이미 커밋된 파일은 막지 못합니다.
- 공개 파일 104,185개 중 1.1%에 실제 비밀이 있었고, 다른 경로까지 합치면 1,994개 저장소에서 2,539개가 나왔습니다.
- 3분의 1 이상이 데이터베이스 비밀번호처럼 DB에 바로 접속하는 정보였고, 의료 기록 앱 개발사 등 63개 조직이 영향을 받았습니다.
- 비밀은 $DB_URL 같은 환경 변수로 넘기고, 개별 명령 대신 Bash(npm run:*) 같은 패턴을 승인하라고 권했습니다.
HN 반응
- 버튼만으로 노출되지는 않으며 로컬 설정 파일을 직접 커밋해야 한다는 지적이 많았고, 체르니도 같은 취지로 답했습니다.
- 체르니가 권한 규칙 대신 모델이 위험을 판단하는 자동 모드를 권하자, 확정적인 차단 장치가 필요하다는 반론이 이어졌습니다.
Claude Code 팀의 보리스입니다. 지금까지 Claude Code는 시크릿 마스킹(secret scrubbing)을 하지 않았습니다(이를 위한 좋은 도구가 많습니다). 다만 이런 일을 막기 위해 할 수 있는 게 무엇인지 살펴보고 있습니다.
그렇긴 해도 몇 가지 말씀드리겠습니다.
.claude/settings.local.json은 로컬에만 두려고 만든 파일입니다. 소스 관리에 체크인하면 안 되는 파일입니다. Claude가 이 파일을 만들 때는 자동으로 gitignore에 추가하므로, 이번 경우에는 파일을 수동으로 만들어 체크인한 것입니다(문서: https://code.claude.com/docs/en/settings )
권한 규칙은 구식입니다. 이제 모두 auto mode를 써야 합니다. 더 안전하고, 까다로운 허용/거부 목록을 수동으로 관리할 필요도 없습니다. auto mode는 기본으로 켜져 있고 모든 요금제에 무료로 포함되어 있습니다.
어떤 에이전트를 쓰든 시크릿 스캐닝은 켜 두셔야 합니다. GitHub를 비롯한 소스 관리 호스트가 이 기능을 제공합니다. 이 기능이 막아 주는 위협 모델이 많으니, 쓸 수 있다면 반드시 쓰십시오. (https://github.com/security/plans 참고)
저는 에이전트가 할 수 있는 일에 결정론적인 경계를 긋고 싶습니다. 보안을 확률적인 방식으로 다루고 싶지 않습니다.
제 생각에는 에이전트가 스스로 어떤 일을 할지 결정할 수 있다면, 그 일이 실수로 일어나는 것을 막을 방법이 없고, 에이전트의 컨텍스트에 텍스트를 주입할 수 있는 공격자라면 누구든 그 일을 시킬 수 있습니다.
결정론적 경계는 샌드박스, 마이크로VM, 원격 인프라, 고유한 신원(identity)으로 풀고 그 위에 확률적 가드레일을 얹는 방식이 최선으로 보입니다. 베어메탈에서 돌리던 예전 방식의 결정론적 허용/거부 목록으로는 Claude에게 결정론을 부여하는 문제를 제대로 풀지 못했습니다. 사람은 승인 피로에 시달렸고, 결국 Claude가 'python3 FILE.py' 같은 실행 권한을 얻으면 'FILE.py'를 수정해서 마음대로 날뛸 수 있었으니까요.
간단한 해결책이 있잖아요. 결정론적 제약이 필요한 일에는 비결정적인 도구를 쓰지 않으면 되지 않나요?
그렇지 않습니다. 허용 목록(allowlist)은 결정론적 도구입니다. 그게 핵심입니다. LLM에게 스스로를 검토하라고 지시하는 것은 비결정적이어서 권한 관리에 적합하지 않고, 결정론적인 허용 목록이 그보다 낫습니다.
장난해요? 뭐가 안전하고 뭐는 하면 안 되는지를 Claude가 '감'으로 판단하게 전권을 줄 것 같아요?
저는 특정 폴더를 완전히 정적으로 통제하고 싶어요. 권한 규칙은 수동 모드든 auto 모드든 어떤 모드 위에서도, 사용자가 따로 샌드박스를 꾸미지 않아도 무조건 강제되는 샌드박싱이어야 해요.
내장된 /sandbox는 써 보셨나요?
써 봤죠. UX 면에서 아쉬운 점이 많고, 기본값도 좋지 않고, 파 보지 않으면 알 수 없는 구멍도 여전히 많아요(예: 자체 쓰기 도구와 bash의 차이).
그래서 애플의 (곧 '지원 중단'된다는) seatbelt 백엔드로 직접 만들었어요. 앤트로픽도 그걸 쓰는 걸로 아는데, 제 건 인터페이스가 훨씬 낫고 프로젝트별 설정도 쉬워요.
그리고 '$file을 열 수 없어서 샌드박스 없이 다시 시도했다'고 하는데, 그게 어째서인지 그냥 통한다니까요?
비판하려는 건 아니지만, Claude가 .env에 접근하지 못하게 하려면 거쳐야 할 과정이 지나치게 많습니다. 조금만 복잡해져도 사실상 에이전트에게 써 달라고 해야 합니다. 예를 들어 .env.example은 허용하되 .env.*는 막으려면 그렇습니다.
오히려 그런 건 기본으로 켜져 있어야 하고, 알려진 다른 민감한 폴더에도 적용되어야 합니다. .agentignore 같은 더 단순한 체계라면 훨씬 좋겠고요.
auto mode는 마음에 들지만, '에이전트가 스스로를 감독한다'는 것만으로는 컴플라이언스와 안전 측면에서 부실한 답입니다.
헤드라인이 혼란스럽습니다. 이들은 .claude/ 폴더와 로컬 설정을 커밋한 저장소를 찾아서, 그 파일들에서 키나 비밀번호가 들어간 명령어를 스캔한 겁니다.
그러니 '다시 묻지 않음'을 누른다고 해서 그것만으로 비밀번호가 노출되는 건 아닙니다. 로컬 Claude 설정을 커밋했고, 그 설정에 비밀 값이 명령어에 그대로 들어간 명령을 수동으로 승인해 둔 상태에서 저장소를 공개하면 노출되는 겁니다.
삭제된 댓글입니다.
그 흐름이 맞습니다. 사람들이 예상하지 못하는 부분은, 이 파일이 프로젝트 안에 만들어지는데 Claude Code는 저장소의 .gitignore가 아니라 전역 git ignore에만 추가한다는 점입니다. 그래서 새로 클론하거나 두 번째 기기에서 작업하면 다른 파일처럼 그대로 커밋됩니다. 저희가 추적한 1,105개 저장소 중 539곳에서는 Claude가 공동 작성자로 들어간 커밋이 이 파일을 변경했습니다.
새로 클론한 곳에는 그 파일이 없을 텐데요. 이 주장은 말이 안 됩니다.
제가 보기에 커밋될 수 있는 경우는 누군가 전역 .gitignore를 수정했거나, 그보다는 다른 기기에서 작업하려고 디렉터리 전체를 옮겼을 때뿐입니다.
맞습니다, '새로 클론'은 틀린 표현이었습니다. 전역 ignore가 없는 새 기기나 컨테이너, 복사한 프로젝트 폴더에서, 또는 파일이 한 번 커밋된 뒤에는 발생합니다. ignore 규칙은 이미 추적 중인 파일에는 적용되지 않으니까요.
git clone 안 하고 왜 복사하는 거죠?
(AI 때문에 유입된) 새로운 물결의 git 사용자들은 git이 뭔지도 몰라요.
우리의 AI 벤더 군주님들 밑에서 일하는 '시니어/프린서펄 소프트웨어 엔지니어' 중에 이런 부류가 얼마나 될지 궁금해요. 이런 상황은 목소리 큰 VC들(에헴)이 2000년대부터 '나이'와 '경험'을 깎아내리고 젊음을 '필수 조건'처럼 떠받든 데다, 바로 그 VC들이 이제 누가 봐도 미성숙하고 버그투성이고 솔직히 위험할 수도 있는 자기들 제품 위에서 업계 전체를 돌리도록 강탈하려 드는 데서 나온 필연적인 결과예요.
이 모든 게 불행 중 다행이라면, 경험 많은 '고대' 소프트웨어 실무자인 우리가 다시 찾는 사람이 될 거라는 점이에요. 물론 제정신인 세상이라면요.
그렇다면 gitignore는 애초에 무슨 상관이 있는 거예요?
말이 안 됩니다. 저는 전역 git ignore를 항상 씁니다. 저만 만들어 내는 파일 중에 절대 커밋하고 싶지 않은 게 있거든요(flycheck, 너 말이야). 그런 파일은 애초에 커밋된 적이 없으니 새로 클론한 곳에는 들어 있지 않습니다. 전역 git ignore까지 같이 옮기지 않고 저장소를 옮기려면 git이 아닌 다른 전송 수단을 써야 합니다.
어쨌든 이 저장소들에는 제대로 된 코드 리뷰 과정이 없다는 뜻일 겁니다. settings.local.json이라는 파일 이름부터가 로컬 파일이니 커밋하면 안 된다고 외치고 있습니다.
아마 대부분 git이 뭔지도 잘 모르는 개인 개발자일 겁니다. 코딩을 못 하는 사람도 이제 코딩할 수 있다는 것, 이게 AI 회사들이 그토록 광고하고 싶어 하는 바로 그 점이고, 실제로 사실입니다. 하지만 그렇다면 도구가 사람들이 바보짓을 하지 못하게 막아 줘야 한다는 뜻이기도 합니다. 자기가 하는 일이 바보짓인지도 모를 테니까요.
상위 댓글이 신고(flag)당한 건 수치스러운 일입니다. 제가 vouch해서 되살려 놓았지만 아마 또 신고당할 겁니다.
전부 AI가 생성한 글이에요. 사람이 쓴 게 아닌 댓글은 vouch하지 말아 주세요. 규칙에 어긋납니다.
게다가 틀린 내용이에요. 이미 여러 사람이 답글로 그 기본적인 오류를 지적했고요.
이 댓글을 쓴 사람은 지금 논의 중인 기사를 제출하고 쓴 사람이기도 합니다.
AI가 생성했든(저는 알 수 없습니다) 틀렸든(틀렸습니다) 작성자 본인의 답변을 신고하는 건 말이 안 됩니다.
어떻게 판단하신 거죠?
게다가 저도 그 오류를 발견했어요. 지금도 그런 일이 일어나는 걸 볼 수 있고요. 샌드박스에 갇힌 에이전트는 전역 git ignore에 접근하지 못해요.
.claude에 시크릿을 넣은 뒤 새로 하나 만들고요. 같은 개발자, 같은 기기, 새 샌드박스예요. 원래 샌드박스의 전역 gitignore에는 접근할 수 없죠. 시크릿은 이미 프로젝트에 들어 있고요. 커밋하고 푸시하면 시크릿이 유출돼요.그 사람이 쓴 댓글은 올라간 순간부터 전부 자동으로 신고 처리됐습니다. LLM 탐지기나 스팸 탐지기에 걸린 모양입니다.
AI 슬롭이에요. 그 말이 정말 사실이라면 누군가 사람이 직접 올려 주겠죠.
저는 AI 에이전트가 가진 접근 권한 수준이 몹시 걱정됩니다. 그러면서도 제가 해야 하는 온갖 번거로운 작업을 에이전트가 덜어 주길 바라고, 일일이 관리·감독해야 한다는 건 짜증스럽습니다.
제가 찾은 최선의 해법은 작업마다 (격리된 네트워크 위의) 일회용 VM을 쓰고, 귀찮게 묻지 않도록 --dangerously-skip-permissions를 쓰는 것입니다. 여기에 외부 서비스에 대한 에이전트 권한을 제한할 수 있는 API 프록시를 결합합니다. 예를 들어 QuickBooks API 키는 가진 쪽에 '신 모드' 권한을 주지만, 프록시를 거치면 에이전트는 확인 없이 특정 읽기 명령만 실행할 수 있고, 영수증 업로드를 제외한 모든 쓰기 엔드포인트는 제 폰에서 승인해야 QuickBooks 서버에 닿을 수 있습니다. 이제 에이전트가 제 읽기 전용 요청을 제대로 해석해 주리라고 믿을 필요가 없습니다.
제 자랑 같아서 쑥스럽지만, 이 구성은 놀랄 만큼 잘 작동합니다! 과도한 권한이 붙은 날것의 자격 증명이나 OAuth 연동을 에이전트에게 직접 건네는 건 절대 못 믿겠는 수십 개의 서비스를 안전하게 연결할 수 있었습니다. 마침 오늘 이 API 프록시를 공개했습니다. https://keycontain.com
관점을 바꿔 보세요. 정말 문제가 작업이 번거롭다는 건가요? 아니면 그 작업을 꼭 해야 한다는 건가요? LLM 기반 자동화보다는 (LLM이 구축을 도와줄 수 있는) 결정론적 자동화에 더 기대야 할지도 몰라요.
물론 결정론적 자동화가 가능하면 스크립트를 만들라고 시킵니다. 하지만 상당수 작업은 결정론적이지 않습니다. 결정론적이라고 해도 자격 증명은 여전히 안전하게 다뤄야 하고요. 제가 시키는 작업의 예는 다음과 같습니다.
xyz 제품에 쓸 도메인 이름을 조사해서 구매하고, 이 제품에 맞게 원하는 대로 DNS를 전부 설정하고, 이메일을 세팅하고, 스크린샷과 설명을 포함한 앱스토어 제출 준비를 하고, Firebase 알림을 설정하고, 이 앱에 필요한 Google Cloud 프로젝트와 활성화해야 할 API를 설정하고, 앱스토어 심사 피드백에 대응하기.
장부를 감사해서 모든 거래에 영수증이 업로드되었는지, 영수증이 분개 내용과 일치하는지 확인하기. 모든 은행 계좌에서 명세서를 가져와 장부와 대조하기. 잘못된 거래는 제 확인을 받아 수정하기.
소스 관리에 자유롭게 푸시하되, 특정 브랜치 접두사에만 허용하기(GitHub, gitlab, gitea 등에 아직 이게 기본으로 없다는 게 의외입니다). 머지는 제 확인을 받아서 하기.
Gmail에서 제목 줄과 회계사가 보낸 이메일 전문은 자유롭게 읽고, 이메일은 자유롭게 검색(하지만 내용은 읽지 못함)하고, 초안은 자유롭게 작성하고, 회계사 외의 이메일 전문은 제게 읽어 달라고 요청하고, 초안 발송도 제게 요청하기. 예컨대 비밀번호 재설정 링크는 읽을 방법이 없습니다.
더구나 제 모든 서비스에 접근하는 키가 단 하나뿐입니다. 키가 유출돼도 키 하나만 교체하면 됩니다. 에이전트는 업스트림 서비스 키 30개에 접근할 일이 없으니까요. 특정 에이전트에게 더 약하거나 강한 키를 주고 싶으면 한 곳에서 쉽게 설정할 수 있습니다(제 확인을 받아 에이전트에게 그 변경을 대신 요청할 수도 있고요). 매번 새 키를 20개씩 만들 필요도 없고, 업스트림 서비스마다 키를 만드는 UI의 세세한 방법을 기억할 필요도 없습니다.
수정: 하나 더 빠뜨렸는데, API 프록시 덕에 아주 편리한 점이 있습니다. 에이전트에게 CI 설정 변경이나 Google Workspace 사용자·그룹 추가 같은 설정을 UI 없이 그냥 시킬 수 있습니다. 이제 모든 서비스의 관리 설정 거의 전부를 단일 인터페이스(에이전트 CLI)에서 처리합니다.