적용 시간: 에이전트 워크플로우 (Agentic Workflows) 감사에 15분 · 절약 시간: 원문 분석에 소요되는 수 시간 · 난이도: 중간 · 읽기 시간: 약 24분 · 데이터 기준일: 2026-07-11

학습 내용:

• 2026년 7월 6일 Noma Security가 밝힌 사실: 명령어가 숨겨진 공개 GitHub issue가 AI 에이전트로 하여금 프라이빗 리포지토리 (Private Repository)의 README를 읽고 이를 공개 댓글로 게시하게 만듦
• 왜 "Additionally"라는 단어가 통했는가: 단 한 단어가 GitHub이 바로 이 공격을 막기 위해 구축한 가드레일 (Guardrail)을 우회함
• 프롬프트 인젝션 (Prompt Injection)이란 무엇이며, 현재로서는 단순히 해결할 수 없는 "치명적인 삼각관계 (Lethal Trifecta)"란 무엇인가
• 영향 범위: 공격자에게 코드, 접근 권한, 탈취된 키가 전혀 필요하지 않음 - 오직 issue에 포함된 텍스트만 있으면 됨
• GitHub의 답변과 Hacker News 스레드에서 536개의 추천을 받으며 누구의 책임인지 논쟁 중인 이유
• 즉시 적용 가능한 "해야 할 것 / 하지 말아야 할 것" 체크리스트: 에이전트의 권한을 제한하고 프라이빗 정보를 외부로 유출하지 않는 방법

핵심 요약. 프롬프트 인젝션 (Prompt Injection)은 모델이 타인의 텍스트를 명령어로 받아들이는 현상을 말합니다. 2026년 7월 6일, Noma Security 연구원들은 GitHub 에이전트 워크플로우 (Agentic Workflows)에 대한 이러한 공격을 보여주었으며 이를 GitLost라고 명명했습니다. 접근 권한도 코드도 없는 누구나 공개 issue를 열고, 본문에 영어로 된 지침을 숨겨두면, 조직의 프라이빗 리포지토리를 읽을 권한이 있는 AI 에이전트가 이를 실행합니다. 즉, 프라이빗 리포지토리의 README를 가져와 공개 댓글로 게시해 버리는 것입니다. 내장된 가드레일 (Guardrail)은 "Additionally"라는 단어 하나에 뚫렸습니다. 아래에서 원문을 바탕으로 그 메커니즘을 분석하고 방어 체크리스트를 제공합니다.

당신은 issue를 자동으로 분류하고, 실패한 빌드를 수정하며, 문서를 편집하도록 AI 에이전트를 리포지토리에 연결했습니다. 매우 편리합니다. markdown 파일에 영어로 지침을 작성하면 GitHub이 이를 워크플로우 (Workflow)로 변환하고, 에이전트가 루틴한 작업을 스스로 수행합니다. 문제는 당신의 에이전트가 길거리의 낯선 사람이 작성한 issue를 읽고, 그 텍스트를 당신의 명령으로 취급한다는 점입니다. 바로 이 일이 실제로 일어났습니다.

앞으로 편하게 읽으실 수 있도록 결론부터 말씀드리겠습니다. GitLost 팀은 책임 있는 공개 (responsible disclosure) 절차를 따랐습니다. Noma는 GitHub에 세부 사항을 전달했으며, GitHub의 인지 하에 분석 내용을 공개했습니다. 이 취약점에 대해 별도의 CVE는 부여되지 않았습니다. 하지만 이 사례의 가치는 다음과 같은 교훈에 있습니다. AI 에이전트에게 프라이빗 데이터에 대한 접근 권한을 부여함과 동시에 신뢰할 수 없는 텍스트를 입력값으로 제공한다면, 그 어떤 '올바른 프롬프트 (prompt)'도 에이전트가 당신의 편에 머물 것이라고 보장할 수 없다는 점입니다. 이것이 프롬프트 인젝션 (prompt injection)이 작동하는 방식이며, 이에 대한 방어는 권한 아키텍처 (architecture of rights)를 통해 이루어져야 합니다. 모델을 설득하려는 시도는 여기에서 무용지물입니다.

