GitHub MCP 악용: MCP를 통한 비공개 저장소 접근

 (invariantlabs.ai)
3P by GN⁺ | ★ favorite | 댓글 2개
  • GitHub 계정에 연결된 MCP 에이전트가 공개 Issue를 읽는 것만으로 비공개 저장소 데이터 유출 경로가 열릴 수 있음
  • 공격은 공개 저장소 Issue에 심은 간접 프롬프트 인젝션이 에이전트의 도구 사용 흐름을 바꾸면서 시작됨
  • 데모에서는 ukend0464/pacman의 악성 Issue가 Claude 4 Opus와 GitHub MCP 연동을 거쳐 비공개 저장소 정보를 공개 PR로 내보냄
  • 문제의 핵심은 GitHub MCP server 코드 결함보다, 신뢰된 도구가 신뢰할 수 없는 외부 콘텐츠와 함께 쓰이는 구조에 있음
  • 저장소별 최소 권한, 세션 단위 접근 제한, MCP-scan 같은 런타임 보안 모니터링이 에이전트 시스템에 필요함

악성 Issue로 시작되는 GitHub MCP 공격

  • Invariant는 널리 쓰이는 GitHub MCP integration에서 공격자가 사용자의 에이전트를 탈취해 비공개 저장소 데이터를 유출시킬 수 있는 취약점을 발견함
    • 해당 GitHub MCP server는 GitHub에서 14k stars를 받은 프로젝트임
    • 취약점은 Invariant의 보안 분석기가 탐지한 초기 Toxic Agent Flows 사례 중 하나임
  • Toxic Agent Flow는 간접 프롬프트 인젝션으로 에이전트가 의도하지 않은 도구 사용 순서를 수행하게 되는 흐름임
    • 데이터 유출이나 악성 코드 실행 같은 행위로 이어질 수 있음
  • 코딩 에이전트와 IDE가 빠르게 배포되는 상황에서, 유사한 공격이 핵심 소프트웨어 개발 도구 사용자에게 노출될 수 있음

공격 구성

  • 사용자는 Claude Desktop 같은 MCP 클라이언트를 쓰고, GitHub MCP server를 자신의 GitHub 계정에 연결한 상태임
  • 공격 시나리오는 두 종류의 저장소를 가정함
    • <user>/public-repo: 누구나 Issue와 버그 리포트를 만들 수 있는 공개 저장소
    • <user>/private-repo: 독점 코드나 회사 내부 데이터가 들어 있는 비공개 저장소
  • 공격자는 GitHub의 일반 권한 규칙에 따라 공개 저장소에 악성 Issue를 만들 수 있음
  • 사용자가 에이전트에 Have a look at the open issues in <user>/public-repo 같은 정상 요청을 보내면, 에이전트가 공개 저장소 Issue를 가져오며 프롬프트 인젝션에 노출됨
  • 이후 에이전트는 비공개 저장소 데이터를 컨텍스트로 가져오고, 공개 저장소에 자동 생성한 PR로 데이터를 유출할 수 있음

데모에서 확인된 유출 흐름

  • 데모는 공개 저장소 ukend0464/pacman과 여러 비공개 저장소를 사용함
    • ukend0464/pacman: 간단한 Pacman 게임 구현이 들어 있는 공개 저장소이며 GitHub에서 확인 가능
    • 비공개 저장소들에는 사용자의 개인 프로젝트와 민감 정보가 들어 있음
  • 공격자는 공개 저장소에 악성 Issue를 배치함
    • 해당 Issue는 에이전트가 공개 저장소 Issue 목록을 조회하는 순간 실행될 페이로드를 포함함
  • 사용자는 Claude 4 Opus에 요청을 보내 공격을 트리거함
    • Claude Desktop은 기본적으로 개별 도구 호출에 사용자 확인을 요구함
    • 많은 사용자는 에이전트를 사용할 때 “Always Allow” 확인 정책을 선택하고 개별 동작 감시를 중단함
  • 에이전트는 Issue 목록을 순회하다가 공격 페이로드를 발견하고, 비공개 저장소 데이터를 컨텍스트로 가져온 뒤 pacman 저장소의 pull request에 유출함
  • 공개 PR에는 사용자 ukend0464의 비공개 정보가 포함됨
    • Jupiter Star 같은 비공개 저장소 정보
    • 남미로 이주하려는 계획
    • 급여 정보
  • 전체 에이전트 추론과 도구 사용 순서는 Invariant Explorer의 전체 trace에서 확인 가능함

