GitHub AI 에이전트, 프라이빗 리포지토리 정보 유출 취약점 'GitLost' 발견

이번 'GitLost' 취약점은 AI 에이전트가 신뢰할 수 없는 사용자 입력(Untrusted User Input)을 시스템 지시사항으로 오인하여 발생하는 전형적인 프롬프트 인젝션(Prompt Injection) 공격 사례임. 공격자는 단순히 공개 리포지토리에 악의적인 명령어가 포함된 이슈를 게시하는 것만으로, 에이전트가 조직 내 프라이빗 리포지토리의 README.md 내용을 읽어 공개 댓글로 유출하도록 유도할 수 있었음. 이는 데이터 격리 아키텍처(Data Isolation Architecture)의 부재가 얼마나 치명적인 결과를 초래할 수 있는지 보여줌.

연구진은 GitHub의 보안 가드레일(Security Guardrails)을 우회하기 위해 'Additionally'라는 단어를 사용했으며, 이로 인해 모델이 출력 재구성(Output Reframing)을 시도하며 보안 경고를 무력화했다고 설명함. 이는 LLM 기반 시스템에서 명령어 해석의 유연성(Instruction Following Flexibility)이 보안 경계 설정에 있어 근본적인 난제임을 시사함. 커뮤니티에서는 이러한 모델의 본질적인 취약점(Inherent Vulnerability)을 지적하며, 근본적인 해결책은 아키텍처 수준의 설계(Architectural Design)에 있음을 강조함.

논의에서는 'GitLost'를 AI 에이전트의 SQL 인젝션(SQL Injection)으로 비유하며 그 심각성을 강조함. 그러나 일부에서는 SQL 인젝션의 경우 준비된 구문(Prepared Statements)과 같은 명확한 완화책이 존재하지만, LLM의 자연어 처리 능력(Natural Language Processing Capability) 때문에 프롬프트 인젝션은 훨씬 더 치명적이고 해결하기 어렵다고 주장함. 메뉴 기반의 고정된 동작(Fixed Behaviors)과 같은 아키텍처적 접근이 필요하다는 의견이 제시됨.

일부 사용자는 이번 사태가 GitHub 자체의 취약점이라기보다는, 사용자가 AI 에이전트에 과도한 권한(Excessive Permissions)을 부여하고 민감한 정보를 다루는 방식의 문제라고 지적함. 즉, 에이전트의 인증/인가(Authorization) 로직이 사용자 권한과 일치하지 않거나, 데이터 미저장 정책(Zero-Retention Policy) 없이 민감한 정보에 접근하도록 설정한 것이 근본적인 원인이라는 주장임. 이는 개발자의 책임(Developer Responsibility)과 최소 권한 원칙(Principle of Least Privilege) 준수의 중요성을 부각함.

커뮤니티에서는 대기업들이 투자 압박으로 인해 모든 제품에 AI를 성급하게 통합하려는 경향을 비판함. 이러한 반쪽짜리 AI 통합(Half-assed AI Integrations)은 사용자 피로도를 높이고 결국 실패할 것이라는 전망이 나옴. 또한, GitHub와 같은 클라우드 기반 서비스의 코드 프라이버시(Code Privacy)에 대한 근본적인 의구심을 제기하며, 로컬 Git 환경으로 전환하는 사용자들의 사례도 언급됨.