프롬프트 인젝션 테스트로 배포 직전의 버그를 잡아냄
A prompt injection test caught something we would've shipped
핵심 요약
프롬프트 수정 후 발생한 보안 취약점을 자동화된 테스트로 발견하고 해결한 사례 공유.
- 보안 회귀 테스트 — 프롬프트 수정 시 발생할 수 있는 보안 취약점을 자동화된 평가로 방지함
- 신뢰 계층 구조 — 시스템 지시사항과 검색된 데이터 간의 엄격한 우선순위 설정이 핵심임
- 지속적인 평가 — 단순 인젝션 공격 외에도 일반적인 문서가 명령어로 오인되는 사례를 테스트에 추가함
- 구조적 해결책 — 프롬프트 내부에 보안 경계를 두는 대신 데이터와 명령어를 분리하는 방식이 권장됨
조금 사소하고 지루한 승리지만, 내가 제일 좋아하는 종류의 보안 성과임 하하.
우리는 내부 문서를 검색해서 사용자 질문에 답변하는 문서 어시스턴트를 운영 중임. 프롬프트를 리팩토링한 후, 어시스턴트가 검색된 문서 텍스트에 너무 많은 권한을 부여하기 시작했음. 적대적인 테스트 문서 하나에 악의적인 지시사항이 깊숙이 숨겨져 있었는데, 어시스턴트가 문서를 신뢰할 수 없는 콘텐츠로 취급해야 함에도 불구하고 그 지시사항을 따르기 시작한 거임. 엄청난 익스플로잇 체인 같은 건 아니었음. 다들 새로운 프롬프트가 더 자연스럽게 들리는지에만 집중하다 보니 조용히 배포될 뻔한 전형적인 회귀 버그였음.
우리를 구한 건 이미 릴리즈 파이프라인에 적대적 평가(adversarial evals)를 포함해뒀다는 점이었음. 지시사항 계층 공격, 검색된 문서 내의 가짜 시스템 메시지, 정책 무시 시도 등이 포함된 예제들을 대상으로 프롬프트를 다시 실행했음. Braintrust가 즉시 회귀를 잡아냈고, 트레이스를 열어보니 에이전트가 검색된 텍스트를 지시사항처럼 취급하기 시작한 지점을 확인할 수 있었음.
우리는 프롬프트 계층 구조를 변경하고, 검색된 텍스트가 시스템 지시사항을 무시할 수 있는지 판단하는 더 엄격한 스코어러를 추가했으며, 알려진 사례들이 다시 통과될 때까지 머지를 차단했음. 지루한 수정이었지만, 그게 바로 우리가 원하던 거였음. 아무도 긴급 채널에 뛰어들거나 이미 프로덕션에 배포된 내용 때문에 오후 내내 고민할 필요가 없었음.
우리가 얻은 가장 큰 교훈은 시스템 지시사항과 검색된 데이터 사이에 엄격한 신뢰 계층 구조를 유지해야 한다는 것임. 데이터가 시스템을 무시할 수 있다면, 보안 모델은 깨진 거나 다름없음.
