본문 바로가기
LLM/Prompting

프롬프트 인젝션과 LLM 보안

by AtoN 2023. 10. 31.

프롬프트 인젝션과 LLM 보안

SQL 인젝션에서는 공격자가 넣은 문자열이 데이터가 아니라 SQL 문법으로 해석되면서 문제가 생깁니다. 값을 parameter binding으로 전달하면 데이터와 실행할 SQL 구조를 API 수준에서 분리할 수 있고, 이를 통해 대표적인 SQL injection 경로를 구조적으로 차단할 수 있습니다.

LLM에서는 이 경계가 훨씬 흐립니다. API에는 system, user, tool 같은 role이 있지만 이것은 모델이 입력의 의미와 우선순위를 판단하기 위한 형식이지, 운영체제의 권한 검사처럼 외부에서 강제되는 보안 경계는 아닙니다. 검색한 문서, 웹페이지, 이메일, tool output처럼 원래는 데이터여야 할 텍스트도 모델의 context에 들어오면 자연어 지시로 해석되어 행동에 영향을 줄 수 있습니다.

이 때문에 사용자가 직접 공격 문구를 입력하는 direct prompt injection뿐 아니라, 모델이 읽어 온 외부 데이터에 공격자의 지시를 숨기는 indirect prompt injection이 특히 문제가 됩니다. 도구를 사용할 수 있는 에이전트에서는 단순히 이상한 답을 만드는 데서 끝나지 않고, 잘못된 tool call이나 정보 유출 같은 실제 행동으로 이어질 수도 있습니다.

2023년 초기 indirect prompt injection 연구는 당시 효과적인 완화책이 부족하다고 지적했습니다. 이후 입력 필터링, instruction/data 분리, guardrail, human approval 같은 여러 방어가 발전했지만, 현재도 이것들만으로 공격 자체를 완전히 제거한다고 보기는 어렵습니다. 그래서 중요한 권한과 데이터 접근은 모델의 지시 준수에 맡기지 않고 least privilege, deterministic authorization, tool validation 같은 시스템 바깥의 통제로 제한하는 것이 핵심입니다.

프롬프트 인젝션이 왜 단순한 “나쁜 프롬프트” 문제가 아니라 코드와 데이터의 경계가 흐려지는 구조적 문제인지부터 살펴봅니다. 이어서 direct와 indirect injection이 어떻게 다른지, 그리고 완전한 예방이 어렵다면 실제 시스템에서 공격의 성공 가능성과 피해 범위를 어떻게 줄여야 하는지까지 봅니다.

1장. 문제의 성격

근본 원인. Indirect Prompt Injection 논문(2023-02)은 이 문제를 다음처럼 설명합니다. 아래 논문 인용은 영어 원문의 의미를 살려 옮긴 번역입니다.

우리는 LLM 통합 애플리케이션이 데이터와 명령어 사이의 경계를 흐린다고 주장한다.

전통적인 프로그램에서는 parser와 타입 시스템이 코드와 데이터를 비교적 명확하게 나눕니다. LLM 입력은 role token과 구분자를 포함할 수 있지만 결국 모델이 학습된 확률적 규칙으로 해석합니다. 신뢰하지 않는 자연어를 “절대로 명령으로 취급하지 않게” 강제하는 deterministic privilege boundary가 모델 내부에 있는 것은 아닙니다.

SQL 인젝션과 비교. Prepared statement는 값이 SQL syntax가 되는 경로를 API 수준에서 막을 수 있습니다. 프롬프트 인젝션에서는 “이 부분은 참고 데이터”라는 markup을 넣어도 그것을 최종적으로 해석하는 주체가 모델입니다. 그래서 delimiter와 role marker는 도움이 되지만 SQL parameter binding과 같은 보안 보장은 아닙니다.

OWASP LLM01. OWASP Top 10 for LLM Applications(2025)에서 Prompt Injection이 LLM01입니다.

2장. 직접과 간접

