[AISec] Day 1: 프롬프트 인젝션(Prompt Injection)과 간접 인젝션의 메커니즘

서론: LLM의 입력면은 생각보다 훨씬 넓다

전통 보안에서는 사용자 입력 검증이 핵심이었다. LLM 시스템에서는 입력면이 더 넓다.

• 직접 입력된 사용자 프롬프트
• RAG가 가져온 외부 문서
• 툴 호출 결과와 시스템 메시지

이 중 하나라도 오염되면 모델 동작이 탈선할 수 있다.

1. 프롬프트 인젝션의 본질

프롬프트 인젝션은 “모델이 따를 지시 체계”를 공격자가 재정의하는 공격이다.

예시:

• 안전 정책 무시 유도
• 내부 지침/비밀 정보 노출 유도
• 악성 툴 호출 유도

핵심은 SQL 인젝션처럼 구문 파괴가 아니라, “의도 우선순위 교란”이다.

2. 직접 인젝션 vs 간접 인젝션

2.1 직접 인젝션

사용자가 대화 입력에서 직접 공격 지시를 넣는다.

2.2 간접 인젝션

RAG 문서, 웹페이지, 첨부 파일 등 외부 데이터에 숨겨진 지시가 모델 컨텍스트로 유입된다.

간접 인젝션이 더 위험한 이유:

• 정상 데이터처럼 보이기 쉽고
• 파이프라인 중간에서 전파되며
• 사용자도 공격 존재를 인지하기 어렵다

3. RAG 파이프라인 공격 경로

Poisoned Content -> Ingestion -> Chunking -> Embedding -> Retrieval -> LLM Response

문서가 한 번 인덱싱되면 반복적으로 회수되어 장기적 오염원이 될 수 있다.

4. 방어 설계 원칙

1. Instruction/Data 분리: 문서 내용과 실행 지시를 같은 신뢰 레벨로 취급하지 않음
2. Context Sanitization: 회수 문서에서 의심 패턴 필터링
3. Tool Use Policy: 모델의 툴 호출 권한을 최소화
4. Output Validation: 응답 단계에서 민감정보/정책 위반 검증

5. 운영 체크포인트

• 회수 문서 출처 신뢰 등급
• 인젝션 패턴 탐지율
• 툴 호출 실패/차단 로그
• 응답 차단률과 오탐률

6. Day 1 체크리스트

1. 프롬프트 계층(system/user/retrieved context) 우선순위를 명시했다.
2. RAG 문서 전처리에 인젝션 패턴 스캔을 추가했다.
3. 툴 호출을 allow-list 기반으로 제한했다.
4. 인젝션 시나리오를 포함한 보안 테스트 케이스를 작성했다.

다음 글 예고

Day 2에서는 RAG 환경에서 자주 발생하는 데이터 유출(Data Leakage) 문제와 PII 탐지/차단 전략을 다룬다.