다른 사람의 저장소가 Claude Code를 탈취하는 방법: 보호 규칙 7가지

Ailoot 문서: API, 키, 설정.

신뢰할 수 없는 텍스트에서 에이전트 동작으로 이어지는 네 가지 문서화된 경로#

정식 용어로는 간접 프롬프트 인젝션이라고 합니다. 악의적인 지시가 사용자에게서 직접 오는 것이 아니라, 에이전트가 작업을 수행하면서 처리하는 데이터, 예를 들어 낯선 README, 오류 메시지, GitHub 댓글 또는 외부 서비스의 응답을 통해 들어옵니다. 이 문단을 읽고 나면 용어는 잊어도 됩니다. 이제부터는 쉬운 말로 설명하겠습니다.

아래에서 살펴볼 연구 예시는 네 가지입니다.

1. 평범해 보이는 저장소가 리버스 셸로 이어질 수 있다는 점이 확인됐습니다.
2. Pull Request 제목 하나로 서로 다른 AI 에이전트 세 개를 동시에 탈취할 수 있다는 점이 확인됐습니다.
3. 에이전트가 실제 오류 보고서 대신 가짜 Sentry 오류 보고서를 받아들일 수 있다는 점이 확인됐습니다.
4. Microsoft는 MCP 도구 설명이 시스템 프롬프트만큼 효과적으로 에이전트를 제어할 수 있다고 경고했습니다.

무해해 보이는 저장소의 README가 어떻게 리버스 셸로 이어질까?#

작동 방식은 개별 단계 어느 하나도 의심스러워 보이지 않도록 설계되어 있습니다.

1. 평범해 보이는 저장소를 복제하고 Claude Code에 실행해 달라고 합니다.
2. 저장소가 처음 사용할 때 실패하도록 설계된 Python 패키지를 가져옵니다.
3. 오류 메시지가 친절하게 “수정” 명령을 제안합니다. python3 -m axiom init
4. init 명령이 setup.sh를 실행합니다.
5. 스크립트가 DNS TXT 레코드를 조회합니다. (보통 도메인 관련 메모에 쓰이지만, 이 필드에는 아무 텍스트나 넣을 수 있습니다.) 공격자는 그곳에 base64로 인코딩한 명령을 넣고, 이를 bash로 곧바로 전달합니다. (base64는 공백이나 특수 문자 없이 임의의 데이터를 일반 텍스트로 바꾸는 방법입니다.)
6. DNS 레코드의 값을 언제든 바꿀 수 있으므로 공격자는 사용자 권한으로 대화형 리버스 셸을 열고 컴퓨터의 모든 비밀 정보에 접근할 수 있습니다.

시연의 최종 페이로드는 실행 중 DNS에서 가져오므로 저장소 바이트만 검사해서는 드러나지 않았습니다. 모든 스캐너나 실행 제어가 무력하다는 증거는 아닙니다. 가져온 내용 검사, 프로세스 관측, 네트워크 제한이 연쇄를 드러내거나 중단할 수 있습니다. 출처는 개념 증명이며 실제 사고 빈도 측정이 아닙니다.

Pull Request 제목 하나가 서로 다른 AI 에이전트 세 개를 어떻게 탈취했을까?#

연구자는 다음 경로와 대응을 설명합니다. 과거 보고서이며 모든 현재 제품 버전의 검증은 아닙니다.

이 공개 과정에서 첫 보고와 마지막 보고 사이에는 거의 5개월이 흘렀습니다. (첫 Claude Code 보고는 2025년 10월 17일, 마지막 GitHub Copilot 버그 수정은 2026년 3월 9일이었습니다.) 보고서의 심각도 변경과 완화 조치가 모든 가능한 페이로드의 완전한 차단을 입증하지는 않습니다. 연구자의 PoC 저장소는 시연한 Claude 경로를 설명합니다. 실제 시스템에서 공격 페이로드를 실행하지 마세요. 여기서 얻을 가치는 공격 패턴 자체에 있습니다. 확인되지 않은 GitHub 데이터가 에이전트에 들어가고, 에이전트가 명령을 실행하며, 같은 GitHub를 통해 비밀 정보가 유출됩니다. 공격자에게 외부 서버는 필요하지 않습니다.

