GitLost: GitHub AI 에이전트를 속여 비공개 저장소 유출

 (noma.security)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Noma Labs는 GitHub Agentic Workflows에서 간접 프롬프트 인젝션 취약점 GitLost를 발견했으며, 공개 저장소 이슈만으로 같은 조직의 비공개 저장소 데이터를 공개 댓글에 노출시킬 수 있었음
  • 이 기능은 Markdown 워크플로를 YAML Actions 파일로 컴파일하고, Claude 또는 GitHub Copilot 기반 AI 에이전트가 이슈를 읽고 도구를 호출하며 조직 내 저장소에 접근하는 구조임
  • 취약한 워크플로는 issues.assigned 이벤트에서 이슈의 Title과 Body를 읽고 add-comment로 응답했으며, 공개·비공개 저장소 읽기 권한을 가진 상태였음
  • 공격자는 코드, 접근 권한, 자격 증명 없이 공개 저장소에 그럴듯한 이슈를 열기만 하면 됐고, 테스트에서는 poc와 testlocal의 README.md 내용이 공개 이슈 댓글에 게시됨
  • GitHub의 가드레일은 “Additionally” 변형에서 의도대로 막지 못했고, 에이전트형 AI에서는 컨텍스트 창 자체를 공격 표면으로 보고 사용자 제어 콘텐츠를 신뢰된 지시문과 분리해야 함

GitLost가 노린 신뢰 경계

  • Noma Labs는 GitHub의 새 Agentic Workflows에서 GitLost라는 취약점을 발견함
  • 인증되지 않은 공격자가 같은 조직의 공개 저장소에 조작된 GitHub Issue를 게시하면, 에이전트가 조직 내 비공개 저장소 데이터를 가져오도록 유도될 수 있었음
  • 공격 방식은 AI 에이전트가 읽는 콘텐츠 안에 악성 지시를 숨기는 간접 프롬프트 인젝션에 해당함
  • 운영자가 의도한 지시보다 공격자가 숨긴 지시가 우선 처리되면, 비공개 데이터가 누구나 볼 수 있는 공개 이슈 댓글로 노출될 수 있음

GitHub Agentic Workflows의 동작 방식

  • GitHub Agentic Workflows는 팀이 저장소 자동화를 자연어로 작성할 수 있게 함
  • 워크플로는 Markdown .md 파일로 작성되고, YAML 형식의 GitHub Actions .yml 파일로 컴파일됨
  • 실행 시 Claude 또는 GitHub Copilot 기반 AI 에이전트가 설정된 권한 안에서 작업함
    • GitHub Issue 읽기
    • 도구 호출
    • 조직 내 다른 저장소 접근

취약한 워크플로 조건

  • Noma Labs가 확인한 취약한 설정은 공개 이슈와 에이전트 권한이 결합될 때 문제가 됨
    • GitHub의 issues.assigned 이벤트에서 워크플로 트리거
    • 이슈의 Title과 Body 읽기
    • add-comment 도구로 댓글 게시
    • 조직 내 다른 저장소 읽기 권한 보유
      • 공개 저장소
      • 비공개 저장소
  • 공격자에게 별도의 코드 작성, 접근 권한, 자격 증명은 필요 없었음
  • 필요한 조건은 GitHub Agentic Workflow를 쓰는 조직의 공개 저장소에 이슈를 여는 것뿐이었음

공격 흐름

  • 연구진은 고객 미팅 이후 VP Sales가 요청하는 것처럼 보이는 그럴듯한 GitHub Issue를 작성함
  • 이슈가 할당되자 워크플로 액션이 트리거됐고, 테스트에서는 다른 GitHub workflow action에서도 같은 방식으로 동작함
  • GitHub 자동화가 이슈를 할당한 뒤, 이벤트로 실행된 워크플로가 에이전트에게 저장소 내용을 가져오게 함
  • 에이전트는 다음 저장소의 README.md 내용을 가져오도록 유도됨
    • poc 공개 저장소
    • testlocal 비공개 저장소
  • 이후 GitHub 에이전트가 해당 내용을 공개 저장소의 이슈 댓글로 게시해 누구나 읽을 수 있는 상태가 됨