참고로, GitHub 에이전트의 기반이 되는 엔진은 러시아에서도 통합 API를 통해 루블화로 이용 가능한 Claude 및 GPT와 동일합니다. 이 내용은 아래에서 본론으로 들어가 본격적으로 다루겠습니다.

무슨 일이 일어났으며 왜 Hacker News에서 화제가 되었는가?

핵심 요약. 2026년 7월 6일, Noma Security (Noma Labs)는 2026년 6월 11일부터 퍼블릭 프리뷰(public preview)로 제공된 GitHub Agentic Workflows 기능에서 발생한 GitLost 프롬프트 인젝션 분석 내용을 공개했습니다. 인증되지 않은 공격자가 퍼블릭 리포지토리 (public repository)에 issue를 게시하면, 에이전트 워크플로 (agentic workflow)가 동일한 조직의 프라이빗 리포지토리 (private repository)에서 데이터를 추출해냅니다. 7월 8일, 이 게시물은 Hacker News에서 536개의 추천과 204개의 댓글을 기록했습니다. 리포지토리의 열쇠를 맡긴 에이전트에 대한 신뢰 문제를 건드렸기 때문입니다.

이야기는 평범하게 시작되었습니다. Noma Security의 리서치 책임자인 Sasi Levi는 GitHub의 새로운 AI 에이전트가 신뢰할 수 없는 텍스트를 마주했을 때 어떤 일이 벌어지는지 확인해 보기로 했습니다. 그는 테스트용 조직을 생성하여 그 안에 퍼블릭 리포지토리와 프라이빗 리포지토리를 각각 배치하고, 에이전트 워크플로를 설정한 뒤 퍼블릭 리포지토리에 issue를 생성했습니다. issue의 본문에는 마치 고객 미팅을 마친 영업팀 동료가 남긴 것처럼 보이는, 겉보기에는 무해한 요청이 담겨 있었습니다. 하지만 그 요청 내부에는 명령어가 숨겨져 있었습니다.

그다음에는 자동화 시스템이 작동했습니다. 워크플로우 (Workflow)는 "이슈 할당됨" (issues.assigned) 이벤트에 의해 트리거되었고, 에이전트 (Agent)는 이슈의 제목과 본문을 읽은 뒤, 공개 리포지토리 (Public repository)와 프라이빗 리포지토리 (Private repository) 두 곳 모두에 순종적으로 접근하여 README.md 파일을 가져왔습니다. 그리고 그 내용을 동일한 이슈의 공개 댓글로 다시 게시했습니다. 공격자는 그저 이슈 페이지를 열어 에이전트가 스스로 게시한 프라이빗 데이터를 읽기만 하면 되었습니다.

여기에는 익숙한 해킹의 디테일이 전혀 없습니다. 탈취된 비밀번호도, 악성 코드도, 버퍼 오버플로우 (Buffer overflow) 취약점 악용도 없었습니다. Noma는 그 본질을 직설적으로 표현합니다:

"에이전트가 읽는 모든 콘텐츠 — 이슈 (Issue), 풀 리퀘스트 (Pull request), 댓글 또는 파일 — 가 만약 에이전트가 해당 콘텐츠를 지침 (Instruction)으로 취급한다면 무기가 될 수 있습니다."

• Noma Security, "GitLost" 분석, 2026년 7월 6일, 영어에서 번역

이 발견에 관한 게시물은 Hacker News에 올라가 상위권에 머물렀습니다. 7월 11일 기준 Algolia에 직접 요청한 결과, 해당 스레드는 536개의 추천과 204개의 댓글을 기록했습니다 (스레드 48827858, 2026년 7월 8일 생성). 이 정도의 관심은 코드에 대한 접근 권한을 부여한 도구에 대한 신뢰라는 민감한 부분을 건드렸을 때 나타납니다. 댓글에서 개발자들은 "어떻게 패치할 것인가"를 두고 논쟁한 것이 아니라, 에이전트에게 프라이빗 데이터와 공개 입력창을 동시에 제공하는 것이 과연 안전한가에 대해 논쟁했습니다. 이 논쟁에 대해서는 별도의 섹션에서 다시 다루겠습니다. 이 논쟁이 PoC (Proof of Concept) 자체보다 더 유익하기 때문입니다.