두 가지 분석만으로도 패턴을 알 수 있습니다. 새로운 발견이 나올 때마다 하나씩 수정하는 방식은 현실적이지 않습니다. 이런 종류의 취약점은 2주마다 나타납니다. 보안 규칙을 머릿속에만 두지 않고 CLAUDE.md와 settings.json에 명시적으로 작성하는 것도 컨텍스트 엔지니어링의 일부입니다. 규칙을 한 번 설정하면 매번 상기시키지 않아도 새 Claude Code 세션마다 자동으로 적용됩니다. 세 가지 축이 함께 작동합니다. AI 복제본 + Second Brain + Context Engineering. 이 조합은 Claude Code를 무엇이든 믿고 실행하는 도구에서 명시적인 규칙을 따르는 에이전트로 바꿉니다.

가짜 Sentry 오류 보고서가 에이전트를 장악할 수 있을까?#

공격에 필요한 것은 Sentry DSN 키뿐입니다. 많은 프로젝트가 이 공개 식별자를 클라이언트 측 코드에 직접 넣습니다.

작동 방식은 간단합니다. 개발자가 에이전트에 미해결 Sentry 오류를 살펴보라고 요청합니다. 에이전트는 MCP 서버를 통해 오류를 요청하고, 실제 오류 사이에 섞인 악성 이벤트를 받습니다. 그런 다음 그 안에 포함된 명령을 오류 수정에 필요한 신뢰할 수 있는 지시로 읽습니다. 형식상 바로 그런 작업을 요청받았기 때문입니다.

Tenet은 시험 환경에서 기존 제어가 경고하지 않았다고 보고합니다. 모든 배포에서 흔적이 없다는 뜻은 아닙니다. 에이전트·도구 로그, 기기 관측 정보, 네트워크 기록은 후속 동작을 남길 수 있습니다. 외부 제출 오류 정보로 시작한 뒤 실제 도구와 권한에 의존하는 공격입니다.

MCP 도구 설명이 시스템 프롬프트만큼 위험한 이유는 무엇일까?#

Microsoft의 표현은 이 주제에 관해 제가 찾은 것 중 가장 정확합니다.

무해한 도구 설명에 숨겨진 지시가 에이전트를 조종하는 기법을 도구 포이즈닝이라고 합니다.

이 테스트에서 Claude 3.7 Sonnet은 회복탄력성이 가장 뛰어났지만, 이 모델조차 포이즈닝된 지시를 거부한 경우는 3% 미만이었습니다. 가장 뛰어난 모델조차 보호보다는 운에 더 많이 의존합니다. 벤치마크의 직관에 반하는 결론은 이렇습니다. 모델이 지시를 더 정확하게 따를수록 메타데이터에 숨겨진 명령과 정당한 명령을 구분하는 능력은 더 떨어집니다. 모델의 강점이 오히려 약점으로 작용합니다.

공격의 공통점은 무엇이며 탐지가 놓칠 수 있는 것은 무엇인가요?#

결론은 네 가지 발견 모두에 적용됩니다. “코드가 정상적으로 보인다”는 점에 의존할 수 없습니다. 공격의 각 단계는 실제로도 무해합니다. 실제 역량을 제한하고 제안된 동작을 검사하세요. 탐지와 제한은 공격의 서로 다른 부분을 다룹니다.

Claude Code에는 어떤 보호 기능이 이미 있으며, 왜 충분하지 않을까?#

Anthropic은 문제를 숨기지 않고 문서에서 직접 인정합니다.

문서에 따르면 에이전트는 전체 프롬프트에서 의심스러운 지시를 분석하고, curl과 wget을 자동으로 승인하지 않으며, 웹 콘텐츠를 별도의 컨텍스트 창에 유지해 기본 창과 섞이지 않게 합니다. 또한 새 코드베이스에서 처음 실행하거나 새 MCP 서버에 연결할 때 신뢰 확인을 요구합니다.

하지만 Anthropic이 단도직입적으로 밝힌 중요한 단서가 있습니다.

