AI 보안 스캐너를 만들었습니다 — 그리고 제 탐지기에서 버그를 발견했습니다
프롬프트 인젝션(Prompt injection)은 LLM 애플리케이션의 주요 보안 위험 요소입니다. 모델에게 원래의 지침을 무시하라고 지시하는 텍스트를 입력하는 방식입니다. 때때로 모델은 그 지시를 따릅니다.
저는 이를 테스트하기 위해 AgentProbe를 구축했습니다. 이 도구는 탈옥(jailbreak) 및 데이터 추출과 같은 8개 카테고리에 걸쳐 49개의 공격 프롬프트를 실행합니다. 그리고 모델이 얼마나 자주 실패하는지를 보고합니다.
진짜 교훈은 스캐너가 아니었습니다. 바로 제 탐지 코드에 있던 버그였습니다.
어려운 것은 공격이 아닙니다. 어려운 것은 탐지입니다.
모델이 실제로 공격에 응했는지 어떻게 알 수 있을까요? 키워드 매칭(Keyword matching)은 쉬운 방법입니다. "도와드릴 수 없습니다"와 같은 거절 문구나 "developer mode"와 같은 준수 문구를 찾는 방식입니다.
하지만 모델들은 "회피 후 준수(hedge-then-comply)" 패턴을 사용합니다. "그 일은 도와드릴 수 없습니다"라고 말하면서도, 결국 제한된 정보를 제공해 버립니다. 이 경우 거절 문구가 포함되어 있기 때문에 키워드 매칭은 실패합니다.
이를 해결하기 위해 저는 "LLM-as-judge" 시스템을 사용했습니다. 대상 모델이 실제로 지침을 따랐는지 판단하기 위해 대화 내용을 더 강력한 모델로 보냈습니다. 제 계획은 먼저 저렴한 키워드 체크를 수행하고, 키워드 체크 결과가 불확실할 때만 비용이 많이 드는 judge 모델을 사용하는 것이었습니다.
그러다 버그를 발견했습니다.
제 키워드 탐지기는 "회피 후 준수" 패턴을 발견했을 때 신뢰도 점수(confidence score) 1을 반환했습니다. 하지만 제 코드는 신뢰도가 2 이상일 때만 키워드 단계의 결과를 신뢰하도록 되어 있었습니다.
이는 제 "저렴한" 탐지기가 실제로 결정을 내린 적이 없음을 의미했습니다. 모든 사례가 비용이 많이 드는 judge 모델로 넘어갔습니다. 무료 도구가 처리했어야 할 상황에서도 매번 judge 모델에 비용을 지불하고 있었던 것입니다.
이 실수를 통해 다른 LLM을 평가하기 위해 LLM을 사용하는 것에 관한 세 가지 교훈을 얻었습니다:
- judge는 대상 모델보다 똑똑해야 합니다. judge가 대상 모델과 크기가 같다면, 동일한 사각지대를 공유하게 될 것입니다.
- 정확도는 거짓말을 할 수 있습니다. 대부분의 모델이 거절한다면, 항상 "거절함"이라고 답하는 judge는 정확해 보이지만 아무것도 배우지 못합니다. 운의 요소를 고려하기 위해 Cohen's kappa와 같은 지표를 사용하세요.
- judge는 안정적이어야 합니다. 동일한 테스트를 다섯 번 실행해 보세요. 만약 judge의 판단이 바뀐다면, 그 결과는 모호하며 사람의 검토가 필요합니다.
LLM으로 무언가를 구축한다면, 다음 사항들을 기억하세요:
- 준수 여부를 탐지하는 것이 준수를 유도하는 것보다 더 어렵습니다.
- 첫 문장에서는 거절하지만 두 번째 문장에서 준수하는 모델을 주의하세요.
- LLM judge를 맹목적으로 신뢰하지 마세요. 신뢰성을 측정해야 합니다.
- 버그를 공유하세요. 저 자신의 결함을 발견한 것이 완벽한 출시보다 더 많은 것을 가르쳐 주었습니다.
Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a
Optional learning community: https://t.me/GyaanSetuAi