검색된 콘텐츠를 통해 들어오는 프롬프트 인젝션을 어떻게 막고 계신가요?
How are you catching prompt injection that comes in through retrieved content?
핵심 요약
검색된 외부 데이터에 포함된 프롬프트 인젝션 공격을 탐지하고 방어하는 실무적인 전략을 공유하고 논의합니다.
- 인젝션 취약점 — 사용자 입력 외에 검색된 문서나 도구 응답이 제2의 입력 채널로 악용됨
- 공격 패턴 — HTML 주석이나 PDF 내 숨겨진 지시어 등 눈에 띄지 않는 방식으로 침투함
- 방어 전략 — 입력 텍스트를 모델에 전달하기 전 게이트웨이에서 패턴을 스캔하고 차단함
- 보안 설계 — 모델 자체의 지시 이행 능력에만 의존하지 말고 외부 스캔 도구를 병행해야 함
니 에이전트가 사용자한테 직접 받은 거 말고 웹 페이지, PDF, 벡터 스토어에서 긁어온 문서, 아니면 툴이 뱉어낸 JSON 같은 걸 읽는다면, 너는 지금 네가 직접 짠 것도 아니고 속을 다 들여다볼 수도 없는 '제2의 입력 채널'을 은근슬쩍 열어준 꼴이야. 보통은 사용자 프롬프트만 빡세게 막아놓고 다 했다고 생각하잖아? 근데 정작 아무도 신경 안 쓰는 검색된 콘텐츠 쪽이 문제라고. 진짜 먹히는 인젝션은 다 거기 숨어있거든.
우리는 모델로 들어가는 데이터를 걸러주는 게이트웨이를 운영하는데, 그래서 실제 트래픽에서 이런 시도들을 엄청 많이 보거든. 근데 놀라운 건, 교과서 예시로 맨날 나오는 "이전 지시사항 무시해" 같은 뻔한 멘트는 거의 없다는 거야. 그런 건 잡기도 쉽고, 보통 누가 대놓고 찔러볼 때나 나오지.
진짜 뚫리는 것들은 훨씬 교묘해. HTML 주석에 숨겨진 지시사항 같은 거 말이야. 사람 눈에는 페이지가 깔끔해 보여도 스크래퍼는 그 페이로드를 다 읽거든. PDF 안에 박혀 있다가 청커(chunker)가 문맥 다 잘라내고 그냥 일반 텍스트로 모델에 밀어 넣을 때 발동하는 문장도 있고. 툴 응답에 시스템 노트처럼 보이는 필드 하나 슬쩍 끼워 넣으면 모델은 그걸 진짜 시스템 지시사항인 줄 알고 덥석 물어버려.
이런 건 사용자 메시지에는 절대 안 나오니까, 사용자 입력값만 검사해봤자 하나도 못 잡아내. 우리는 들어오는 텍스트에서 인젝션 패턴을 스캔해서 모델에 닿기 전에 차단하는데, 이때 민감도를 조절할 수 있게 해놨어. 근데 이게 진짜 골 때리는 게, 설정값 하나에 결과가 확 달라진다는 거야. 너무 빡빡하게 잡으면 "지시사항"이나 "시스템 프롬프트"라는 단어만 들어가도 멀쩡한 문서를 다 차단해버리고, 너무 느슨하게 풀면 숨겨진 악성 코드들이 다 통과해버리거든. 적정 수준은 에이전트가 뭘 읽느냐에 따라 다른 거라, 내부 문서를 다루는 에이전트랑 오픈 웹을 뒤지는 에이전트를 똑같은 설정으로 돌리면 안 되는 거지.
그래서, 에이전트가 검색된 문서나 웹 페이지, 툴 출력값을 읽게 만드는 형들한테 진짜 궁금해서 물어보는 건데, 사용자 프롬프트 말고 그 콘텐츠에 섞여 들어오는 인젝션은 다들 어떻게 잡고 있어? 패턴 매칭을 써? 아니면 콘텐츠를 먼저 걸러주는 모델을 하나 더 돌려? 그것도 아니면 문맥에 넣기 전에 서식이나 링크를 다 날려버리는 거야? 아니면 아예 다른 방법이 있어?