Claude Code가 “질문으로 귀찮게 하지 않도록” 짜증이 나서 --dangerously-skip-permissions를 사용해 실행한 적이 있다면, 위에서 다룬 네 가지 공격을 막았을 수 있는 모든 장치를 그때 꺼 버린 것입니다. Claude Code가 한 세션에서 열 번째로 다시 물어보더라도 저는 이 플래그를 의도적으로 끄지 않습니다. 귀찮기는 하지만, 그 질문들은 “에이전트가 의심스러운 텍스트를 읽었다”와 “에이전트가 그 텍스트를 실행했다” 사이의 경계입니다. 프로그래머가 아닌 사람에게 적절한 설정은 표준 권한 모드(default 또는 acceptEdits)와 활성화된 샌드박스입니다. 일반적인 파일 수정은 별도의 질문 없이 이뤄지고, 에이전트가 속더라도 터미널 명령은 물리적으로 샌드박스 밖으로 나갈 수 없습니다.

샌드박스 모드를 활성화하고 기본 설정에서 열려 있는 취약점을 막으려면 어떻게 해야 할까?#

모든 프로젝트에서 영구적으로 활성화하려면 ~/.claude/settings.json을 한 번 수정합니다.

{
  "sandbox": { "enabled": true }
}

기본적으로 샌드박스 안의 명령은 프로젝트 작업 디렉터리와 세션의 임시 디렉터리에만 쓸 수 있습니다. 네트워크 접근은 프록시를 통하며, 미리 허용된 도메인은 없습니다. 처음으로 새 도메인에 접속할 때 Claude Code가 확인을 요청합니다. Anthropic에 따르면 회사 내부 측정에서 권한 확인 요청이 84% 감소했습니다. 매번 묻는 대신 샌드박스가 안전한 일부 상황을 직접 처리하기 때문입니다.

표준 설정에서 열려 있는 취약점은 다음과 같습니다. 기본적으로 샌드박스는 쓰기를 제한하지만 ~/.aws/credentials와 ~/.ssh 같은 파일의 읽기는 막지 않습니다. 앞선 공격에서 표적이 된 파일과 환경 변수입니다. 같은 파일에 별도 블록을 추가해 이 취약점을 막습니다.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

즉, 첫 번째 분석에 나온 리버스 셸이 샌드박스 안에서 열리더라도 프로세스가 시작되기 전에 해당 변수와 파일이 환경에서 물리적으로 제거됩니다. 훔칠 것이 남지 않습니다.

오늘 추가해야 할 permissions.deny 규칙은 무엇일까?#

프로그래머가 아닌 사람을 위한 최소 규칙 세트로, 네 가지 공격의 주요 표적을 한꺼번에 다룹니다.

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

Claude Code 문서에 따르면 deny 규칙은 항상 allow 규칙보다 우선합니다. 따라서 사용자나 에이전트가 실수로 다른 곳에서 더 넓은 접근을 허용했더라도 구체적인 deny 규칙이 먼저 적용됩니다. 이 우선순위는 일치한 도구 요청에 적용됩니다. 모든 하위 프로세스나 도구에서 비밀 정보에 접근할 수 없다는 증거는 아니므로 강제 파일시스템·환경 제한도 사용하세요.

Claude Code에는 auto 모드도 있습니다. 대화하는 모델과는 별개인 분류 모델이 실행 전에 동작을 검사합니다. 기본적으로 이 모드는 “코드를 다운로드하고 즉시 실행”하는 패턴(curl | bash) 등을 차단합니다. Anthropic은 이 모드가 요청 횟수를 줄여 주지만 그 자체로 안전을 보장하지 않는 연구용 모드라고 명시적으로 경고합니다. 샌드박스와 permissions.deny를 대체하는 기능이 아니라 추가 보호 계층으로 보세요.

에이전트에게 맡기기 전에 저장소와 MCP 서버를 어떻게 확인할까?#

에이전트에게 맡기기 전에 저장소를 확인할 간단한 점검 목록입니다.

1. 낯선 출처의 이메일, 게시물 또는 리뷰에 있는 링크에서 곧바로 설치하지 마세요.
2. 설치 중 “수정하려면 X 명령을 실행하세요”라는 지시와 함께 오류가 나오면 Claude Code가 실행하도록 허용하기 전에 X가 실제로 무엇을 하는지 읽어보세요. 앞선 분석에 나온 지시는 아주 일상적으로 보였습니다. 그게 바로 핵심이었습니다.
3. 별 개수만 보지 말고 저장소가 만들어진 시기와 커밋 기록을 확인하세요. 새로 만든 저장소에도 이런 공격을 위해 가짜 별점을 쉽게 달 수 있습니다.
4. 낯선 저장소라면 실제 키가 있는 업무용 컴퓨터가 아니라 가상 머신에서 설치를 실행하세요. 외부 서비스를 사용할 때 따르라는 Anthropic의 직접적인 권고입니다.

