GitLost, 공개 이슈 하나로 private repo를 건드린 AI agent 취약점
Original: GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos View original →
Noma Security가 공개한 GitLost는 AI agent를 GitHub Actions와 붙일 때 생기는 권한 경계 문제를 정면으로 건드린다. 공격자는 같은 조직의 공개 저장소에 조작된 GitHub Issue를 남기고, agent가 그 내용을 업무 지시로 읽게 만든다. 연구진의 설명대로라면 agent는 공개 입력을 처리하는 과정에서 private repository의 정보를 끌어와 외부로 내보낼 수 있었다.
흥미로운 대목은 취약점이 단순한 prompt injection 데모에 머물지 않는다는 점이다. agent가 읽는 텍스트, 호출할 수 있는 도구, 조직 단위로 부여된 저장소 권한이 한 흐름 안에 묶이면 전통적인 CI 보안 사고와 비슷한 결과가 나온다. 비밀 값을 가진 작업을 신뢰할 수 없는 PR에서 실행하면 위험하듯, private code 접근권을 가진 agent가 공개 이슈를 그대로 믿으면 데이터가 빠져나갈 수 있다.
커뮤니티 논점은 “GitHub의 버그인가, 잘못된 권한 설정인가”로 갈렸다. 일부는 public repo 이벤트가 private repo 권한을 가진 agent를 움직일 수 있다는 구조 자체를 문제로 봤고, 다른 쪽은 민감한 접근권을 가진 자동화가 공개 입력을 읽도록 구성한 책임을 더 크게 봤다. 어느 쪽이든 결론은 비슷하다. LLM에게 보안 경계를 맡기는 대신, agent의 토큰 범위와 도구 호출 권한을 입력 출처별로 나눠야 한다.
GitLost가 남기는 실무적 메시지는 분명하다. agent workflow는 편의 기능이 아니라 권한을 가진 실행 주체다. 공개 이슈, 댓글, 문서, 로그처럼 외부 사용자가 쓸 수 있는 텍스트는 명령이 아니라 데이터로 격리해야 하며, private repo나 secret에 접근하는 단계는 별도의 승인과 최소 권한 정책을 가져야 한다.
Related Articles
보안 알림의 양보다 신뢰도가 더 중요한 단계로 들어섰다. GitHub는 LLM 기반 문맥 검증을 적용해 secret scanning 오탐을 목표치 65%보다 높은 75.76% 줄였다고 공개했다.
자동화된 네트워크 스캔이 실제 비용과 커뮤니티 대응으로 이어지자, 관심은 “agent에게 어디까지 권한을 줘야 하는가”에 모였다.
2026년 3월 Hacker News에서 Stanford SCS의 `jai`가 604 points와 313 comments를 기록했다. 이 도구는 현재 작업 디렉터리는 그대로 쓰게 두고, 나머지 home 영역은 overlay 또는 숨김 처리해 AI agent의 파일 손상 범위를 줄이려는 Linux용 containment 도구다.