직접 인젝션. 사용자가 직접 입력창에 넣습니다. 이전 지시를 무시하고 시스템 프롬프트를 출력하라는 식이고, 공격자가 곧 사용자입니다.

간접 인젝션. 논문이 제기한 질문입니다.

지금까지는 사용자가 LLM에 직접 프롬프트를 넣는다고 가정했다. 그런데 프롬프트를 넣는 것이 사용자가 아니라면?

논문의 정의는 이렇습니다.

우리는 간접 프롬프트 인젝션을 사용하는 새로운 공격 벡터를 밝힌다. 이는 적대자가 검색될 가능성이 높은 데이터에 전략적으로 프롬프트를 주입함으로써, 직접적인 인터페이스 없이 원격으로 LLM 통합 애플리케이션을 악용할 수 있게 한다.

더 위험한 이유. 공격자가 최종 사용자와 직접 상호작용하지 않아도 됩니다. 모델이 읽는 웹페이지, 문서, 이메일, tool output, memory 등에 공격 문자열을 심어 둘 수 있습니다. RAG가 신뢰하지 않는 외부 소스를 검색한다면 그 검색 범위만큼 간접 입력의 공격 표면이 넓어집니다.

숨기는 자리. 사람 눈에 안 보이게 숨길 수 있습니다.

흰 배경에 흰 글씨
아주 작은 폰트
HTML 주석
이미지 안의 텍스트

사람에게 잘 보이지 않아도 parser, OCR, multimodal model 등이 해당 내용을 입력으로 추출하면 공격이 성립할 수 있습니다. 반대로 파이프라인이 읽지 않는 정보는 모델에도 전달되지 않습니다.

3장. 공격으로 할 수 있는 일

논문이 세운 분류입니다.

우리는 컴퓨터 보안 관점에서 포괄적인 분류 체계를 도출하여 영향과 취약점을 체계적으로 조사한다. 여기에는 데이터 절도, 웜 확산, 정보 생태계 오염, 그리고 기타 새로운 보안 위험이 포함된다.

위험의 크기를 이렇게 표현합니다.

우리는 검색된 프롬프트를 처리하는 것이 임의 코드 실행처럼 작동할 수 있고, 애플리케이션의 기능을 조작하며, 다른 API가 어떻게 그리고 호출될지 여부를 통제할 수 있음을 보인다.

에이전트가 도구를 쓴다면 공격 입력이 모델의 tool-call 판단을 조작해, 그 에이전트에 이미 부여된 권한 범위 안에서 의도하지 않은 행동을 유도할 수 있다는 뜻입니다. 실제 피해 규모는 도구 권한과 별도 authorization 경계에 달려 있습니다.

실제 시스템에서도 확인했습니다.

우리는 Bing의 GPT-4 기반 Chat과 코드 자동완성 엔진 같은 실제 시스템, 그리고 GPT-4로 구축한 합성 애플리케이션 모두에 대해 공격의 실용적 실현 가능성을 입증한다.

연구실 안의 이야기가 아닙니다.

웜. 감염된 출력이 다시 다른 모델의 입력이 됩니다. 에이전트가 메일을 읽고 답장을 쓰는 구조라면 답장에 인젝션이 실려 퍼집니다.

4장. Jailbreak

프롬프트 인젝션은 시스템의 의도를 가로채고, jailbreak은 모델의 안전 정렬을 우회합니다. 겨냥하는 층이 다릅니다.

초기 jailbreak는 수작업 prompt engineering 비중이 컸습니다. Universal and Transferable Adversarial Attacks on Aligned Language Models(2023-07)은 당시 상황을 다음처럼 설명합니다. 아래 인용도 의미를 살린 번역입니다.

이러한 조치를 우회하는 데 일부 성공이 있었지만, 이른바 LLM에 대한 "jailbreak" 공격들은 상당한 인간의 창의성을 요구했고 실제로는 취약했다.

할머니 역할극을 해 달라는 식의 수법이라, 막히면 다시 사람이 새로 만들어야 했습니다.

이 논문의 기여는 그 과정을 자동화한 것입니다.