MCP 서버에 대한 Anthropic의 입장은 공개되어 있습니다.

즉, 설치한 플랫폼이 아니라 사용자가 타사 MCP 서버를 확인할 책임이 있습니다. 주로 보안 스타트업인 일부 팀은 이미 이를 위한 도구를 만들고 있습니다. 포이즈닝된 설명을 찾는 MCP 구성 스캐너와 최초 설치 때 도구 설명의 해시를 저장하고 이후 변경 사항을 표시하는 도구 “고정” 기능입니다. 이러한 기술은 아직 초기 단계이므로 유일한 보호 수단으로 삼기에는 이릅니다. 하지만 특히 MCP 서버를 프로덕션에 연결한다면 지켜볼 가치가 있습니다. 그런 연결에서는 각 패키지 버전을 고정하고 도구 설명의 지문을 감사 로그에 기록할 수 있습니다.

보호를 위한 7가지 규칙: 오늘의 점검 목록#

1. 샌드박스 모드를 활성화하고(/sandbox 또는 ~/.claude/settings.json의 "sandbox": {"enabled": true}), ~/.ssh 및 ~/.aws/credentials를 읽지 못하도록 하는 credentials 블록을 추가합니다.
2. 비밀 파일 읽기와 위험한 bash 명령(curl, wget, sudo)을 차단하는 permissions.deny 규칙을 추가합니다. deny는 항상 allow보다 우선합니다.
3. 외부 또는 확인되지 않은 코드에는 --dangerously-skip-permissions를 절대 사용하지 마세요. 이 플래그는 이러한 공격을 막았을 수 있는 보호 기능까지 모두 한꺼번에 비활성화합니다.
4. 오류 메시지에 나온 “수정” 명령을 Claude Code가 자동 실행하도록 두지 마세요. 먼저 실제로 무엇을 하는지 읽어보세요.
5. 신뢰하는 출처의 MCP 서버만 설치하고, Anthropic이 사용자를 대신해 서버 보안을 검사하지 않는다는 점을 기억하세요.
6. 권한에 따라 세션을 분리하세요. 한 세션은 개인 데이터를 다루고 외부 데이터를 보지 않습니다. 두 번째 세션은 다른 사람의 이메일, 저장소, 티켓을 살펴보지만 비밀 정보에는 접근할 수 없습니다. 세 번째 세션은 외부에 게시하되 사용자가 직접 승인한 내용만 게시합니다. 저는 제 프로젝트에서 이를 엄격하게 지킵니다. 결제 키에 접근할 수 있는 세션은 임의의 외부 티켓이나 저장소를 읽지 않고, 다른 사람의 코드를 분석하는 세션은 비밀 정보를 전혀 보지 않습니다. 한 채팅에서 이 역할을 섞지 마세요.
7. Claude Code와 연결된 자동화 스크립트를 최신 상태로 유지하세요. 이 가이드가 게시될 당시 여기서 논의한 취약점 대부분은 이미 패치로 해결됐고, 새로운 취약점도 비슷한 방식으로 수정됩니다.

다음 단계#

이 보호 계층 중 어느 것도 보장은 아닙니다. Anthropic 역시 어떤 보호 기능도 완전한 면역을 제공하지 않는다고 솔직히 밝힙니다. Claude Code가 오류 메시지나 이슈 댓글의 속임수를 스스로 알아차리리라고 기대하지 않습니다. 저에게 샌드박스와 permissions.deny는 프로젝트 컨텍스트 관리 방식의 일부입니다. 에이전트가 무엇을 보는지, 기본적으로 무엇을 신뢰하는지, 실수했을 때 어떤 일이 벌어지는지를 관리합니다.

Ailoot을 통해 신경망 서비스에 접근해야 한다면 Ailoot을 살펴보세요.