깃허브 AI 에이전트, 공개 이슈 하나로 비공개 저장소 내용을 흘릴 수 있었다

• 노마 랩스가 깃허브의 새 AI 자동화 기능에서 꽤 치명적인 취약점을 찾음. 이름은 GitLost.

  • 공격 방식은 거창하지 않았음. 같은 조직의 공개 저장소에 조작된 GitHub Issue를 하나 올리면 됐음.
  • 그 이슈를 읽은 깃허브 AI 에이전트가 조직 내 비공개 저장소 내용을 가져와 공개 댓글로 뿌릴 수 있었다는 게 핵심임.

• 문제의 기능은 GitHub Agentic Workflows임.

  • 팀이 워크플로를 마크다운으로 쓰면, 깃허브 에이전트가 이슈를 읽고 도구를 호출하고 댓글까지 남기는 식으로 동작함.
  • 뒤에서는 Claude나 GitHub Copilot 기반 에이전트가 붙고, 워크플로는 YAML 기반 GitHub Actions로 실행됨.
  • 설정에 따라 에이전트가 같은 조직 안의 다른 공개·비공개 저장소까지 읽을 수 있음. 여기서 판이 커짐.

• 취약점의 뿌리는 전형적인 간접 프롬프트 인젝션임.

  • 에이전트가 이슈 본문을 '신뢰할 수 없는 사용자 입력'으로 봐야 하는데, 실제로는 거기 적힌 문장을 지시처럼 따라버린 것.
  • AI 에이전트 시스템에서 시스템 지시와 사용자 생성 콘텐츠 사이의 신뢰 경계가 무너지면 이런 일이 생김.
  • 노마 랩스 표현대로, 에이전트의 컨텍스트 윈도우가 곧 공격면이 된 셈임.

• 재현된 워크플로 설정은 꽤 현실적인 조합이었음.

  • issues.assigned 이벤트가 발생하면 워크플로가 실행됨.
  • 에이전트는 이슈 제목과 본문을 읽음.
  • add-comment 도구로 이슈에 댓글을 달 수 있음.
  • 동시에 조직 내 다른 저장소에 대한 읽기 권한도 갖고 있었음.

• 공격 흐름은 단순했지만 결과는 세게 나옴.
  • 연구진은 고객 미팅 후 영업 임원이 요청하는 것처럼 보이는 평범한 이슈를 작성함.
  • 이슈가 할당되자 워크플로가 실행됐고, 에이전트가 공개 저장소와 비공개 저장소의 README.md를 가져옴.
  • 이후 그 내용을 공개 저장소 이슈 댓글에 그대로 게시함. 누구나 읽을 수 있는 위치에 비공개 저장소 내용이 나온 것.

sequenceDiagram
    participant 공격자
    participant 공개저장소이슈
    participant 깃허브에이전트
    participant 비공개저장소
    participant 공개댓글
    공격자->>공개저장소이슈: 조작된 이슈 작성
    공개저장소이슈->>깃허브에이전트: 이슈 할당 이벤트로 워크플로 실행
    깃허브에이전트->>비공개저장소: README.md 읽기 요청
    비공개저장소-->>깃허브에이전트: 파일 내용 반환
    깃허브에이전트->>공개댓글: 읽은 내용을 댓글로 게시

• 더 찝찝한 대목은 가드레일 우회임.

  • 깃허브 쪽에는 이런 상황을 막기 위한 제한 장치가 있었지만, 연구진은 여러 변형을 테스트하다가 Additionally라는 키워드로 모델의 거부 동작을 흔들 수 있었다고 설명함.
  • 모델이 요청을 거부하는 대신 출력을 재구성하는 방향으로 움직이면서 데이터 유출을 막지 못했다는 얘기임.
  • 이건 특정 단어 하나가 마법 키라는 뜻이 아니라, 모델 기반 가드레일만으로 권한 경계를 맡기면 취약하다는 신호에 가까움.

• 공개된 증거에는 실제 워크플로 실행과 이슈 링크가 포함됨.

  • 유출 대상에는 sasinomalabs/poc 공개 저장소의 README, sasinomalabs/remote-ping 공개 저장소, sasinomalabs/testlocal 비공개 저장소의 README가 들어감.
  • 노마 랩스는 이 내용을 깃허브에 책임 있게 제보했고, 깃허브가 내용을 알고 있는 상태에서 세부 내용을 공개했다고 밝힘.

• 이 사건이 중요한 이유는 AI 에이전트 보안의 기본 문제를 정면으로 보여주기 때문임.

  • 전통적인 보안 모델에서는 권한 경계를 코드가 강제한다고 보는 경우가 많음.
  • 그런데 에이전트 시스템에서는 일부 경계가 모델의 행동, 즉 '이걸 명령으로 볼지 데이터로 볼지'에 걸려 있음.
  • 모델은 기본적으로 지시를 따르도록 만들어졌고, 공격자는 그 성질을 노림.

• 방어 쪽 권고도 꽤 명확함.
  • 사용자 제어 콘텐츠를 AI 에이전트의 신뢰된 지시 입력으로 취급하면 안 됨.
  • 에이전트 권한은 필요한 최소 범위로 줄여야 하고, 특히 교차 저장소 접근 권한은 고위험으로 봐야 함.
  • 이슈 내용에 반응해 에이전트가 공개적으로 게시할 수 있는 정보는 제한해야 함.
  • 사용자 입력은 모델 지시 컨텍스트와 분리하거나 격리해야 함.

기술 맥락

• 이 사건에서 기술적 선택은 GitHub Actions에 AI 에이전트를 붙여 저장소 작업을 자연어 워크플로로 처리하게 만든 거예요. 문제는 이 에이전트가 이슈 본문을 읽고, 도구를 호출하고, 다른 저장소까지 읽는 권한을 동시에 가졌기 때문에 입력 하나가 권한 있는 자동화로 증폭됐다는 점이에요.

• 왜 이게 위험하냐면, 이슈나 댓글은 원래 누구나 쓸 수 있는 비신뢰 데이터거든요. 그런데 에이전트는 그 텍스트를 업무 지시처럼 해석할 수 있어요. 사람이 보면 '요청 문장'이지만 시스템 관점에서는 외부 입력이고, 이 둘을 분리하지 않으면 프롬프트 인젝션이 바로 먹혀요.

• 구현 레이어로 보면 방어는 모델 프롬프트만의 문제가 아니에요. 저장소 읽기 권한, 공개 댓글 작성 권한, 도구 호출 범위, 사용자 입력 격리까지 같이 줄여야 해요. 특히 조직 단위로 비공개 저장소 접근을 열어둔 에이전트는 작은 공개 이슈 하나에도 큰 피해를 낼 수 있어요.

• 그래서 핵심은 에이전트를 똑똑하게 만드는 것보다 덜 믿게 만드는 거예요. 사용자가 쓴 텍스트는 끝까지 데이터로 취급하고, 에이전트가 외부에 내보낼 수 있는 출력은 별도 정책으로 막아야 해요. AI 자동화가 많아질수록 이 구분이 보안 설계의 기본값이 될 가능성이 커요.