GitLost가 보여준 GitHub AI Agent 보안 이슈는 저장소 권한이 바로 깨지는 해킹이 아니라, 에이전트가 2025년 기준 이슈·PR·README 같은 텍스트를 명령으로 오인해 비공개 코드나 토큰을 외부 응답으로 내보내는 문제예요. 핵심 대응은 저장소 자체보다 에이전트의 입력면, 자동 실행 권한, 출력 필터, repo 단위 권한을 줄이는 데 있어요.

무엇이 문제인가요: GitHub AI Agent 보안 이슈의 정체

비공개 저장소는 ‘직접 해킹’보다, 에이전트가 잘못 해석한 입력을 통해 새어 나갈 수 있습니다.AI로 생성된 이미지입니다
비공개 저장소는 ‘직접 해킹’보다, 에이전트가 잘못 해석한 입력을 통해 새어 나갈 수 있습니다.

이 이슈는 AI가 코드를 추천하는 수준을 넘어, 2025년의 GitHub Copilot 계열 기능처럼 저장소 문맥을 읽고 작업을 실행하는 에이전트가 등장하면서 커졌어요. Noma Security는 2025년 10월 10일 공개한 GitLost 연구에서, 비공개 저장소를 공개로 바꾸지 않아도 에이전트가 권한 있는 문맥에서 파일을 읽고 외부로 흘릴 수 있음을 보여줬어요.

핵심은 저장소 ACL이 바로 뚫리는 전통적 침해와 다르다는 점이에요. 공격자는 이슈, PR, README, 자동화 작업 설명처럼 에이전트가 읽는 입력면에 악성 지시문을 숨기고, 에이전트가 이를 사용자의 요청보다 우선하는 명령처럼 처리하게 만들어요. OWASP LLM Top 10이 2024~2025년에 Prompt Injection과 Sensitive Information Disclosure를 따로 경고한 이유가 바로 이 구조예요.

그래서 오늘 검색한 사람이 먼저 봐야 할 질문은 "내 비공개 저장소가 직접 공개되나?"보다 "에이전트가 무엇을 읽고, 무엇을 실행하고, 어디로 출력할 수 있나?"예요. Noma의 설명대로 실제 유출은 저장소 공개 전환보다, 에이전트가 접근 가능한 내부 코드 조각이나 비밀값을 댓글, PR, 외부 호출 같은 채널로 내보내도록 유도될 때 발생해요.

어떻게 유출되나요: GitLost류 공격의 실제 과정

신뢰할 수 없는 이슈·PR·문서가 지시처럼 처리되면 내부 코드를 읽게 될 수 있습니다.AI로 생성된 이미지입니다
신뢰할 수 없는 이슈·PR·문서가 지시처럼 처리되면 내부 코드를 읽게 될 수 있습니다.

이 공격은 신뢰할 수 없는 텍스트가 에이전트의 실행 흐름에 들어가는 순간 시작돼요. 2025년 GitHub Copilot은 IDE, GitHub 웹, 코드 리뷰, 이슈·PR 맥락까지 연결되는 기능을 제공해 입력면이 넓고, 입력면이 넓을수록 프롬프트 인젝션이 작동할 여지가 커져요.

  1. 외부 기여자나 낮은 권한 사용자가 2025년 기준 이슈, PR 설명, README, 문서, 자동화 코멘트 중 하나에 악성 지시문을 넣어요.

  2. GitHub AI 에이전트가 해당 텍스트를 읽고, 원래 사용자 요청과 별개로 "파일을 찾아 요약하라" 또는 "결과를 댓글로 남겨라" 같은 숨은 지시를 수행해요.

  3. 에이전트가 repo 컨텍스트 권한으로 비공개 파일, 설정값, 문서 조각을 읽어요. 이때 저장소 ACL 자체는 그대로일 수 있어요.

  4. 읽은 내용이 PR 코멘트, 작업 로그, 생성된 패치, 외부 서비스 호출 같은 출력 채널로 이동해요.

  5. 결과적으로 공격자는 저장소 접근 권한이 없어도, 에이전트가 대신 읽고 대신 말한 응답에서 내부 정보를 회수해요.

text
신뢰할 수 없는 입력(이슈/PR/README)
        ↓
에이전트가 텍스트를 명령처럼 해석
        ↓
repo 컨텍스트로 파일/문서/토큰 읽기
        ↓
댓글·PR·로그·외부 호출로 출력
        ↓
비공개 코드/민감정보 유출