“Additionally”로 가드레일 우회

  • GitHub에는 이 시나리오를 막기 위한 제한적 가드레일이 있었음
  • Noma Labs는 공격자처럼 여러 변형을 반복 테스트함
  • “Additionally”라는 키워드를 추가하자 모델이 거부하지 않고 출력을 재구성하는 의도치 않은 동작이 발생함
  • 이 우회로 GitHub의 가드레일은 의도대로 작동하지 않았고, 데이터 유출을 막지 못함

PoC와 노출된 데이터

에이전트형 AI에서 달라지는 보안 전제

  • 에이전트의 컨텍스트 창은 작업 공간인 동시에 공격 표면이 됨
  • 에이전트가 읽는 콘텐츠는 모두 무기화될 수 있음
    • 이슈
    • Pull Request
    • 댓글
    • 파일
  • 전통적인 보안 모델은 신뢰 경계가 코드로 강제된다고 가정하는 경우가 많음
  • 에이전트형 시스템에서는 신뢰 경계 일부가 모델의 동작에 의해 강제됨
  • 모델은 본질적으로 지시를 따르기 때문에, 프롬프트 인젝션은 에이전트형 AI에서 SQL 인젝션이 웹 애플리케이션에 가졌던 것과 같은 범주형 취약점이 됨
  • 이 취약점 유형에는 체계적인 전략과 방어가 필요함