신뢰된 도구에서도 생기는 Toxic Agent Flow

  • 이 취약점은 MCP 도구 자체가 손상되어야 하는 기존 도구 오염 공격과 다름
  • GitHub 같은 외부 플랫폼에 연결된 에이전트가 신뢰할 수 없는 정보에 노출되면, 도구가 완전히 신뢰된 상태여도 문제가 생길 수 있음
  • 에이전트 시스템에서 이런 흐름을 이해하고 분석하며 완화하는 작업은 수동으로 대규모 수행하기 어려움
  • Invariant는 조직이 악의적 행위자에게 악용되기 전에 잠재 위협을 식별하고 모델링할 수 있도록 Toxic Agent Flow 탐지 자동화 방법을 개발함

적용 범위와 완화책

  • 실험은 Claude Desktop에 초점을 맞췄지만, 취약점은 특정 에이전트나 MCP 클라이언트에 한정되지 않음
  • GitHub MCP server를 사용하는 모든 에이전트가 기본 모델이나 구현과 무관하게 영향을 받을 수 있음
  • 중요한 점은 이 문제가 GitHub MCP server 코드 자체의 결함이 아니라는 것임
    • 서버 측 패치만으로 GitHub가 단독 해결할 수 있는 취약점이 아님
    • 에이전트 시스템 수준에서 다뤄야 하는 구조적 문제임

  • 세분화된 권한 제어

    • GitHub 같은 MCP 연동을 사용할 때 에이전트 접근 권한을 필요한 저장소로 제한해야 함
    • 전통적인 토큰 기반 권한은 일부 보호를 제공하지만, 에이전트 기능을 제한하는 경직된 제약을 만들 수 있음
    • Invariant는 에이전트 시스템에 맞춘 동적 런타임 보안 계층을 권장함
    • Invariant Guardrails는 에이전트 워크플로에 맞춰 적응하는 컨텍스트 인식 접근 제어를 제공함
    • 예시 정책은 한 세션에서 하나의 저장소만 접근하도록 제한해 저장소 간 정보 유출을 막음
    • 서로 다른 repo 또는 owner에 대한 저장소 관련 도구 호출이 이어지면 위반으로 처리함
    • 전체 정책은 github_policy.txt에서 확인 가능함
    • 적용 방법은 MCP-scan documentation에 있음
    • Guardrails Playground에서 배포 전 정책을 테스트할 수 있음

  • 지속적인 보안 모니터링

    • 예방 조치와 함께 실시간 위협 탐지와 대응을 위한 모니터링이 필요함
    • Invariant는 에이전트와 MCP 시스템 간 상호작용을 지속적으로 감사하기 위해 MCP-scan 같은 전용 보안 스캐너 배포를 권장함
    • MCP-scan의 proxy mode는 기존 에이전트 인프라 수정 없이 MCP 연결을 실시간 스캔할 수 있게 함
    • MCP 트래픽을 프록시로 라우팅하면 가시성과 실시간 보안 위반 스캔을 얻을 수 있음
    • 포괄적 모니터링은 감사 추적을 만들어 잠재 취약점, 악용 시도, 새로운 공격에 대한 보호 상태 확인에 도움이 됨

모델 정렬만으로는 충분하지 않음

  • 실험에는 최신의 정렬 및 보안 훈련이 적용된 Claude 4 Opus가 사용됨
  • 강한 안전 훈련에도 에이전트는 비교적 단순한 프롬프트 인젝션에 조작될 수 있었음
  • 많은 기성 프롬프트 인젝션 탐지 방어도 이 공격을 잡지 못함
  • 에이전트 시스템 보안은 컨텍스트와 환경에 의존함
    • 일반적인 모델 정렬 훈련은 모든 배포 시나리오나 조직별 보안 요구를 예측할 수 없음
    • 시스템 수준 보안 조치가 모델 수준 보호 장치를 보완해야 함

