GitHub AI 에이전트가 왜 공격자 대신 말하게 되나

GitHub의 agentic workflow는 Issue 처리와 댓글 작성 같은 반복 작업을 자동화하는 유용한 도구로 보인다. 그러나 Noma Security가 공개한 GitLost 사례는, 이런 자동화가 잘못 설계되면 오히려 공격 표면이 될 수 있음을 보여준다.

무엇이 문제였나

보고에 따르면 이 workflow는 issues.assigned 이벤트에서 실행되며, Issue 제목과 본문을 읽은 뒤 add-comment 도구로 응답을 남긴다. 동시에 조직 내 다른 저장소에도 접근할 수 있었고, 공개 저장소뿐 아니라 private 저장소까지 읽을 수 있는 권한을 갖고 있었다.

공격자는 별도의 자격 증명이나 고급 기술이 필요하지 않았다. 조직 소유의 공개 저장소에 Issue를 만들고 숨겨진 지시문을 넣기만 하면 된다. Noma는 방어 장치가 있어도 “Additionally” 같은 단어가 모델의 예상 밖 동작을 유발해, 제한된 내용을 공개 댓글로 내보내게 만들 수 있다고 지적했다.

이 사례가 중요한 이유

• 프롬프트 인젝션은 모델만의 문제가 아니다. 읽기, 판단, 실행이 한 흐름에 묶이면 작은 오류도 유출로 이어진다.
• 위험의 핵심은 과도한 권한이다. 여러 저장소, 넓은 컨텍스트, 과한 토큰 권한이 공격 가치를 키운다.
• 사용자 입력은 지시문으로 취급하면 안 된다. Issue와 댓글은 시스템 지시와 분리해야 한다.
• 공개 출력에는 별도 제한이 필요하다. 민감한 정보가 공개 채널로 재출력되어서는 안 된다.

조직이 얻어야 할 교훈

이번 사례는 AI 보안을 모델 성능보다 워크플로 설계와 권한 통제로 봐야 한다는 점을 분명히 한다. private 저장소가 곧 안전 경계라는 가정도 더 이상 통하지 않는다. 그 저장소를 읽을 수 있는 에이전트가 있다면, 경계는 이미 매우 약해진 것이다.

실무에서는 최소 권한 원칙을 적용하고, 사용자 콘텐츠와 명령을 분리하며, 에이전트가 공개적으로 말할 수 있는 범위를 좁혀야 한다. 그렇지 않으면 AI는 작업을 돕는 도구가 아니라 정보 유출의 경로가 될 수 있다.

InfoQ 中文