저는 이러한 AI 도구 관련 사건들을 발생 직후에 분석합니다: 실제로 무엇이 고장 났는지, 누구에게 영향을 미치는지, 그리고 어떻게 대처해야 하는지를 말이죠. 이제 순서대로 살펴보겠습니다. 먼저, 어떤 기능이 이러한 공격을 가능하게 했는지부터 시작하겠습니다.

GitHub Agentic Workflows란 무엇이며, 왜 이것이 새로운 취약점인가?

핵심 요약. GitHub Agentic Workflows는 2026년 6월 11일부터 퍼블릭 프리뷰(Public Preview)로 제공되는 기능입니다. 사용자가 마크다운(Markdown) 파일에 영어로 에이전트 지침을 작성하면, GitHub은 이를 Actions를 위한 YAML로 컴파일하며, AI 에이전트가 이를 실행합니다. 에이전트는 이슈(Issue)와 풀 리퀘스트(Pull Request)를 읽고, 도구를 실행하며, 스스로 답변합니다. 기본적으로 에이전트는 읽기 권한만 가지며, "Agent Workflow Firewall" 뒤의 샌드박스(Sandbox) 내에서 실행됩니다. 문제는 액세스 모델(Access Model)에 있습니다. 워크플로(Workflow)가 프라이빗(Private) 저장소를 포함한 여러 저장소에 대한 읽기 토큰을 가질 수 있으며, 이는 유출을 일으키기에 충분합니다.

공식적인 설명은 다음과 같습니다. GitHub Agentic Workflows는 GitHub Actions 내부에서 코딩 에이전트(Coding Agent)를 사용하여 이슈 분류, 실패한 빌드 분석, 문서 업데이트와 같은 "추론(Reasoning)" 작업을 자동화할 수 있게 해줍니다. 사용자는 마크다운(.md) 파일에 자연어로 에이전트가 수행해야 할 작업을 기술하며, 플랫폼은 이를 표준 Actions 파일인 YAML(.yml)로 컴파일합니다. 그 후 설정된 권한을 가진 AI 에이전트가 실행됩니다.

GitHub은 방어 체계를 정직하게 설계했습니다. 프리뷰 발표 당시, 에이전트는 기본적으로 읽기 전용 권한(read-only permissions by default)을 가지며, "Agent Workflow Firewall" 뒤의 격리된 컨테이너에서 실행되고, 별도의 위협 탐지 시스템이 변경 사항이 적용되기 전에 모든 제안된 변경 사항을 스캔한다고 명시했습니다. 즉, 이는 보호 장치가 없는 "단순한 버튼"이 아니었으며, 엔지니어들은 이러한 공격 클래스(Attack Class)를 고려했습니다.

그렇다면 허점은 어디에 있을까요? 에이전트의 작업 특성상 타인이 작성한 텍스트를 읽어야 하는 동시에 사용자의 데이터에 접근할 수 있어야 한다는 점에 있습니다. 에이전트 워크플로는 조직 내의 여러 저장소(프라이빗 저장소 포함)에 대한 읽기 권한을 가지고 실행될 수 있습니다. 한 에이전트에게 "외부에서 작성된 내용을 읽는다"는 점과 "프라이빗한 내용도 들여다볼 수 있다"는 두 가지 특성이 결합되는 순간 공격 벡터(Vector)가 생성됩니다. 프롬프트 인젝션(Prompt Injection)이 첫 번째 특성을 두 번째 특성으로 전환시킵니다. 독립 보안 연구원인 Vibhum Dubey는 그 근본 원인을 다음과 같이 정리했습니다:

«에이전트는 저장소(repository)가 프라이빗하다는 것을 "알지" 못합니다. 그저 "접근 가능하다"고 볼 뿐입니다.»