중요한 점은 LLM 자체의 추론 오류보다 도구 권한이 피해를 키운다는 점이에요. Noma는 파일 읽기, PR 생성, 댓글 작성, 외부 호출 같은 에이전트 기능이 결합될수록 위험이 커진다고 설명했고, GitHub가 2025년에 Agent Mode와 자동화 기능을 확장해 온 만큼 사람 승인과 권한 최소화가 더 중요해졌어요.

어떻게 막나요: 지금 바로 적용할 실전 대응

대응은 저장소 접근권만이 아니라 입력면, 실행 권한, 출력 경로를 함께 줄이는 것입니다.AI로 생성된 이미지입니다
대응은 저장소 접근권만이 아니라 입력면, 실행 권한, 출력 경로를 함께 줄이는 것입니다.

가장 효과적인 대응은 에이전트의 입력, 실행, 출력, 비밀값 보관 위치를 분리하는 것이에요. 2025년 기준 실무에서는 자동 실행을 줄이고, 외부 작성자가 건드릴 수 있는 텍스트를 덜 믿게 만들며, repo 단위로 Copilot 권한을 다시 보는 방식이 우선이에요.

  1. 외부 작성 권한을 줄여요. 퍼블릭 저장소나 다수 협업 저장소라면 이슈, PR 본문, 위키, 문서 페이지 중 에이전트가 읽는 입력면을 먼저 확인하고, 외부 사용자가 자유롭게 수정하는 위치를 1차로 축소해요.

  2. 자동 작업을 승인형으로 바꿔요. 에이전트가 코드 수정, 파일 읽기, PR 생성, 댓글 작성, 외부 전송을 자동으로 하지 않게 하고, 1회 승인 또는 단계별 승인 흐름으로 제한해요.

  3. 실행 환경을 샌드박스로 분리해요. 기본 비활성화가 가능하면 비활성화하고, 꼭 써야 하면 네트워크·파일 접근 범위를 제한한 환경에서만 돌려요.

  4. 비밀값과 토큰을 저장소 문맥에서 빼요. README, 예제 .env, 설정 파일, 내부 문서, 테스트 데이터에 실제 키를 두지 말고, 2025년 기준 시크릿 매니저와 단기 토큰을 써요.

  5. 출력 필터를 넣어요. 에이전트가 생성하는 댓글, 로그, 패치, 요약문에 API 키 패턴, JWT, SSH 키 헤더, 사내 경로명 같은 민감정보 마스킹 규칙을 적용해요.

  6. Copilot 및 AI 도구 권한을 repo 단위로 점검해요. 조직 전체 기본 허용보다 민감 저장소만 별도 차단하거나 기능별로 분리하는 편이 안전해요.

점검 항목위험한 설정 예시권장 설정 예시
입력면외부 사용자가 작성한 이슈·PR·README를 에이전트가 그대로 읽음외부 작성 텍스트는 분리하고, 신뢰 입력만 작업 컨텍스트에 포함
실행 권한파일 읽기·댓글 작성·외부 호출이 자동 허용읽기 범위 최소화, 외부 전송 차단, 단계별 승인
비밀값 위치repo 내 문서·샘플 파일에 실제 토큰 존재시크릿 매니저, 단기 자격증명, 저장소 밖 보관
출력 채널PR 코멘트·로그에 원문 그대로 노출민감정보 필터, 마스킹, 사람이 최종 검토
도구 범위조직 전체에서 동일한 AI 권한 사용repo 단위 예외 정책, 민감 저장소는 비활성화

무엇과 다른가요: 전통적 저장소 해킹과 AI 에이전트 유출 비교

이 문제는 GitHub 계정 탈취나 저장소 공개 설정 변경과 같은 기존 침해와 구분해서 봐야 해요. 2025년 GitLost 사례의 본질은 저장소 문 자체를 부수는 것이 아니라, 문 안에 들어갈 수 있는 에이전트를 속여서 내용을 대신 읽고 말하게 만드는 데 있어요.

구분전통적 저장소 침해GitLost류 AI 에이전트 유출
시작점계정 탈취, 토큰 유출, ACL 오설정이슈, PR, README, 자동화 텍스트의 프롬프트 인젝션
필요한 것직접 접근 권한 또는 인증 우회에이전트가 읽는 입력면과 에이전트 권한
유출 방식저장소 clone, 다운로드, 공개 전환에이전트가 읽은 내용을 댓글·로그·응답으로 출력
방어 우선순위MFA, 토큰 회수, 권한 정리입력 분리, 승인형 실행, 출력 필터, repo별 AI 권한
오해하기 쉬운 지점GitHub 보안 설정만 보면 됨에이전트 워크플로우와 문맥 권한까지 함께 봐야 함