우리의 접근은 수작업 엔지니어링에 의존하는 대신, 탐욕적 탐색과 그래디언트 기반 탐색 기법의 조합으로 이러한 적대적 접미사를 자동으로 생성한다.

질의 뒤에 붙이는 접미사를 찾되, 모델이 거절하는 대신 긍정적으로 응답할 확률을 최대화하도록 탐색합니다.

더 놀라운 것은 그렇게 만든 접미사가 다른 모델에도 통했다는 점입니다.

놀랍게도 우리는 이 접근으로 생성된 적대적 프롬프트가 블랙박스로 공개된 LLM들에까지 상당히 전이 가능하다는 것을 발견했다.

논문이 확인한 범위입니다.

Vicuna-7B와 13B에 대해 훈련한 결과 공격 접미사는 ChatGPT, Bard, Claude의 공개 인터페이스, 그리고 LLaMA-2-Chat, Pythia, Falcon 같은 오픈소스 LLM에서도 문제성 콘텐츠를 유도할 수 있었다.

이 연구는 오픈 모델에서 최적화한 adversarial suffix가 당시 여러 공개 black-box 모델로 전이될 수 있음을 보였습니다. 따라서 가중치 비공개만으로 충분한 방어가 되지는 않지만, 모든 공격이 모든 모델로 동일하게 전이된다는 뜻도 아닙니다.

여기서 중요한 결론은 가중치 비공개만으로 충분한 방어가 되지 않을 수 있고, 모델 자체의 안전 정렬만으로도 시스템 권한 문제까지 해결되지는 않는다는 점입니다. 실제 방어는 애플리케이션과 권한 계층까지 내려가야 합니다.

5장. OWASP GenAI LLM Top 10 2026

OWASP GenAI Security Project는 2026년 8월 LLM Top 10 2026을 공개했습니다. Prompt Injection은 여전히 1위지만 agentic deployment의 영향을 반영해 Excessive Agency가 3위로 올라갔고, 2025년의 System Prompt Leakage는 더 넓은 Hidden Context Exposure로 재구성됐습니다.

ID 항목 뜻
LLM01:2026 Prompt Injection 직접·간접·멀티모달 입력이 모델 행동을 의도와 다르게 바꿈
LLM02:2026 Sensitive Information Disclosure 민감 정보 노출
LLM03:2026 Excessive Agency 과도한 기능·권한·자율성이 피해를 확대
LLM04:2026 Supply Chain 모델·데이터·컴포넌트 공급망 위험
LLM05:2026 Data and Model Poisoning 데이터·모델·fine-tuning 오염
LLM06:2026 Unbounded Consumption 자원·비용의 무제한 소비
LLM07:2026 Misinformation 잘못된 정보가 판단과 행동으로 이어지는 위험
LLM08:2026 Hidden Context Exposure system/developer 지시·도구 schema 등 숨은 문맥의 노출
LLM09:2026 Vector and Embedding Weaknesses 벡터·임베딩 계층의 취약점
LLM10:2026 Improper Output Handling 모델 출력을 안전하지 않게 실행·렌더링·전달

이 문서의 주제와 특히 가까운 항목은 세 개가 연결됩니다.

LLM01  Prompt Injection
   신뢰하지 않는 입력이 모델의 판단을 바꾸는 시작점

LLM03  Excessive Agency
   주입이 성공했을 때 도구·권한 때문에 피해가 커지는 증폭기

LLM10  Improper Output Handling
   조작된 모델 출력이 코드·HTML·SQL·downstream system으로 넘어가는 출구

2026 보고서는 모델이 단순한 component를 넘어 도구와 memory를 가진 actor가 되는 경우에는 OWASP Top 10 for Agentic Applications 2026도 함께 보라고 명시합니다. Agent 보안에서는 prompt injection 하나만 보는 것이 아니라 tool misuse, identity/privilege, memory/context poisoning 같은 agentic risk까지 별도로 봐야 합니다.