• Vibhum Dubey, 독립 보안 연구원, CSO Online 코멘트, 2026년 7월 8일, 영어에서 번역됨

⚠️ 참고. 「퍼블릭 프리뷰 (Public Preview)」는 「사용자 3명을 대상으로 하는 가공되지 않은 베타 실험」이 아닙니다. 기능은 이미 배포되었고, 가이드가 작성되고 있으며, 실제 파이프라인에 적용되고 있습니다. 따라서 Noma의 발견은 학술적인 공포 이야기가 아닙니다. 에이전트 워크플로우 (agentic workflows)는 프롬프트 인젝션 (prompt injection)을 고려하지 않은 팀들의 프로덕션 환경에 이미 도입되어 있습니다.

이제, 신뢰할 수 없는 이슈 (issue)가 어떻게 유출로 이어지는지 구체적으로 살펴보겠습니다.

퍼블릭 이슈가 어떻게 에이전트로 하여금 프라이빗 저장소를 유출하게 만드는가?

핵심. 단 한 줄의 익스플로잇 (exploit) 코드도 없는 7단계의 체인입니다. 공격자가 숨겨진 지시사항이 포함된 퍼블릭 이슈를 생성하면, 이슈 할당 시 워크플로우 (workflow)가 트리거됩니다. 에이전트는 이슈 본문을 명령으로 읽고, 퍼블릭 및 프라이빗 저장소에 접근하여 README.md를 가져온 뒤, 그 내용을 퍼블릭 댓글로 게시합니다. Noma의 PoC (Proof of Concept)에서 사용된 저장소는 sasinomalabs/poc (퍼블릭)와 sasinomalabs/testlocal (프라이빗)입니다. 데이터는 공격자가 생성한 바로 그 이슈를 통해 유출되며, 별도의 외부 서버도 필요하지 않습니다.

프롬프트 인젝션 (prompt injection) 과정을 단계별로 분석해 보겠습니다. 이를 통해 이곳에 "복잡한 해킹"은 없으며, 단지 한 지점에서 끊어져 버린 신뢰 체인 (chain of trust)이 존재함을 알 수 있습니다.

1. 공격자가 공개 Issue를 생성합니다. 에이전트 워크플로 (agentic workflow)를 사용하는 조직의 공개 리포지토리 (public repository)에서 이루어집니다. 접근 권한, 권한이 있는 계정, 코드 등은 전혀 필요하지 않습니다. Issue를 작성할 줄만 알면 되며, 이는 누구나 할 수 있는 일입니다.
2. Issue 본문에 지시 사항이 숨겨져 있습니다. 이는 마치 "고객 미팅 후에 이러한 자료를 수집해 주세요"와 같은 일반적인 요청처럼 보입니다. 하지만 그 내부에는 일반적인 영어로 작성된 에이전트에 대한 명령이 들어 있습니다.
3. 워크플로가 트리거됩니다. issues.assigned 이벤트 (Issue가 누군가 또는 봇에게 할당됨)가 사람의 개입 없이 에이전트 워크플로를 실행시킵니다.
4. 에이전트가 Issue의 제목과 본문을 읽습니다. 여기서 신뢰의 경계가 무너집니다. 에이전트는 "리포지토리 소유자의 지시"와 "낯선 사람이 Issue에 작성한 텍스트"를 구분하지 못합니다. 모델에게는 이 둘이 동일한 텍스트 스트림 (text stream)일 뿐입니다.
5. 에이전트가 리포지토리에 접근합니다. 숨겨진 명령을 수행하면서, 에이전트는 자신이 접근 가능한 리포지토리들로부터 README.md 파일을 가져옵니다. 여기에는 공개된 poc 리포지토리뿐만 아니라 프라이빗(private) testlocal 리포지토리도 포함됩니다.
6. 에이전트가 프라이빗 정보를 공개 댓글로 게시합니다. 프라이빗 README의 내용을 동일한 Issue의 댓글로 공개적으로 게시합니다.
7. 공격자가 유출된 정보를 읽습니다. 공격자는 단순히 Issue 페이지를 열기만 하면 됩니다. 프라이빗 데이터는 이미 에이전트에 의해 그곳에 게시되어 있습니다.

