AI 보안 · 2026년 7월 9일 · 약 7분

GitHub Agentic Workflows GitLost 보안 점검법, AI 에이전트가 private repo를 읽기 전에 막을 것

Noma Labs가 GitHub Agentic Workflows에서 공개 이슈가 AI 에이전트를 흔들어 private repository 내용을 공개 댓글로 내보낼 수 있는 GitLost 사례를 공개했다. 기능을 쓰는 팀이 권한, 입력, 출력 경계를 어떻게 점검해야 하는지 정리했다.

• GitHub Agentic Workflows
• GitLost
• prompt injection
• AI 에이전트 보안
• private repo 보안

출처: Noma Labs

Noma Labs가 2026년 7월 6일 GitLost라는 GitHub Agentic Workflows 보안 사례를 공개했습니다. 공개 저장소의 이슈 본문에 숨긴 지시가 AI 에이전트에게 전달되고, 에이전트가 접근 가능한 private repository의 README 내용을 공개 댓글로 적는 흐름이 재현됐다는 내용입니다.

이 글을 “GitHub를 쓰면 private repo가 바로 새는 문제”로 읽으면 과합니다. 조건이 있습니다. 공개 이슈를 읽는 에이전트가 있고, 그 에이전트가 조직 안의 다른 private repo를 읽을 수 있으며, 결과를 공개 댓글 같은 외부 채널에 쓸 수 있어야 합니다. 하지만 이 조합은 AI 에이전트를 업무 자동화에 붙이는 팀이 실제로 만들기 쉬운 구조라서 점검할 가치가 큽니다.

핵심 키워드

• GitHub Agentic Workflows GitLost
• GitHub AI agent 보안
• private repo prompt injection
• AI 에이전트 권한 점검
• GitHub safe outputs

무엇이 문제였나

GitHub Agentic Workflows는 Markdown으로 자동화 지시를 쓰고, 이를 GitHub Actions workflow로 컴파일해 AI 에이전트가 이슈나 PR 같은 저장소 이벤트를 처리하게 만드는 방식입니다. Noma Labs가 설명한 취약한 구성은 공개 이슈가 할당될 때 실행되고, 이슈 제목과 본문을 읽고, 댓글을 작성하며, 조직의 다른 public/private repository도 읽을 수 있었습니다.

초보자 관점에서 이해하기

기존 웹 보안에서는 사용자 입력과 관리자 권한을 섞지 않는 것이 기본입니다. AI 에이전트에서도 같은 원칙이 필요합니다. 문제는 자연어 자동화가 “이 문장은 사용자가 남긴 데이터인가, 아니면 에이전트가 따라야 할 지시인가”를 항상 깔끔하게 나누기 어렵다는 데 있습니다.

그래서 방어를 모델의 거절 능력에만 맡기면 부족합니다. Noma Labs는 특정 표현 변화로 가드레일을 우회했다고 설명했습니다. 실무자는 어떤 문구가 우회에 쓰였는지 외우기보다, 에이전트가 읽을 수 있는 곳과 쓸 수 있는 곳을 먼저 줄여야 합니다.

바로 확인할 세 가지 조건

우리 팀 점검 질문

• 공개 이슈, PR 본문, 댓글처럼 외부 사람이 쓸 수 있는 텍스트를 AI 에이전트가 그대로 읽는가?
• 그 에이전트 토큰이 현재 저장소를 넘어 다른 private repo, secret, 내부 문서에 접근할 수 있는가?
• 에이전트가 사람 승인 없이 공개 댓글, PR, 이슈, 배포 로그처럼 외부에서 볼 수 있는 위치에 내용을 쓸 수 있는가?
• 세 질문에 모두 “예”라면 즉시 권한과 출력 경계를 줄인다.

GitHub 공식 문서에서 같이 봐야 할 설정

GitHub Agentic Workflows 문서는 cross-repository 작업에 별도 인증이 필요하고, 읽기 범위를 allowed-repos 같은 설정으로 제한할 수 있다고 안내합니다. 또한 safe outputs는 에이전트가 직접 GitHub에 쓰는 대신 정해진 출력 형식과 대상 저장소를 거치게 만드는 장치입니다. GitLost를 보고 가장 먼저 볼 부분은 모델 이름이 아니라 이 권한 설정입니다.

작게 써보는 안전한 시작 방식

처음부터 조직 전체 이슈를 triage하거나 여러 저장소의 코드를 읽게 하지 마세요. 작은 공개 저장소 하나에서 읽기 전용 요약부터 시작하는 편이 낫습니다. 에이전트가 작성한 내용은 바로 게시하지 말고 draft issue나 draft pull request로 남기고, 사람이 확인한 뒤 공개합니다.

초기 설정 예시

• 목표: 현재 저장소의 공개 이슈를 읽고 분류 후보만 제안한다.
• 읽기 범위: current repository만 허용한다. private repo와 조직 전체 검색은 끈다.
• 쓰기 범위: 공개 댓글 작성 대신 maintainer 전용 draft issue 또는 PR 초안만 만든다.
• 중단 기준: 이슈 본문이 다른 저장소, secret, 토큰, 내부 문서를 요청하면 결과를 만들지 않고 사람 검토로 넘긴다.
• 검토 기준: 에이전트 출력에 private 경로, secret처럼 보이는 문자열, 내부 파일 내용이 포함됐는지 확인한다.

복사해서 쓰는 보안 검토 프롬프트

아래 템플릿은 Agentic Workflows나 다른 GitHub 자동화 에이전트를 도입하기 전에 설정을 읽고 위험 경로를 찾는 용도입니다. 실제 secret 값을 붙여 넣지 말고, 권한 이름과 workflow 구조만 넣으세요.

에이전트 권한 점검 템플릿

• 검토 대상: [workflow 이름]이 읽는 이벤트, 입력, 토큰 권한, 출력 위치를 점검한다.
• 입력: 공개 이슈, PR 본문, 댓글, 파일 내용 중 외부 사용자가 바꿀 수 있는 항목을 표로 나눈다.
• 권한: 에이전트가 읽을 수 있는 repository, branch, secret, artifact, issue, PR 범위를 나열한다.
• 출력: 에이전트가 쓸 수 있는 댓글, issue, PR, branch, artifact 중 외부 공개 가능성이 있는 곳을 표시한다.
• 판단: untrusted input, private data access, public output이 동시에 만나는 경로를 가장 위험한 순서로 정리한다.
• 개선안: allowed-repos 축소, safe outputs 제한, human review 추가, 공개 댓글 비활성화 중 먼저 할 조치를 제안한다.

오늘 할 일

GitHub Agentic Workflows를 쓰고 있거나 검토 중이라면, 먼저 토큰과 출력 채널부터 보세요. “에이전트가 똑똑한가”보다 “에이전트가 무엇을 읽고 어디에 쓸 수 있는가”가 더 중요합니다. 공개 입력을 읽는 에이전트에는 조직 전체 private repo 읽기 권한을 주지 않는 것이 출발점입니다.