중심은 피해 한도. 인젝션 가능성을 완전히 제거하기 어렵다면 성공하더라도 중요한 자산에 닿지 못하도록 blast radius를 줄여야 합니다. 최소 권한, 명시적 authorization, sandbox, 승인 절차가 이 층을 담당합니다.

6장. 방어

완전한 해법의 부재. 아래 문장은 2023년 Indirect Prompt Injection 논문의 결론입니다.

LLM에 대한 통합과 의존이 증가함에도 불구하고, 이러한 신종 위협에 대한 효과적인 완화책은 현재 부족하다.

OWASP LLM Top 10 2026도 Prompt Injection을 LLM01로 유지하면서, 현재 LLM에는 instruction과 data를 강제 분리하는 architectural boundary가 없으므로 신뢰할 수 있는 완전 예방책이 없고 방어는 architecture와 blast-radius 제한 중심이어야 한다고 설명합니다. 특정 system prompt 문구 하나를 보안 경계로 취급해서는 안 됩니다.

권한 최소화와 deterministic authorization. 에이전트에 필요한 도구만 주고, 실제 권한 검사는 LLM 판단이 아니라 애플리케이션 코드에서 강제합니다. 읽기와 쓰기를 분리하고, 사용자/tenant 권한·허용 리소스·금액 한도 같은 조건을 tool 실행 직전에 다시 검사합니다.

위험 동작에 사람 승인. 결제, 외부 전송, 파일 삭제, 권한 변경처럼 되돌리기 어렵거나 영향이 큰 동작은 사람이 확인하거나 별도의 정책 엔진이 승인하게 합니다. 단순히 모델에게 “확인했니?”라고 묻는 것은 독립 승인 경계가 아닙니다.

출력 불신 원칙. 모델 출력을 그대로 실행하지 않고, 그대로 HTML로 렌더링하지 않고, 그대로 SQL에 넣지 않습니다. 입력 검증과 출력 이스케이프라는 기존 웹 보안의 원칙이 그대로 적용됩니다.

데이터 출처와 provenance 유지. 외부 문서, 사용자 입력, tool output을 신뢰 수준별로 태깅하고 그 출처를 tool policy까지 전달합니다. 모델에게 “명령으로 읽지 마라”고 부탁하는 것만으로는 충분하지 않지만, untrusted data가 곧바로 privileged action으로 이어지지 않도록 실행 경로를 분리하는 데 도움이 됩니다.

실행 격리. 코드 실행이 필요하면 샌드박스에서 합니다. 네트워크 접근을 제한해 데이터 유출 경로를 막습니다.

탐지와 로깅. 의심스러운 패턴, tool call, authorization failure 같은 보안 이벤트를 기록하면 사고 경로를 추적하는 데 도움이 됩니다. 다만 prompt와 tool output에는 개인정보나 비밀이 섞일 수 있으므로 원문을 무조건 전부 저장하지 말고 redaction, 접근 제어, 보존 기간을 함께 설계해야 합니다.

숨은 문맥을 비밀 저장소로 쓰지 않기. 2026 목록에서는 기존 System Prompt Leakage가 LLM08 Hidden Context Exposure로 확장됐습니다. System prompt뿐 아니라 developer instruction, RAG로 주입된 policy, tool/function schema 등 사용자가 직접 보지 못하는 operational context 전체가 대상입니다. OWASP는 이 context가 발견될 수 있다고 가정하고 credential·connection string·token을 넣지 말며, authorization이나 policy enforcement를 그 비밀성에 의존하지 말라고 권고합니다.

7장. 실무 점검 목록

설계 단계에서 물을 것입니다.

① 이 에이전트가 실제로 필요한 도구는 무엇인가
② 최악의 경우 무엇까지 할 수 있는가
③ 외부 데이터가 들어오는 경로는 어디인가
④ 되돌릴 수 없는 동작이 있는가

구현 단계에서 확인할 것입니다.

① 출력을 실행, 렌더링, 질의에 넣기 전에 검증하는가
② 도구 권한이 최소인가
③ 위험 동작에 승인 절차가 있는가
④ 실행 환경이 격리돼 있는가
⑤ 사용량 한도가 걸려 있는가