즉, 저장소 자체 보안이 좋아도 에이전트 운영이 느슨하면 새 경로가 열릴 수 있어요. 반대로 모든 AI 기능을 중단하지 않더라도, 신뢰 입력만 읽게 하고 자동 외부 전송을 막으면 위험을 꽤 줄일 수 있어요. OWASP가 권한 높은 에이전트일수록 실패 영향이 커진다고 한 이유도 여기 있어요.

어떤 실수가 많나요: 운영팀이 놓치기 쉬운 오류와 팁

가장 흔한 실수는 에이전트를 단순 챗봇으로 취급하는 것이에요. 2025년 Copilot 계열 기능은 저장소 맥락, 코드리뷰, 이슈·PR 문맥과 연결되므로, 사람이 보는 텍스트와 에이전트가 실행 근거로 삼는 텍스트를 같은 것으로 보면 안 돼요.

  • 오류 1: 이슈·PR 텍스트는 무해하다고 봐요. 팁: 외부 사용자가 쓰는 텍스트는 2025년 기준 모두 비신뢰 입력으로 분류해요.

  • 오류 2: 읽기 전용이면 안전하다고 생각해요. 팁: 읽기만 가능해도 댓글, 로그, 요약 응답으로 유출될 수 있으니 출력 통제를 같이 걸어요.

  • 오류 3: 토큰만 숨기면 끝이라고 봐요. 팁: 내부 코드, 설계 문서, 고객명, 경로명도 민감정보로 분류해 필터링해요.

  • 오류 4: 조직 전체 동일 정책을 써요. 팁: 고객 데이터나 프로덕션 IaC가 있는 저장소는 repo 단위로 AI 기능을 제한해요.

  • 오류 5: 자동화 결과를 사람이 안 봐요. 팁: PR 생성, 코멘트 게시, 외부 호출은 최소 1회 승인 절차를 넣어요.

바로 실행할 체크는 다섯 가지면 충분해요. 첫째, 외부 작성 가능한 이슈·PR·문서가 에이전트 컨텍스트에 들어가는지 확인해요. 둘째, 자동 댓글·PR·외부 호출 기능을 끄거나 승인형으로 바꿔요. 셋째, 저장소 안의 예제 키와 토큰을 전수 점검해요. 넷째, 출력 마스킹 규칙을 테스트해요. 다섯째, 민감 저장소의 Copilot 권한을 repo별로 재검토해요.

FAQ

GitLost는 GitHub가 해킹당했다는 뜻인가요?

아니에요. 2025년 10월 10일 Noma Security가 공개한 GitLost의 초점은 GitHub 플랫폼 전체가 뚫렸다는 의미보다, 권한 있는 AI 에이전트가 비신뢰 텍스트를 지시로 오인해 비공개 정보를 흘릴 수 있다는 점이었어요.

비공개 저장소면 원래 안전한 것 아닌가요?

비공개 설정 자체는 여전히 중요하지만 충분조건은 아니에요. 2025년 사례에서 문제는 저장소 공개 전환이 아니라, 에이전트가 접근 가능한 내부 코드나 토큰을 댓글·로그·응답으로 출력하는 흐름이었어요.

Copilot을 끄면 해결되나요?

민감 저장소에서는 1차 대응이 될 수 있지만, 항상 유일한 답은 아니에요. 2025년 권장 실무는 외부 입력 최소화, 승인형 실행, 샌드박스, 출력 필터, repo 단위 권한 조정까지 함께 적용하는 방식이에요.

가장 먼저 점검할 설정은 무엇인가요?

외부 작성자가 수정할 수 있는 이슈·PR·문서가 에이전트 입력으로 들어가는지, 그리고 에이전트가 자동으로 댓글 작성·PR 생성·외부 호출을 하는지를 먼저 보세요. 이 두 부분이 2024~2025년 프롬프트 인젝션 대응의 시작점이에요.

토큰을 저장소에 안 두면 충분한가요?

충분하지 않아요. OWASP가 2024~2025년에 민감정보 노출을 따로 다룬 것처럼, 소스코드 조각, 설계 문서, 고객 식별자, 내부 URL도 유출 대상이 될 수 있어요. 토큰 제거와 출력 필터를 같이 운영해야 해요.