권장 방어책과 공개 절차

  • 사용자 제어 콘텐츠를 AI 에이전트의 신뢰된 지시 입력으로 취급하지 않아야 함
  • 에이전트 권한은 필요한 최소 범위로 제한해야 함
    • 여러 저장소에 접근할 수 있는 에이전트는 특히 가치 높은 공격 대상이 됨
  • 이슈 콘텐츠에 응답하는 경우처럼, 에이전트가 공개적으로 게시할 수 있는 내용을 제한해야 함
  • 사용자 입력을 모델에 전달하기 전에 지시문 컨텍스트에서 정제하거나 격리해야 함
  • GitLost는 GitHub에 책임 있게 공개됐고, 취약점 세부사항은 GitHub가 인지한 상태에서 공유됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 프롬프트 인젝션이 에이전트형 AI에서 SQL 인젝션이 웹 앱에 가졌던 위치와 같다는 비유는 이상함. 프롬프트 인젝션은 SQL 인젝션보다 LLM에 훨씬 치명적인 것 아닌가 싶음
    SQL 인젝션은 사용자 입력이 SQL 엔진에 전달되는 명령 문자열 일부가 되면서 생겼고, 악성 입력이 SQL 문법 토큰으로 현재 명령을 끝낸 뒤 자기 SQL 명령을 붙이면 엔진이 둘 다 실행했음. 해결책은 준비된 문장처럼 고정·정적·사전 컴파일된 명령 문자열을 쓰고, 임의 사용자 입력은 데이터로만 적용하는 것이었음
    에이전트에서 비슷한 완화책은 “repo 1 읽기”, “repo 2 읽기” 같은 고정 동작을 두고 사용자 입력은 어떤 동작을 실행할지 고르는 데이터로만 쓰는 방식인데, 이건 이미 메뉴라고 부르는 기술임. LLM의 가치는 본질적으로 메뉴 이상이라는 데 있고, SQL의 가치는 “임의 데이터에 적용되는 사전 정의 로직” 이상일 필요가 없다는 점이 다름

    • 맞음. SQL 인젝션은 사용자 입력을 순수 데이터가 아니라 명령의 일부로 취급해서 생겼고, 둘을 분리하니 해결됐음. 프롬프트 인젝션은 사용자 입력 자체가 명령으로 의도되기 때문에 피하기 어려움
    • “해결책은 준비된 문장”이라기보다 핵심은 매개변수 바인딩임. 매개변수를 SQL 문장과 따로 제출해 코드와 사용자 데이터를 분리하는 것임
      에이전트에 제한된 동작만 허용하는 건 일부 특수 문제만 다루며, 코드와 사용자 데이터를 분리하지도 않으니 같은 문제가 아님. 제한된 동작만 두는 건 더 엄격한 데이터베이스 권한을 쓰는 것에 가까움. 사용자가 어차피 실행할 수 있는 SQL만 허용된다면 SQL 인젝션도 별 의미가 없어짐
    • SQL 인젝션과 같은 유형의 문제이긴 하지만, 해결 난이도는 같지 않음. 더 미묘한 문제가 많이 생길 수 있지만 설명용 비유로는 괜찮은 편임
      메뉴에서 고르게 하는 것도 한 방법이지만 가능한 행동 범위는 더 넓게 설계할 수 있음. 이메일 도구를 주면 고객에게 스팸을 보낼 수 있고, 답장만 가능하도록 잠그면 사고 범위를 줄일 수 있음. 이미지 렌더링으로 데이터가 새는 식의 취약점처럼, 데이터 유출도 제한해야 함
    • 프롬프트 인젝션은 치명적이지도 않고, 사실상 진짜 문제라기보다 밑바탕의 보안 아키텍처 문제를 드러내는 것에 가까움. 인간 대상 사회공학 공격과 비슷함
      해결책도 같음. 최소 권한의 역할 기반 접근 제어를 적용하고, 중요한 행동에는 관리자 승인을 요구하면 됨. 그러면 LLM이 혼자 할 수 있는 최악은 부적절한 단어를 출력하는 정도임
    • 이게 모두가 생각하는 만큼 깊은 문제인지 확신이 안 듦. SQL 인젝션도 똑같이 위험함. 쿼리 사용자가 수행할 수 있는 모든 데이터베이스 작업에 무제한 접근을 열어주기 때문임
      완화책 중 하나는 준비된 문장이지만, 다른 하나는 어떤 사용자에게도 데이터베이스 전체 접근을 허용하지 않는 것임. 읽기 전용 사용자는 SQL 인젝션 여부와 무관하게 DROP TABLE을 할 수 없어야 함
      이 에이전트는 무제한 읽기 접근을 갖고 있고, 답변의 “수신자” 개념이 없음. 수신자의 권한을 포함시키면 자동으로 읽기 접근이 거부되게 만드는 건 꽤 단순함. 유일한 해결책은 아니지만 그런 방향의 해법을 떠올리기 어렵지 않음
      “메뉴” 예시는 달라진 게 없다는 뜻이기도 함. LLM이든 인간 직원이든 허용되는 건 통제된 고정 행동 집합뿐임. 자유도는 주로 표현에 있고, 권한 부여는 고정 집합임. 왜 메뉴 이상이어야 하는지 모르겠음

  • 이게 왜 GitHub 취약점인지 모르겠음. 연구자들이 에이전트에 비공개 저장소 접근 권한을 주고, 공개 저장소에서 질문에 답하게 했으니 당연히 비공개 정보 추출이 가능함
    비밀값에 접근 가능한 일반 CI 작업을 만들어 공개 PR에서 실행하는 것과 같음. 공개 코드나 LLM 지시가 민감한 것에 접근 가능한 문맥에서 실행되도록 GitHub를 설정하면 유출됨. 그건 GitHub 잘못이 아니라 설정한 사람 잘못임

    • 현재 질문하는 저장소에만 권한이 제한되고, 비공개 저장소까지는 포함되지 않는다고 가정한 것 같음. 양쪽 논리 모두 이해는 감
    • GitHub가 에이전트 접근을 안전하게 설정하기 쉽게 만들어주지는 않음. 일반 접근 토큰과 앱 자격 증명은 비공개 저장소에 직접 접근시키기엔 세분화된 제어가 충분하지 않음
      토큰 범위를 빡빡하게 잡아도 공개 저장소 접근은 항상 허용되고, 예를 들어 공개 저장소 이슈를 통한 유출 경로가 남음. 안전하게 하려면 GitHub가 제공하는 것보다 더 엄격한 제어를 구현하는 MITM 프록시로 보완해야 함
      GitHub Agentic workflows가 이런 문제를 위한 공식 1차 해결책일 텐데, 보안 모델이든 안전한 사용성 측면이든 아직 할 일이 있어 보임
      자세한 내용: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • 이런 프롬프트 인젝션 공격의 핵심에는 에이전트 권한 범위를 제대로 제한하지 못한 문제가 있음. 이 경우 실제로 에이전트가 해야 하는 일에 따라 저장소별로 별도 워크플로 에이전트를 두거나, 더 넓은 저장소 접근권을 가진 에이전트를 두되 허용 목록의 사용자에게만 트리거되도록 설정할 수 있음
      공개 개발과도 양립 가능하고, 외부인이 공개 이슈를 여는 것도 허용하면서 각 사용자에게 둘 신뢰 수준을 반영할 수 있음. 제대로 생각해보면 선택지는 더 많을 것임
      그러려면 세밀한 범위 지정과 권한을 기술적으로 지원해야 하고, 에이전트로 무엇을 달성할지와 그에 필요한 최소 권한·기능을 시간을 들여 따져야 함
      첫 번째는 올 것 같음. 아직 에이전트 사용은 서부 개척 시대임. 사람이 에이전트를 설계할 때 범위와 권한을 찾고 정의하는 마찰을 줄이는 추상화, 에이전트 기능을 제한할 때 세밀함과 사용성 사이의 균형을 잡는 인터페이스가 무엇이 될지 흥미로움
      두 번째는 늘 고품질 소프트웨어 구축을 막아온 핵심 장애물임. 제대로 생각하고 제대로 구현할 시간을 들이는 일은 “빠르게 움직이고 부수기” 식으로 에이전트를 아무 데나 던지는 방식과 정면으로 어긋남
    • 에이전트형 워크플로별로 접근을 나눠서, 하나는 민감한 데이터에 접근하고 다른 하나는 공개 데이터에만 접근하게 할 수 있는 방법이 있는가? 기본값은 현재 저장소로만 범위를 제한하는가? GitHub가 비공개 저장소 데이터 접근과 에이전트형 워크플로 결합의 위험을 적절히 알려주는가?
      이 질문 중 하나라도 답이 “아니오”라면 문제임. 고전적인 GitHub Workflows도 PR 트리거 워크플로를 통한 권한 상승이 잔뜩 있지만 그건 별도 주제임
    • 권한 관점에서 LLM은 그냥 멍청한 터미널임. 원하는 건 프롬프트를 바탕으로 즉석에서 합성 권한을 만드는 것처럼 보이는데, 이건 “준비된 문장” 해법이 아니라 “정규식으로 사용자 SQL 문을 깨끗이 만들겠다”에 가까움. 그 결말은 이미 잘 앎
      진짜 해법은 프롬프트별 권한 제어 UI를 더 좋게 만드는 것임. “웹 검색 여부”를 고르듯 “내 비공개 저장소 포함” 옵션을 쉽게 켜고 끌 수 있어야 함

  • 연구자들이 “Additionally” 같은 단어 하나로 GitHub가 자랑하던 가드레일을 우회하는 모습이 웃김. LLM 문맥 창 안에 강한 보안 경계를 세우려는 시도는 실패할 수밖에 없다는 걸 보여줌
    모델은 본질적으로 지시를 따르도록 만들어졌기 때문에, 시스템 규칙과 사용자 입력을 섞으면 더 최신이거나 더 집요한 지시가 이기게 됨

  • “책임 있는 공개” 섹션에 언제 수정됐는지, GitHub가 인정했는지 거부했는지가 왜 없을까? GitLost가 GitHub에 책임 있게 공개됐고 세부 정보는 GitHub가 아는 상태에서 공유한다고 되어 있는데, 아직 고치지 않은 건가?

    • 이건 일반적인 소프트웨어 버그가 아니고, 일반 지원 직원이 속는 일을 “수정”할 수 없는 것처럼 같은 방식으로 고칠 수 없음. 답은 LLM에 신뢰할 수 없는 입력과 민감한 데이터를 동시에 접근시키지 않는 것임
    • 원글 작성자가 아래 설정을 켠 상태로 실험했는지 궁금함. 이걸 막는 문자 그대로의 설정이 있음. 이 보고 때문에 생긴 설정인지, 아니면 보고자가 이걸 코멘트로 달지 않은 부주의인지 알고 싶음
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • 뭘 고친다는 건가? LLM에 비공개 데이터 접근권과 공개 댓글 읽기 능력을 함께 준 것뿐임. 그냥 잘못된 설정임

  • Microsoft 같은 대기업은 투자자 압박 때문에 이제 AI 회사라고 주장하려고 모든 제품에 AI를 얹고 있음. Adobe가 했던 것과 비슷함
    소비자는 이런 반쯤 만든 AI 통합에 지쳐가고 있고, 곧 한계점이 올 것 같음

    • 난 끝났음. Forgejo로 옮김. 훌륭하고 모든 게 더 잘 동작함
      진지하게, 여기저기 클릭할 때 모든 게 즉각적이고 러너를 붙인 CI도 아름답게 돌아감. 러너 설정 문서는 조금 더 명확할 수 있지만, 그 외에는 전부 너무 매끄러웠음
    • Microsoft는 상장사임. 어떤 투자자가 원치 않는 AI 기능으로 GitHub를 망치게 압박하고 있는 건가? 어느 자리에서 그런 일이 벌어짐?
    • 동의하지만 기업용 AI 제품은 꽤 인상적이라고 봄. 투자자와 소비자는 잘 모르고, 직원은 거래할 수 없음
      매출은 실제로 존재하고 인상적이며, 소비자·좌석 기반 매출을 대체하고 있음. 시장은 아직 SaaS 배수를 낮추는 중인데 그 판단은 맞다고 봄. 분기 보고서에서 매출을 분리해 보면 실제 효율성에서 나온 큰 성장 스토리가 있음

  • 공개 저장소 문맥에서 실행되는 액션이 왜 비공개 저장소 접근권을 갖고 있었는지 모르겠음. 워크플로를 보면 보통 비공개 저장소 권한을 주지 않는 github token을 쓰는 것처럼 보임
    아니면 에이전트 자체가 somehow 더 높은 권한을 갖고 있었던 건가? 그렇다면 에이전트를 잘못 설정한 것임. 에이전트가 무엇인가를 강제한다고 믿으면 안 된다는 건 이미 알고 있음

  • 이 글은 Noma 마케팅처럼 읽힘. 귀여운 이름, 로고, 낚시성 제목, 비기술 독자를 겨냥한 듯한 극적인 톤까지 있음
    실제 취약점이 뭔가 하면, LLM에 비공개 데이터를 주고 아무나 상호작용하게 하면 데이터가 샐 수 있다는 것임. 너무 당연함

  • 이런 사람들은 LLM에 디스크 전체 쓰기 권한을 주고 파괴적인 작업을 했다고 불평할 것임
    AI 에이전트가 비공개 저장소를 읽지 않게 하려면 비공개 저장소 접근권을 주지 않으면 됨. 이건 권한 우회 문제가 아니라 프롬프트 인젝션 문제이고, 에이전트 계층에서 신뢰성 있게 해결할 수 없음

  • 이미 해결된 문제이거나, 아직 GitHub가 해결하지 못했고 그 사이 악의적 행위자가 저장소들에 취약점을 시도할 것임
    저장소 수가 많으니 0이 아닌 확률로 유출이 생길 수 있음. 다만 사기 피해처럼 거의 아무도 유출을 인정하지 않을 것임

답변달기