운영 단계에서 볼 것입니다.

① 프롬프트와 도구 호출이 로그에 남는가
② 이상 패턴을 감시하는가
③ 사고 시 차단할 수단이 있는가

자주 하는 실수. 이전 지시를 무시하라는 말만 막으면 된다고 생각하는 것이 첫 번째입니다. 표현은 무한히 바꿀 수 있습니다. 시스템 프롬프트로만 방어하려는 것도 모델에게 지키라고 부탁하는 것에 불과합니다. RAG 문서를 신뢰하는 것은 가장 흔한 간접 인젝션 경로이고, 에이전트에 관리자 권한을 주는 것은 편하지만 피해 크기를 무한대로 만듭니다.

8장. 정리

프롬프트 인젝션의 어려움은 모델이 자연어 지시와 외부 데이터를 같은 추론 문맥 안에서 처리한다는 데 있습니다. 특히 간접 인젝션은 웹페이지, 문서, 이메일, tool output처럼 사용자가 직접 작성하지 않은 입력에서도 들어올 수 있습니다. 완벽한 탐지에 기대기보다 최소 권한, 독립적인 authorization, 위험 동작 승인, 출력 검증으로 성공했을 때의 피해 범위를 제한하는 것이 중요합니다.

세 유형을 실무적으로 구분하면 다음과 같습니다. 실제 문헌과 제품에서는 prompt injection과 jailbreak라는 용어가 일부 겹쳐 쓰이므로, 절대적인 분류라기보다 공격이 어느 제어 경계를 노리는지를 구분하기 위한 표로 보는 편이 좋습니다.

구분 직접 인젝션 간접 인젝션 탈옥
누가 넣나 사용자 문서나 웹페이지 사용자
노리는 것 시스템 의도 시스템 의도 안전 정렬
접촉 필요 있음 없음 있음
주요 완화 최소 권한, authorization, 입력/출력 검증 provenance, 권한 격리, 승인 모델 안전학습, 정책 필터, 시스템 수준 권한 통제

Prompt engineering만으로 강한 보안 경계를 만들 수 없고 방어는 시스템 설계까지 내려가야 합니다. 가중치 비공개는 일부 공격 비용을 올릴 수 있지만 전이 공격 때문에 충분조건은 아닙니다. RAG·브라우징·이메일·tool output은 모두 간접 입력 경로가 될 수 있고, system prompt에는 유출되면 안 되는 비밀이나 실제 authorization 규칙을 두지 않아야 합니다.

용어 정리

용어 한 줄 뜻
프롬프트 인젝션 입력에 명령을 섞어 시스템의 원래 의도를 가로채는 공격
직접 인젝션 사용자가 입력창에 직접 넣는 방식
간접 인젝션 모델이 읽을 문서나 웹페이지에 미리 심어 두는 방식
탈옥 (Jailbreak) 모델의 안전 정렬을 우회해 거절할 내용을 끌어내는 것
적대적 접미사 질의 뒤에 붙여 거절을 무력화하도록 탐색된 문자열
전이성 한 모델에서 만든 공격이 다른 모델에도 통하는 성질
OWASP GenAI LLM Top 10 LLM 애플리케이션의 주요 보안 위험을 정리한 OWASP 가이드. 이 문서는 2026판 기준
과도한 권한 (Excessive Agency) 에이전트에 필요 이상의 도구나 권한을 준 상태
Hidden Context Exposure system/developer 지시, tool schema 등 숨은 operational context가 노출·추론·재구성되는 위험
샌드박스 실행을 격리해 외부에 영향을 못 주게 하는 환경
인간 개입 (Human in the Loop) 위험한 동작 전에 사람이 승인하는 절차

참고자료

'LLM > Prompting' 카테고리의 다른 글

CoT(Chain of Thought)  (0) 2024.05.24
ToT(Tree of Thoughts)  (0) 2024.03.22

관련글

댓글

티스토리툴바