We Tricked GitHub's AI Agent into Leaking Private Repos
제목: AI 에이전트가 GitHub의 비공개 저장소를 유출하게 만든 방법
최근 논의된 내용은 AI agent1를 대상으로 하는 프롬프트 주입(Prompt injection) 공격의 심각성을 다룬다. 이 공격은 단순한 취약점을 넘어, LLM(Large Language Model)이 가진 근본적인 구조적 문제와 연결되어 있다. 특히 에이전트가 비공개 데이터 접근, 신뢰할 수 없는 외부 콘텐츠 읽기, 그리고 외부 통신 능력을 동시에 가질 때 위험도가 극대화된다.
프롬프트 주입 공격의 심각성: SQL 인젝션과의 비교 참여자들은 프롬프트 주입 공격이 웹 애플리케이션에서 발생했던 SQL injection2보다 LLM에 훨씬 치명적이라고 지적한다. SQL 인젝션은 사용자 입력(user input)이 SQL 엔진에 전달되는 명령어 문자열의 일부로 처리될 때 문제가 발생했다. 이 문제에 대한 해결책은 ‘prepared statements’였는데, 이는 명령 구조를 고정하고 사용자의 입력을 순수한 데이터로만 취급하게 함으로써 코드와 데이터를 분리하는 방식이었다.
그러나 LLM의 경우, 사용자 입력 자체가 본질적으로 모델에게 전달되는 ‘지시(instruction)’ 역할을 하도록 설계되어 있어 이 둘을 근본적으로 분리하기 어렵다는 것이 핵심 문제다. 즉, 사용자의 의도가 곧 명령이 되는 구조적 한계가 존재한다.
보안 관점에서의 근본적인 결함: 현재의 LLM 보안 노력은 종종 ‘돼지 위의 립스틱(lipstick on a pig)‘에 비유될 만큼 임시적이거나 표면적이라는 비판이 제기된다. 특히, 기업들이 사내 문서를 포함한 민감 데이터를 모델 학습에 활용하는 과정에서 데이터 프라이버시와 보안이 필수 요구사항임에도 불구하고, 내부 저장소에 대한 경계(boundary)가 명확하지 않다는 지적이 나왔다.
또한, 검색 증강 생성(RAG search)과 같은 기술은 마법이 아니며, 본질적으로 수동으로 만든 인덱스에 대한 SQL 쿼리와 같으므로, 애초부터 전통적인 접근 통제 시스템(Access Control System)을 내장할 수 있어야 한다고 강조한다.
안전한 에이전트 구축을 위한 제언: 전문가들은 LLM의 위험성을 줄이기 위해 다음과 같은 방어적 조치를 제시했다. 첫째, 모델의 기능을 제한하는 ’limited-instruction’ 방식(예: 요약 기능만 수행)을 도입하여 명령어 수신 범위를 좁히는 것이다. 둘째, 민감한 데이터에 접근할 때는 반드시 전통적인 인증 및 권한 부여 시스템을 거치도록 강제해야 한다. 마지막으로, 사용자 입력 중 신뢰할 수 없는 데이터를 명시적으로 프롬프트 내에서 표시하고(mark), 모델에게 항상 주의를 기울이도록 지시하는 것이 필요하다.