Why Prompt Injection Won't Be "Fixed"

개요

Prompt injection은 LLM의 근본적인 아키텍처 속성으로 인해 근본적인 해결이 불가능하며, 모델 자체를 똑똑하게 만드는 것이 아닌 시스템 수준의 설계와 보안 조치를 통해 관리해야 하는 취약점이다.

주요 내용

• Prompt Injection의 본질: LLM은 단일 입력 채널을 통해 토큰 시퀀스를 받아 다음 토큰을 예측하는 방식으로 작동하며, 시스템 프롬프트와 데이터(예: 이메일 본문) 간의 명확한 구조적 분리가 없어 특정 입력이 더 권위 있는 명령으로 해석될 가능성이 존재한다.
• SQL Injection과의 차이점: SQL Injection은 언어의 문법적 구조를 이용해 데이터와 명령을 분리하지만, 자연어는 이러한 구조적 분리가 없어 LLM이 실행할 내용과 조작 시도를 구분하기 어렵다.
• 공격 유형:
• Direct Injection: 사용자가 직접 모델에 악의적인 명령을 주입하는 방식.
• Indirect Injection (Data): 공격자가 모델이 나중에 읽게 될 데이터(이메일, 웹 페이지 등)에 악의적인 명령을 삽입하는 방식. 에이전트 시스템에서 취약.
• Indirect Injection (Tools): 에이전트가 호출하는 외부 도구가 손상되었거나 제3자 데이터를 노출할 때 발생.
• Encoding and Obfuscation: Base64 인코딩, 단어 순서 변경, 다른 언어 사용 등으로 탐지를 우회.
• Multi-turn Attacks: 여러 차례의 대화를 통해 모델을 서서히 특정 시나리오로 유도한 후 악의적인 요청을 하는 방식.
• 현존 방어 기제와 한계:
• System-prompt Incantations: 간단하거나 주의가 부족한 공격은 막지만, 새로운 형태의 지시어나 인코딩된 내용은 놓칠 수 있음.
• I/O Classifiers: 학습된 패턴 기반 공격은 탐지하지만, 공격자가 같은 모델에 접근할 경우 정확도가 저하됨.
• Architectural Channel Separation: 단순한 간접 주입은 막을 수 있으나, 모델이 압박 속에서 통계적으로 잊어버리도록 학습된 내용은 탐지하기 어려움.
• Action-level Isolation: 치명적인 결과(데이터 유출, 금액 이동)는 방지하지만, 에이전트가 여전히 수행하도록 허용된 작업 내에서는 막을 수 없음.
• 근본적인 해결책은 '시스템 아키텍처':
• 모든 외부 데이터를 적대적으로 취급해야 함.
• 상태 변경 작업은 out-of-band(예: 인간 검토, 별도 모델 검증, 지연 시간)를 통해 명시적으로 확인받도록 설계해야 함.
• 에이전트의 컨텍스트에 불필요한 비밀 정보(API 키, 토큰 등)를 넣지 않아야 함.
• 전체 컨텍스트를 기록하여 사후 조사를 용이하게 해야 함.
• 문서를 읽는 모델과 행동하는 모델을 분리하여 공격자가 두 가지를 동시에 침해하도록 만들어야 함.
• '더 똑똑한 모델'로는 해결 불가: 모델 성능 향상은 공격 모델의 성능 향상과 동등하게 이루어지며, 단일 입력 채널과 통계적 힌트로는 근본적인 문제를 해결할 수 없다.
• 안전 시스템 구축의 중요성: LLM을 신뢰할 수 없는 구성 요소로 취급하고, 최소 권한, 행동 확인, 감사 로그, 모델 역할 분리 등 표준 보안 엔지니어링 원칙을 적용해야 한다.

시사점

Prompt injection은 LLM 자체의 한계라기보다는 LLM을 포함하는 시스템 설계의 문제이며, 이는 기존 정보 보안 분야에서 사용되는 원칙들을 새로운 AI 컴포넌트에 적용하여 해결해야 할 과제이다.