엔터프라이즈 AI 시스템을 프롬프트 인젝션 공격으로부터 보호하는 방법
How to protect enterprise AI systems from prompt injection attacks
핵심 요약
내부 RAG 시스템의 간접적 프롬프트 인젝션 방어 전략과 실무적 보안 대책을 논의합니다.
- RAG 보안 위협 — 내부 문서에 포함된 악성 지시문이 모델의 동작을 왜곡할 위험이 있음
- 방어 전략 — 프롬프트 필터링보다는 액션 레이어의 엄격한 도구 스키마 검증이 핵심임
- 실무적 대책 — 서버 측 검증, 권한 기반 제어, 모델 출력에 대한 인간 승인 절차 도입
- 보안 도구 — Lakera Guard와 같은 RAG 특화 솔루션 및 이중 모델 격리 방식 활용
내부 LLM 앱을 위한 프롬프트 인젝션 방어 체계를 강화하고 있는데, 지금 딱 "다이어그램은 깔끔해 보이는데 현실은 시궁창"인 단계에 와 있습니다.
현재 설정: FE → API → 오케스트레이터 → LLM + 내부 문서 대상 RAG, 여기에 데이터 웨어하우스와 몇몇 내부 API를 호출할 수 있는 데이터 레이어가 추가된 구조입니다.
뻔한 직접적 프롬프트 인젝션(사용자가 채팅창에 탈옥 텍스트를 입력하는 경우)은 이미 대비했습니다. 지금 저를 괴롭히는 건 RAG를 통한 간접적 인젝션입니다. 지원 티켓, KB 문서, 런북 등에는 모두 지시문 형태의 텍스트가 포함되어 있어서, 검색 루프에 들어가는 순간 모델이 가져온 모든 청크가 모델이 따르는 지시문처럼 행동할 수 있습니다. 무서운 점은 이 조합입니다: 컨텍스트 내의 신뢰할 수 없는 콘텐츠 + 민감 데이터 접근 + 어떤 형태든 데이터 유출 채널. 이 중 하나만 있으면 별거 아니지만, 셋이 합쳐지면 심어놓은 한 줄의 문장이 실제 피해로 이어집니다.
현재 대략적인 계획은 이렇습니다: 검색된 콘텐츠를 신뢰할 수 없는 입력으로 취급하고 지시문 패턴이 있는지 스캔(강력한 차단보다는 텔레메트리 용도), 액션 레이어에 실제 가드레일 적용(좁은 도구 스키마, 허용 목록, 모델 출력을 신뢰하지 않는 서버 측 검증, 상태 변경 시 인간 승인), 신뢰할 수 없는 청크에 대한 이중 모델/격리 패턴 활용, 그리고 문서나 DB 행에 악성 지시문을 심어두고 변경 사항이 있을 때마다 테스트를 다시 돌리는 "인젝션 훈련"을 수행하는 것입니다.
실제 내부 데이터를 대상으로 RAG를 운영하시는 분들께 묻습니다: 프로덕션 환경에서 이런 통제 수단 중 어떤 것이 프롬프트 인젝션을 막는 데 효과적이었나요? 그리고 "프롬프트 필터링"과 "모델이 할 수 있는 일을 엄격히 제한하는 것" 사이의 선을 어디에 긋고 계신가요?