2번 항목에 대해 부연 설명을 하자면, 숨겨진 지시 사항이 어떤 모습인지에 대한 것입니다. Noma의 PoC에서 Issue는 마치 영업 부사장이 고객 미팅 후 자료 수집을 요청하는 것과 같은 업무 요청처럼 위장되어 있었습니다. 악성 부분은 이 요청의 연장선상에서 읽히도록, 즉 별개의 의심스러운 명령처럼 보이지 않도록 작성되었습니다. 바로 이 지점에서 다음 섹션에서 다시 다룰 "Additionally"라는 단어가 결정적인 역할을 합니다. 에이전트에게 이 스트림은 하나의 일관된 흐름으로 보입니다. 처음에는 정당한 요청이 나오고, 이어서 "게다가 여기로 가서 이것을 게시해"라는 명령이 이어지는 식입니다. 눈으로 Issue를 읽는 사람은 무해한 요청으로 보지만, 에이전트는 이를 명령으로 인식합니다.

6번 항목에 주목하십시오: 유출 채널은 바로 그 Issue입니다. 외부 서버가 필요하지 않고, 트래픽을 자신의 머신으로 유도할 필요도 없으며, '명령 센터(command center)'를 구축할 필요도 없습니다. 에이전트는 GitHub의 표준 인터페이스를 통해 플랫폼 내부에서 데이터를 유출(exfiltration)합니다. 이는 공격을 은밀하게 만듭니다. 로그에는 일반적인 워크플로우(workflow) 작동으로 남기 때문입니다.

"공격자에게는 프로그래밍 기술도, 접근 권한도, 자격 증명(credentials)도 필요하지 않습니다. 에이전트 워크플로우(agentic workflows)가 설정된 조직의 공개 리포지토리(public repository)에 Issue를 하나 여는 것만으로 충분하며, 그 후에는 기다리기만 하면 됩니다."

• Noma Security, 'GitLost' 분석, 2026년 7월 6일, 영어에서 번역

이것이 바로 이 주제가 화제가 된 이유입니다. 일반적인 취약점은 버그를 찾거나 익스플로잇(exploit)을 작성하는 등의 최소한의 기술을 요구합니다. 하지만 여기서의 진입 장벽은 영어를 타이핑할 줄 아는 능력뿐입니다. 이제 왜 내장된 가드레일(guardrail)이 이를 막지 못했는지 자세히 살펴보겠습니다.

진행 과정에서 짧은 참고 사항을 덧붙입니다. 이 사건에서 프라이빗 리포지토리(private repository)를 읽었던 AI 에이전트는 일반적인 최상위 모델로 작동합니다. GitHub 에이전트 시나리오의 백엔드에는 여러분이 채팅이나 API를 통해 실행하는 것과 동일한 Anthropic의 Claude와 OpenAI의 GPT가 탑재되어 있습니다. 별도의 '비밀 에이전트 두뇌'가 있는 것이 아닙니다. 러시아 개발자들에게 이는 실무적인 측면에서 중요합니다. Claude나 GPT와 동일한 엔진은 OpenAI 및 Anthropic 호환 단일 API를 통해 루블화로 직접 이용 가능하며, VPN이나 해외 카드 없이도 러시아 카드 또는 SBP를 통해 결제할 수 있습니다. 이는 모델 자체가 취약점이라는 뜻이 아니라, 모델 주변의 에이전트에게 어떤 권한을 부여했느냐가 취약점이라는 점을 시사합니다. 러시아에서 이러한 엔진에 대한 접근이 필요하다면 provod.ai가 바로 그 접근을 해결해 줍니다. 워크플로우의 보안은 여러분의 책임이며, 이 글의 모든 내용은 바로 그 점에 관한 것입니다.

왜 'Additionally'라는 단어 하나가 방어 체계를 뚫었을까?