Gheist 토큰 악용, AI 개발의 경계는 CI 권한까지

AI 코딩 에이전트의 권한을 설계할 때 파일 수정과 커밋만 생각하면 중요한 경계를 놓친다. 저장소 변경이 자동 실행으로 이어지는 환경에서는 코드를 쓸 수 있는 권한이 CI의 비밀정보와 배포 환경에 닿는 출발점이 될 수 있다.

Wiz가 확인한 Gheist의 범위

Wiz Research는 2026년 10월 25일 Gheist 조사 결과를 공개했다. 연구팀은 9월 15일부터 탈취된 GitHub 토큰을 대규모로 악용하는 활동을 추적했으며, 850개가 넘는 침해 계정에서 공격자가 심은 브랜치 13,500개 이상을 복구했다고 밝혔다.

이 숫자를 성공적으로 비밀정보가 유출된 저장소 수로 읽어서는 안 된다. 심어진 브랜치, 침해된 계정, 실제 실행된 워크플로, 후속 클라우드 접근은 서로 다른 관측 단위다. Wiz는 공개 저장소의 실행 보류 기능이 확인한 공개 공격 실행을 막았지만, 비공개 저장소와 GitHub Enterprise 환경에서는 실행과 후속 활동을 관찰했다고 설명했다.

공격이 AI로 작성됐다는 증거를 제시한 보고서는 아니다. AI 산업과의 연결점은 개발 자동화의 권한 구조와 자격증명이다. 자체 호스팅 러너를 겨냥한 변종은 AI 공급자 키를 포함한 여러 자격증명 형식을 찾았다고 연구팀은 밝혔다.

로그 마스킹과 권한 제한은 같은 통제가 아니다

보고서의 핵심은 비밀정보가 외부의 낯선 서버로만 나가는 것이 아니라 GitHub 실행 로그와 API 경로를 통해 이동했다는 점이다. 외부 도메인을 차단하는 방어만으로는 이 경로를 충분히 설명할 수 없다. 원문은 변형된 비밀 값이 로그의 단순한 원문 마스킹과 다르게 처리될 수 있다는 점도 지적한다.

또한 작업의 기본 토큰 권한을 낮춘다고 해서 작업에 주입되는 모든 비밀정보가 사라지는 것은 아니다. GitHub의 보안 배포 가이드는 자격증명, 신뢰되지 않은 입력, 실행 환경을 함께 검토하는 출발점이다.

이 표는 이번 사건의 공격 절차가 아니라 방어 통제의 분리다. 하나의 제한을 설정했다는 이유로 나머지도 보호됐다고 가정하는 것이 문제다.

코딩 에이전트 경쟁에서 실행 환경이 중요해진다

에이전트가 더 많은 작업을 자율적으로 처리할수록 코드 생성 품질 외의 기능이 중요해진다. 작업용 브랜치와 운영 배포 권한을 나누는지, 도구 호출의 대상이 드러나는지, 워크플로 변경을 일반 코드 변경보다 엄격하게 검토할 수 있는지가 선택 기준이 된다.

이번 보고서는 특정 AI 제품이 침해됐다고 말하지 않는다. 다만 이미 탈취된 계정이 자동화 기능을 사용했을 때 어떤 범위로 확장되는지 보여준다. AI 에이전트가 정상적인 요청을 수행하더라도 동일한 계정과 러너를 공유한다면 비슷한 권한 경계를 검토할 필요가 있다.

Argus의 실행 권한 설계에서 다룬 것처럼, 탐지나 판단 모델과 실제 권한을 행사하는 구성요소는 나눌 수 있다. 인도 에이전트 침입 사례 역시 모델 자체보다 자격증명과 실행 경계가 중요한 지점을 짚었다.

한국 개발 조직의 대응 우선순위

우선 공개 저장소에서 동작하는 보호 장치가 비공개 저장소와 사내 설치형 환경에서도 동일하게 적용된다고 가정하지 말아야 한다. 원문의 관측 시점은 10월 24일이며, 제품 기능과 조직 정책은 이후 달라질 수 있다. 현재 설정을 직접 확인하는 것이 우선이다.

운영 비밀정보는 배포 환경 보호 규칙을 통해 승인과 허용 경로를 제한할 수 있다. 장기 키 대신 OIDC 기반 인증을 고려하더라도, 신뢰 정책이 모든 브랜치를 받아들이면 기대한 경계가 사라질 수 있다. 짧은 수명 자체가 충분한 보호는 아니다.

침해가 의심되는 경우에는 브랜치 삭제만으로 마무리해서는 안 된다. 실행 여부, 노출 가능한 비밀정보, 후속 클라우드 활동을 조사하고 영향을 받은 키를 폐기·교체해야 한다. 자체 호스팅 러너에서 실행됐다면 저장소 수준을 넘어 호스트의 신뢰 상태까지 검토해야 한다는 것이 Wiz의 권고다.

Railway 사고와 배포 복구처럼 키 교체 이후 정상 서비스의 재연결도 작업의 일부다. 한국 조직은 개발팀, 보안팀, 운영팀이 서로 다른 자격증명을 관리하는 경우가 많으므로 담당자와 복구 확인 항목을 사전에 연결해두는 편이 유리하다.

자주 묻는 질문

이번 공격이 AI로 실행됐다는 뜻인가?

아니다. 보고서는 자동화된 토큰 악용을 설명한다. AI 생성 또는 특정 에이전트 사용을 확인한 것으로 해석해서는 안 된다.

공개 저장소 보호가 있으면 모두 안전한가?

Wiz가 확인한 공개 실행은 보류됐지만, 다른 환경과 향후 변종까지 보장하는 결론은 아니다. 비공개 및 사내 환경은 별도로 점검해야 한다.

작업 토큰 권한을 줄이면 비밀정보도 차단되나?

항상 그렇지는 않다. 작업 토큰의 API 권한과 작업에 주입되는 비밀정보는 구분되는 대상이다.

OIDC를 도입하면 끝인가?

아니다. 허용 저장소, 브랜치, 환경과 역할 권한을 제한해야 한다. 장기 키를 없애는 것과 신뢰 범위를 좁히는 것은 서로 다른 작업이다.

에이전트 운영팀은 무엇부터 바꿔야 하나?

저장소 변경, 워크플로 수정, 운영 배포의 권한을 구분하고 각 경로의 감사 기록을 확보해야 한다. 실제 침해 여부는 증거를 기반으로 판단해야 한다.