에이전트 보안에서 남는 과제

  • GitHub MCP server를 사용하는 에이전트는 악성 GitHub Issue를 통해 조작되어 비공개 저장소 데이터를 공개 저장소로 유출할 수 있음
  • 이번 취약점은 GitHub MCP에 특화되어 있지만, 유사한 공격은 다른 환경에서도 계속 나타나고 있음
    • Legit Security는 최근 GitLab Duo의 원격 프롬프트 인젝션 취약점을 보고함
  • 대규모 책임 배포를 위해 MCP 연동과 에이전트 시스템에는 MCP-scan과 Guardrails 같은 전용 보안 스캐너와 정책 제어가 필요함

함께 보면 좋은 글 β

crawler   [-]

거창하지만 그냥 프롬프트 인젝션+MCP가 쓸 수 있는 권한이 너무 많아서 생긴 문제네요
그래서 MCP 권한을 외부에서 제어할 수 있는 도구를 홍보하는 느낌입니다
외부에서 입력되는 프롬프트랑 내부에서만 입력하는 프롬프트랑 MCP가 쓸 수 있는 권한이 다르게 하면 좋겠네요

답변달기
GN⁺   [-]
Hacker News 의견들

  • 공격 방식이 잘 이해되지 않음. Claude에 접근 토큰을 주면, 원래 용도가 무엇이든 Claude가 그 토큰으로 허용된 모든 작업을 하도록 설득될 수 있다는 얘기로 보임
    이런 도구를 쓰는 사람이라면 자격 증명을 LLM에 넘기는 순간, 특히 도구 호출을 자동 허용한다면 그 자격 증명이 허용하는 범위까지는 모두 할 수 있다고 봐야 함. 다만 GitHub에는 세분화된 접근 토큰이 있어서 작업 중인 저장소와 필요한 리소스만 허용하도록 만들 수 있음. 그런 자격 증명을 쓰면 LLM이 속아도 피해 범위가 제한되고, 이 공격도 성립하지 않음. 이 공격은 Claude에 GitHub 계정 전역 권한을 준 경우에 의존하는데, 그런 자격 증명은 만들기도 위험하고 Claude에 주는 건 더 위험함

    • 여기서 핵심은 프롬프트 주입 공격에서 거의 항상 그렇듯, LLM이 공격자가 제어하는 데이터, 민감한 정보, 데이터 유출 수단을 동시에 가진다는 데 있음
      에이전트 설계의 “절대 규칙”은 한 세션에서 이 셋 중 최대 두 가지만 LLM이 갖게 하는 것이어야 함. 예를 들어 신뢰할 수 없는 사람이 만든 이슈를 읽는 에이전트는 공격자 데이터에 “오염”된 것으로 봐야 하고, 그 뒤 비공개 정보에 접근한다면 문맥을 비울 때까지 인터넷 접근을 강하게 제한하거나 꺼야 함. 이 모델에서는 저장소별 토큰이 필요 없고, 이 규칙만 지키면 보안 문제가 생길 수 없음. 안타깝게도 MCP는 이를 보장하는 데 필요한 도구를 제공하지 않는 것처럼 보임
    • 권한 범위가 너무 넓은 토큰이 문제인 데 동의함. 동시에 사람들은 저장소마다 잠금 해제를 하지 않아도 되는 범용 에이전트를 원하기 때문에 그런 접근 권한을 가진 토큰을 주고 LLM을 맹신함
      이런 주의는 현명하지만, 실제 생태계의 상당 부분은 이런 관행을 따르지 않음. 이 보고서는 토큰과 신뢰할 수 없는 데이터에 접근할 수 있으면 LLM이 탈취되어 무엇이든 하게 될 수 있다는 점을 알리는 교육 자료에 가까움. 해법은 그 토큰으로 에이전트가 할 수 있는 일과 없는 일을 동적으로 제한하는 것이고, 우리가 한동안 작업해 온 접근도 바로 이것임: https://explorer.invariantlabs.ai/docs/guardrails/
    • Railway 같은 배포 서비스에도 적용되는 얘기임. 단일 프로젝트만 배포하면 되는데도 모든 GitHub 저장소 접근을 요구함
      반면 Netlify는 배포하려는 저장소에만 접근하도록 존중함. GitHub는 접근 제어를 존중하지 않는 앱을 승인하지 말아야 함
    • 현재 직장에서 받는 보안 취약점 보고서의 80%가 이런 식임
      길고 복잡하게 “X에게 Y를 할 권한을 줬고 공격자가 X를 가져가면 Y를 할 수 있다”고 말하는 형태임
    • 챗봇을 사용자에게 노출한다면, 챗봇이 허용된 모든 일에 사용될 수 있다고 가정해야 함. 이는 API 위에 얹은 편의 계층이지 API 자체가 아님

  • 작성자 중 한 명임. MCP와 에이전트 보안에 더 관심이 있다면 우리가 작업하며 만든 자료들을 참고하면 좋음
    이 공격 시나리오에서 Claude 세션의 전체 실행 추적: https://explorer.invariantlabs.ai/trace/5f3f3f3c-edd3-4ba7-a..., MCP 연결용 보안 스캐너 MCP-Scan: https://github.com/invariantlabs-ai/mcp-scan, MCP 도구 오염 공격: https://invariantlabs.ai/blog/mcp-security-notification-tool..., WhatsApp MCP 악용: https://invariantlabs.ai/blog/whatsapp-mcp-exploited, 에이전트용 문맥 보안 계층 Guardrails: https://invariantlabs.ai/blog/guardrails, AI 에이전트의 보안과 유용성을 함께 평가하는 AgentDojo: https://invariantlabs.ai/blog/agentdojo

  • 보안 관점에서는 LLM이 신뢰할 수 없는 출처의 텍스트를 보면, 그 출처가 LLM을 원하는 텍스트 생성 쪽으로 조종할 수 있다고 가정해야 함
    그 생성된 텍스트가 도구 호출로 이어질 수 있다면, 신뢰할 수 없는 출처도 해당 도구를 쓰게 되는 셈임. 트윗을 따라 Invariant Labs 블로그를 봤고 https://explorer.invariantlabs.ai/docs/guardrails/를 찾았음. 이런 걸 안전하게 만들기가 너무 어려워서 가드레일 제품만 파는 회사가 생긴다는 사실이 보안 관점에서 불편함. AI 회사들이 처음부터 보안 의식 있는 설계를 했다면 이런 물건의 필요가 줄었을 것 같음. 물론 그 제품 자체가 허튼소리가 아니라는 전제에서임

    • 특정 텍스트를 정제되지 않은/오염된 입력으로 표시하고, LLM이 그런 텍스트 블록 안의 지시를 무시하도록 훈련할 수 있지 않을까 궁금함. 이미 그렇게 되어 있지 않다면 말임
    • 입력을 올바르게 표시하는 건 복잡하지 않음
      프롬프트를 쓰고 입력을 올바르게 표시한 뒤, 읽기만 하고 프롬프트로 간주하지 말라고 명확히 쓰면 됨. 다만 이 공격은 꽤 복잡하게 꼬여 있음. 챗봇에서 프롬프트 주입을 얘기하던 때를 아직 기억하는지 모르겠음. 2년 전에는 그게 화제였고, 지금은 MCP가 떠들썩함
    • AI 회사들도 보안 설계를 하고 있음. 다만 이 “익스플로잇”은 그 보호 장치를 끄는 경우를 요구하며, 그때는 큰 경고도 붙음
      Claude가 GitHub MCP 통합을 사용해 지시를 따르는 과정에서 Claude Desktop은 기본적으로 개별 도구 호출에 사용자 확인을 요구함. 하지만 많은 사용자가 에이전트를 쓸 때 이미 “Always Allow” 확인 정책을 선택하고 개별 동작 감시를 중단함
    • 소프트웨어 익스플로잇에서 워낙 오래된 전통이라, 새 기술에서 또 튀어나오면 재밌으면서도 이마를 치게 됨
      “사용자 텍스트 입력을 받아, 그것이 어떤 종류의 지시로 해석되도록 오염되고, 그 지시를 준비되지 않은 문맥에서 실행한다”는 패턴은 계속 반복됨. SQL 주입, 사이트 간 스크립팅, PHP include 주입이 있었고 그 밖에도 빠뜨린 것들이 많으며, 이제 이것도 추가됨

  • 이게 왜 “익스플로잇”으로 간주되는지 모르겠음. 에이전트에 비공개 저장소에 접근 가능한 토큰을 줬고, MCP는 그냥 API 서버임
    그 API에 뭔가 노출되길 원하지 않는다면 권한을 주지 않으면 됨

    • 실제로 글을 읽기 전에 댓글부터 보는 사람이 많듯, 나도 그랬음
      그렇게 보면 금방 알 수 있듯 이 글에는 공격이 들어 있음. 악성 이슈가 GitHub에 올라가고, 그 이슈에는 데이터 유출을 유도하도록 설계된 LLM 프롬프트가 포함됨. GitHub 계정 소유자가 에이전트를 실행하면, 에이전트가 저장소 소유자를 대신해 그 악성 프롬프트에 따라 행동함
    • 이건 인간의 취약함을 악용하므로 익스플로잇임. 사용자가 과장 광고를 맹신하고 안전하다고 생각해 GitHub 비공개 저장소 전체 접근 권한을 주는 취약함을 찌름
    • 주제가 심각하니 다소 꼼꼼하게 말하겠음. AI 실행 도구를 돌리는 게 정확히 얼마나 위험한지 모두가 이해하는 게 중요함
      에이전트는 현재 주의(attention)에 따라 여러 도구를 실행하고, 그 주의는 실행한 도구의 결과에 영향을 받을 수 있음. 처음에 “성격”을 부여하는 것만으로도 도구 실행 방식이 바뀌는 걸 본 적이 있음. 그런데 사용자가 처음부터 정보 접근 권한을 준 것이 잘못이지, 실행 중 정보를 읽는 방식이 문제는 아니라고 말하는 듯함. 이는 혼란스러운 대리자 문제를 여러 사람이 설명했는데도 “접근 권한을 줬으니 네 잘못”이라는 결함 있는 논리로 되돌아가는 태도처럼 보임. 용어를 지적받으면 “공격이 아니다”에서 “취약점이 아니다”, 다시 “MCP 잘못이 아니다”로 옮겨가며 실제 기술 문제를 다루지 않음. MCP가 이후 접근 제한을 위한 적절한 도구나 기록 없이 접근을 부여한다는 점은 분명 MCP의 잘못임. 적어도 문제가 생겼을 때 어떻게 잘못되는지 보려고 MCP 쪽에는 대량 기록을 켜 둠
      합법적인 보안 발견을 “상식”으로 치부하고 연구자가 이런 익스플로잇을 문서화해 공개하는 데 짜증을 내는 듯한 태도는 교육적 가치를 놓침. 보안 얘기를 하는 것이 잘못일 수는 없음. 전제가 약하거나 위협이 작을 수는 있어도, 사용자의 잘못이라고만 할 수는 없음. 검색엔진에 비밀번호를 넣는 비유처럼 실제 공격 벡터와 맞지 않는 비유를 쓰면서, SQL 주입 같은 적절한 비교는 거부함. 사실 이건 거의 SQL 주입과 같고, 그 논의에서는 아무도 이런 식으로 주장하지 않음. Little Bobby Tables는 여전히 살아 있음
      핵심은 직접 접근 남용이 아니라, 제3자가 공개 GitHub 이슈를 올려 시스템을 조종해 허가받지 않은 접근을 얻는 간접성임. AI가 어떤 도구의 출력에 따라 다른 도구를 실행하다가 해서는 안 될 일을 한다면 실제 우려임. 이런 식으로 도구를 한 번에 하나만 실행하라고 권하는 건 Elmer’s 접착제 냄새를 들이마시는 수준이라고 봄. 여러 지식 있는 사람이 왜 반대하는지 이해하려 하기보다 방어적으로 버티며 글을 많이 올렸고, 그만큼 이 댓글이 논쟁적이었다는 건 분명함. 여기서 메타 얘기를 하면 안 되는지도 모르겠지만, 이런 것에 열정이 있고 남들이 어떻게 생각하든 신경 덜 쓰는 이상한 면도 있어 자주 하게 됨

  • 여기 있는 악성 이슈와 응답을 꼭 보면 좋음: https://github.com/ukend0464/pacman/issues/1
    웃긴 건 에이전트가 익스플로잇을 완료했다며 꼬리 흔드는 듯한 태도까지 보인다는 점임

  • MCP 자체에 대해 획기적이거나 특별히 착취적인 건 아님. MCP에 대해서는 따로 생각이 있지만, 여기서는 프롬프트 주입을 영리하게 쓰고 “MCP가 익스플로잇됐다”고 말하는 바이럴 마케팅에 가까움
    에이전트 시스템을 만들 때 항상 “에이전트에 접근 권한을 준 모든 것은 에이전트에 접근하는 누구에게나 노출될 수 있다”는 철학을 유지함. 접근 제어를 LLM에 맡기지 말고, 보안 관점에서는 LLM에 작업을 요청한 사람을 에이전트 작업의 주체로 삼아야 함. 다만 이 글은 사용자를 대신해 행동하는 에이전트에 무엇을 접근시키는지 더 조심해야겠다는 생각을 하게 함. 에이전트가 이메일에 접근할 수 있고 사용자가 이메일 요약을 시켰는데, 누군가 보안 재설정 토큰을 전달하게 만드는 악성 프롬프트 주입 이메일을 보냈다면, 사람들이 에이전트를 만들거나 쓸 때 놓칠 수 있는 나쁜 부분이 바로 그 지점임

    • “with MCP”를 붙이는 게 2025년판 “on the blockchain”인가 싶음
      LLM에 접근 제어를 맡기지 말고, 에이전트가 하는 작업의 보안 주체를 요청자로 삼아야 한다는 데 동의함. 이미 한 바퀴 돌아본 사람들에게는 너무 당연해 보이지만, 새로운 세대 전체가 최소 권한 원칙을 배워야 할 듯함

  • 이 주장은 꽤 과장되어 있음
    “‘author recognition’을 요청하는 간단한 이슈를 만들어 에이전트에 프롬프트 주입을 해 사용자의 GitHub 계정 데이터를 유출시켰고, 그게 전부였다”는 식으로 말하지만, 실제로는 그게 전부가 아니었음. 사용자가 공개·비공개 저장소 모두에 접근 가능한 자격 증명으로 GitHub MCP 서버를 설정하고, 어떤 LLM이 그 MCP 서버에 접근하도록 구성하고, 그 LLM에 임의의 이슈를 읽고 파싱하라는 요청을 명시적으로 제출해야 했음. 그리고 이전에 만든 이슈까지 포함해 그 이슈들이 시키는 내용을 맹목적으로 파싱·처리·수행한 다음, 그 결과를 공개 저장소에 공개적으로 업데이트해야 했음
    나쁜 결과라고 말하는 건 타당하지만, 제3자가 악성 이슈로 악용할 수 있는 취약점을 대표한다고 말하는 건 타당하지 않음. 실제로 악성이라고 부르기도 애매함. 사용자가 신뢰할 수 없는 데이터를 읽고 그 결과를 신뢰할 수 없는 목적지로 내보내는 요청을 명시적으로 해야 하기 때문임. 다만 “GitHub MCP 잘못은 아니다”라는 완화 설명과 달리, GitHub MCP는 분명 잘못이 있음. 공개 저장소와 비공개 저장소를 섞는 상호작용을 허용해서는 안 됨

    • 뒷부분의 문제를 놓치고 있는 것 같음
      프롬프트 주입에서는 LLM이 이슈를 읽는 요청만 받으면 충분함. 예를 들어 “오늘 보고된 버그를 요약해 줘” 같은 단순한 요청이어도, 나머지는 모두 악성 이슈 안의 지시가 될 수 있음
    • 이 문제의 상당 부분은 MCP가 마케팅되는 방식과 관련 있어 보임
      프로토콜 자체는 데이터 접근을 맡겨도 되는 신뢰된 사용자와 격리된 환경에서만 써야 한다고 봄. MCP 서버에 대해 사용자의 범위 지정이나 인증을 표준화하는 방식이 없어 보이고, 그게 이 구현 퍼즐에서 빠진 조각임. GitHub MCP가 잘못이라기보다 업계 전체가 이 기술을 잘못 사용하거나 구현하고 있음. 내가 만드는 맞춤 MCP 서버도 동작시키려면 여전히 ID, JWT 같은 비AI 문맥 정보를 조금 넘겨야 함
    • 공정하게 말하면, 지금의 AI 열풍 속에서는 많은 사람이 바로 이런 일을 별생각 없이 할 것임
      “그러면 안 되지, 바보들아”라고 할 수는 있음. 맞는 말임. 하지만 사람들이 자주 어리석게 행동하기 때문에 가드레일이 필요한 것임
    • GitHub MCP 서버를 설정하고 LLM이 그 서버에 접근하도록 구성하는 건 LLM이 하라고 권할 법한 일처럼 들림
    • 공개 저장소와 비공개 저장소 간 혼합 상호작용을 허용하면 안 된다고 하지만, 이건 별개의 도구 호출임. MCP 서버가 그 둘이 상호작용한다는 걸 어떻게 알 수 있겠음?

  • 지난주 Google의 Jules 코딩 에이전트를 써 봤는데, GitHub OAuth 권한을 매우 넓게 요구했음. 사실상 “계정이 할 수 있는 모든 것에 대한 전체 접근”이었고, 승인하면 모든 저장소 접근 권한을 주는 셈임
    이는 에이전트 쪽 개발 편의성 때문이기도 하지만 GitHub OAuth 흐름의 영향도 큼. 승인 과정에서 범위를 줄인 권한을 만들고, 나중에 앱이 추가 접근을 요청할 수 있게 하는 일이 더 쉬워야 함. 에이전트가 특정 저장소로 범위가 제한된 승인 요청을 제출하게 하는 것도 쉬워야 함
    대신 명시적으로 Jules가 건드리길 원하는 저장소와 권한만 부여한 보조 GitHub 계정(https://github.com/jmandel-via-jules)을 만들어야 했음. 꽤 불편하지만, 잠재적으로 모든 것을 노출하지 않고 이런 에이전트를 안전하게 쓰는 다른 방법이 보이지 않음. GitHub도 애플리케이션 전용 계정인 “machine users” 생성을 인정하므로 이 접근은 타당하지만, 기본적인 저장소 범위 지정에 필요해서는 안 됨. 혹시 놓친 더 쉬운 방법이 있다면 알려주면 좋겠음

  • URL을 보면 현재 논의는 https://news.ycombinator.com/item?id=44100082에서 진행 중인 것 같음

    • 그쪽에서도 적었듯, 이건 그다지 공격이라고 보기 어려움
      필요한 조건은 시스템에 비공개 데이터 접근 권한을 주고, 외부 사용자에게 그 시스템 접근 권한을 주는 것임. LLM 기반 시스템에 비공개 데이터 접근 권한을 준 뒤 외부 사용자가 그 시스템에 임의 텍스트를 입력할 수 있게 하면, 간접적으로 외부 사용자에게 비공개 데이터 접근을 준 셈이라는 건 명백해야 함. 표준 보안 모범 사례로 쉽게 해결 가능함
    • 댓글은 이후 https://news.ycombinator.com/item?id=44097390로 옮겨졌음. 이 글이 먼저 올라왔기 때문임

  • MCP는 하나의 프로토콜일 뿐이고, A2A 같은 비슷한 역할을 할 다른 것들도 이미 있음. 더 원초적인 형태로는 LLM에게 GitHub API 문서를 읽고 이 인증 토큰으로 필요할 때 쓰라고 할 수도 있음
    아직 어떤 LLM이 그 정도로 강력한지는 모르겠지만, 분명 그렇게 될 것임. 이런 도구 등록 메커니즘을 모두 안전하게 만드는 방법은 사실상 없다고 봄. 결국 데이터를 유출하는 쪽의 잘못은 LLM에 있기 때문임. 사람들은 생산성을 높이려고 LLM을 쓰고 싶어 함. LLM에 증명 가능한 안전장치가 필요해지거나, 가능성은 낮아 보이지만, 조직들이 모든 노트북에 보안 방화벽을 추가해야 할 것임. 지금까지는 개발자를 정교한 사용자로 신뢰할 수 있었을지 몰라도 LLM은 절대 그럴 수 없음. 다만 보안 방화벽마저 나쁘게 행동하는 LLM을 찾는 데 LLM을 쓴다면 최종 결과를 어떻게 생각해야 할지는 잘 모르겠음

답변달기