【5/12】 StruQ 읽기

방어 3종 중 두 번째. 이번에는

입력의 구조로 해결하는 입장.

arXiv: 2402.06363 (USENIX Security 2025)

이 논문이 답하고 있는 질문

데이터(처리되는 대상)와 명령(시스템 프롬프트)을 분리함으로써, 유용성을 유지하면서 프롬프트 인젝션 (Prompt Injection)을 방지할 수 있는가.

두 가지 구성 요소

① Secure Front-End

명령과 데이터를 어떻게 구분하는가: 구조화된 쿼리 (Structured Query, 일반적인 텍스트로는 표현할 수 없는 것)로 명령과 데이터를 분리한다. 사용자로부터 유래된 데이터에서는 해당 토큰을 제거하여 모델에 전달한다. -
공격자가 구분을 위조할 수 없는 이유는 무엇인가: 필터링이 작동하고 있으므로 문제없다.

② Structured Instruction Tuning

무엇을 정답으로 학습시키는가: 표준적인 명령 튜닝 (Instruction Tuning)을 채택하며, 인코딩된 입력의 프롬프트 부분에 있는 명령 (공격이 없는 깨끗한 프롬프트)을 학습한다. -
전선(영역을 나누는 것)만으로는 부족한 이유: Secure Front-End는 영역을 나누기만 한다. 나눈 뒤에 "데이터 영역의 명령에는 따르지 마라"는 것을 모델이 지켜야 한다. 순수한 모델은 영역이 구분되어 있어도 데이터 영역의 명령을 따라버린다. 따라서 모델을 훈련함으로써 나뉜 경계를 강조하게 만든다.

무엇을 희생하고 있는가

유용성 저하: 거의 영향을 주지 않음 -
구현 비용: 전선은 앱 개발자도 구현할 수 있다. 다만 Instruction Tuning에는 모델 훈련이 필요하다. IH (모델 제공자만 가능)와의 차이점은 이 부분이다. -
전제 조건: 명령과 데이터를 명확히 분리할 수 있는 앱에 한정된다. 무엇이 명령이고 무엇이 데이터인지 결정할 수 없는 구성에서는 사용할 수 없다.

방어 3종 비교표 (매번 추가 예정)

궁금했던 점

원래 데이터가 오염되어 있다면 끝인가?

← 끝입니다.

같은 특별한 구분자를 사용하게 되면 공격이 성공하지 않을까?

← 필터링이 작동하므로 괜찮다. 그리고 예약 토큰(Reserved Token)은 일반적인 텍스트로는 표현할 수 없는 토큰으로 확보되어 있으므로 괜찮다.

하고 있는 일이 어제 읽은 The Instruction Hierarchy와 같은 것 아닌가? 차이점을 잘 모르겠다.

← 비슷하다고 느끼는 이유는 둘 다 훈련을 사용하기 때문이다. 이전의 방식은 저우선순위인 것을 조건부로 다루는 반면, 이번 방식은 데이터 영역의 명령을 완전히 무시한다.

← 사실 시계열로 보면 반대로, 조사해보니 StruQ가 선행 연구이며 IH가 그것을 인용하고 있었다. 차이점은 엄격함의 정도가 아니라, 훈련을 제외했을 때 무엇이 남느냐였다.

다음에 읽을 것

CaMeL (arXiv 2503.18813, SaTML 2026)

Discussion