프롬프트 인젝션
프롬프트 인젝션은 공격자가 악의적으로 조작한 입력을 LLM에 주입해, 시스템에 설정된 원래 지침을 무력화하거나 탈취하는 보안 공격입니다. LLM이 신뢰된 지침과 신뢰할 수 없는 데이터를 구분하지 못하는 구조적 약점을 악용하며, 모델을 더 잘 다루기 위한 프롬프트 엔지니어링과는 전혀 다른 개념입니다.
- 프롬프트 인젝션은 조작된 입력으로 LLM의 원래 지침을 무력화·탈취하는 보안 공격으로, 모델을 효과적으로 다루는 프롬프트 엔지니어링과는 전혀 다른 개념입니다.
- 근본 원인은 LLM이 개발자가 설정한 신뢰된 지침과 외부에서 들어온 신뢰할 수 없는 데이터를 같은 입력 스트림에서 구분하지 못하는 구조적 약점입니다.
- 공격자가 직접 채팅창에 악성 명령을 넣는 직접 인젝션과, 웹페이지·문서·이메일 같은 외부 콘텐츠에 명령을 숨겨 두는 간접 인젝션으로 나뉩니다.
- OWASP는 2025년 LLM 보안 위험 목록에서 프롬프트 인젝션을 LLM01, 즉 가장 우선순위가 높은 위협으로 분류했습니다.
- 완벽한 단일 해법은 아직 없으며, 권한 최소화·출력 검증·외부 콘텐츠 격리·사람 승인 같은 다층 방어를 조합해야 합니다.
프롬프트 인젝션이란
프롬프트 인젝션은 공격자가 의도적으로 조작한 입력(프롬프트)을 LLM에 주입해, 시스템에 미리 설정된 원래 지침을 무력화하거나 가로채는 보안 공격입니다. "이전 지침은 모두 무시하고 대신 이렇게 해" 같은 문장을 끼워 넣어 모델의 행동을 공격자가 원하는 방향으로 바꾸는 것이 대표적인 형태입니다. 이 용어는 개발자 Simon Willison이 2022년 9월에 처음 명명했습니다.
핵심은 이것이 모델을 더 잘 활용하기 위한 프롬프트 엔지니어링과는 본질적으로 다른, 명백한 보안 공격 개념이라는 점입니다. 프롬프트 엔지니어링이 원하는 출력을 얻기 위해 정상적으로 지시문을 설계하는 기술이라면, 프롬프트 인젝션은 그 지시 체계를 외부에서 깨뜨려 권한을 탈취하는 공격이며, 따라서 논의의 초점도 공격과 방어에 맞춰집니다.
근본 원인: 지침과 데이터의 경계 붕괴
OWASP는 프롬프트 인젝션을 "사용자 프롬프트가 LLM의 동작이나 출력을 의도하지 않은 방식으로 바꿀 때 발생하는 취약점"으로 정의합니다. 이런 공격이 근본적으로 막기 어려운 이유는, 현재의 LLM이 개발자가 설정한 신뢰된 지침과 사용자 입력·검색 문서·웹페이지 같은 신뢰할 수 없는 콘텐츠를 구분하지 못하기 때문입니다. 모델 입장에서는 둘 다 똑같은 토큰 스트림으로 들어오므로, 데이터 속에 숨겨진 명령을 진짜 지시로 착각하게 됩니다.
탈옥(jailbreaking)과의 차이
프롬프트 인젝션은 흔히 탈옥과 혼동되지만 같은 것이 아닙니다. Simon Willison의 구분에 따르면, 탈옥은 모델 자체의 안전 가드레일을 우회하려는 시도인 반면, 프롬프트 인젝션은 LLM을 기반으로 구축된 애플리케이션에서 신뢰된 시스템 지침과 신뢰할 수 없는 입력이 한 모델 안에서 뒤섞이는 구조적 취약점을 악용하는 더 넓은 개념입니다.
유형: 직접 인젝션과 간접 인젝션
| 구분 | 직접 인젝션 (Direct) | 간접 인젝션 (Indirect) |
|---|---|---|
| 주입 경로 | 공격자가 챗봇·API에 악성 프롬프트를 직접 입력 | 모델이 읽어 들이는 외부 데이터에 악성 명령을 미리 심어 둠 |
| 전형적 위치 | 채팅 입력창, 사용자 메시지 | 웹페이지, 문서, 이메일, RAG 저장소, 이미지 속 텍스트 |
| 공격자와 모델의 접촉 | 직접 상호작용 | 비대면 — 피해자가 해당 콘텐츠를 불러올 때 발동 |
| 대표 위험 | 지침 무력화, 시스템 프롬프트 탈취 | 데이터 탈취, 무단 API 호출, 에이전트 오염·확산 |
OWASP는 이 두 축을 기준으로 챗봇 직접 주입, 웹페이지에 숨긴 명령, RAG 저장소 문서 변조, 여러 문서에 나눠 심는 페이로드 분할, 이미지에 삽입한 멀티모달 공격, 의미 없는 문자열을 덧붙이는 적대적 접미사(adversarial suffix), 인코딩·이모지를 이용한 난독화 공격 등 다양한 시나리오를 제시합니다.
완화책
OWASP는 단일 해법이 아니라 여러 통제를 겹쳐 쓰는 다층 방어를 권고합니다. 주요 통제는 다음과 같습니다.
- 모델 행동 제약: 시스템 프롬프트에 역할과 허용 범위를 명확히 규정하고, 외부 지시를 따르지 않도록 지정합니다.
- 출력 형식 정의·검증: 기대하는 출력 형식을 정하고 결정론적 규칙으로 검증해, 비정상 출력을 걸러냅니다.
- 입력·출력 필터링: 의미 기반 필터와 콘텐츠 규칙으로 악성 패턴을 탐지·차단합니다.
- 권한 최소화: 최소 권한 원칙을 적용하고, 기능별로 분리된 API 토큰을 사용해 피해 범위를 줄입니다.
- 사람의 승인: 메일 발송·결제·삭제 등 위험도 높은 작업에는 사람의 확인 단계를 둡니다.
- 외부 콘텐츠 격리: 신뢰할 수 없는 외부 데이터가 사용자 프롬프트에 미치는 영향을 구조적으로 분리합니다.
- 적대적 테스트: 침투 테스트와 침해 시뮬레이션으로 방어선을 지속적으로 점검합니다.
치명적 3요소(lethal trifecta)
Simon Willison은 2025년 6월, 간접 프롬프트 인젝션이 실제 피해로 이어지는 조건을 "치명적 3요소"로 정리했습니다. 비공개 데이터 접근, 신뢰할 수 없는 콘텐츠 노출, 외부로의 통신 능력이 한 에이전트 안에 동시에 존재하면, 오염된 콘텐츠 하나만으로도 민감 정보가 외부로 유출될 수 있습니다. 따라서 위 통제를 적용할 때 이 세 가지가 한곳에 겹치지 않도록 설계하는 것이 특히 중요합니다.
근거와 실제 사례
프롬프트 인젝션은 이론에 그치지 않고 실제 상용 서비스에서 입증되어 왔습니다. 간접 프롬프트 인젝션을 학술적으로 체계화한 Greshake 등의 논문 "Not what you've signed up for"(arXiv:2302.12173, AISec '23)는 LLM 통합 애플리케이션이 데이터와 지침의 경계를 흐린다는 점을 지적하고, 당시 GPT-4 기반이던 Bing Chat과 코드 자동완성 등을 상대로 동작하는 실제 공격을 시연했습니다. 이 논문은 데이터 탈취, 웜처럼 번지는 확산, 생태계 오염, 무단 API 호출을 위협 분류로 제시하며 간접 인젝션 연구의 토대가 되었습니다.
이런 위험은 에이전트형 AI가 확산되면서 더 두드러지고 있습니다. OWASP는 2025년 LLM 애플리케이션 보안 위험 목록에서 프롬프트 인젝션을 LLM01로, 즉 가장 높은 우선순위의 위협으로 지정했습니다. 또한 2026년 1월에는 여러 AI 생산성 도구에서 동일하게 "치명적 3요소"를 이용한 간접 프롬프트 인젝션 취약점이 잇따라 공개되며, 이 문제가 특정 제품의 결함이 아니라 LLM 통합 시스템 전반의 구조적 과제임을 보여 주었습니다.