Semantic DLP: AI 모델이 데이터 유출을 감지할 수 있을까?

This is a submission for the Kaggle Benchmarking Challenge

제가 벤치마킹한 내용

직원들은 AI 도구에 놀라운 것들을 붙여넣습니다: 독점 알고리즘, 미공개 재무 정보, 사고 사후 분석 보고서(incident postmortems), 고객 계약 조건 등. 엔드포인트 데이터 유출 방지(DLP)는 텍스트가 기기를 떠나기 전에, 일반 노트북에서 밀리초 단위로, 그리고 텍스트를 어디에도 전송하지 않고 이를 포착해야 합니다.

저는 이 문제의 핵심인 **시맨틱 누출 감지(semantic leak detection)**에 대한 벤치마크를 구축했습니다. 정규 표현식이나 알려진 키 형식으로는 안 됩니다 (이것들은 이미 해결된 문제입니다); 문제는 모델이 독점적인 기술 콘텐츠와 거의 동일해 보이는 공개적인 기술 콘텐츠를 구별할 수 있는지 여부입니다.

코퍼스는 완전히 합성적이며, 바늘을 건초 더미에서 찾는(needle-in-a-haystack) 스타일입니다:

• 80개의 누출 데이터: 현실적인 혼잡함(직원 채팅 프레임, 붙여넣기 아티팩트, 조정된 상수, 내부 코드명 등)으로 생성된 (독점 코드, 인프라 설정 파일, 내부 산문) 내용으로, 각각은 무해한 기술 텍스트 더미(4k–14k 문자, 평균 약 9.6k) 안에 무작위 라인 경계에 숨겨져 있습니다.
• 140개의 순수 음성 데이터: _어려운 음성 데이터(hard negatives)_에서 구축되었습니다: 오픈 소스 스타일 코드, 공개 문서 튜토리얼, 무해한 인프라 설정 파일, 일상적인 엔지니어링 산문 등, 단순한 분류기가 오탐지를 일으키기 쉬운 바로 그 종류의 텍스트입니다.
• 모든 양성 데이터는 숨겨진 누출 데이터의 문자 범위(char span)를 포함하므로, 이 벤치마크는 단순히 _감지_뿐만 아니라 국소화(localization) (모델이 인용한 범위의 문자 단위 IoU) 점수도 매깁니다.

훔쳐 가볼 만한 두 가지 설계 선택: 어려운 음성 데이터는 누출 데이터를 생성한 _동일한 생성기_에 의해 작성되었으므로(따라서 모델은 작문 스타일을 인식해서 이길 수 없고, 콘텐츠를 이해해야 합니다), 감지는 실제로 전송되는 긴 혼합 페이로드에서 페이로드 수준으로 점수가 매겨지며, 깨끗하게 분리된 스니펫에서는 그렇지 않습니다.

테스트한 모델들

Kaggle 벤치마크를 통한 호스팅 LLM (리더보드: 무료 호스팅 추론, 고정 프롬프트 하나, 모든 모델에 대한 구조화된 판결 {is_leak, quote}):

• google/gemini-2.5-pro 및 google/gemini-2.5-flash: 최첨단 수준
• openai/gpt-oss-120b (117B) 및 openai/gpt-oss-20b (21B): 오픈 가중치 추론 모델

4개 모델 × 220 페이로드 = 총 880회 실행, 879회 점수화됨 (한 응답은 3번의 재시도에도 파싱에 실패함). 이 테스트 스위트는 Kaggle Benchmarks 레지스트리의 현재 카탈로그를 반영하며, 벤치마크 자체는 모델 독립적이므로 새로운 또는 더 큰 모델을 러너(runner)에 추가하여 통합할 수 있습니다.

로컬 엔드포인트 기준점 (kbench 리더보드에는 없음; API가 아닌 노트북에서 실행됨): 512 토큰 창에 대한 로지스틱 헤드(logistic head)를 가진 고정된 all-MiniLM-L6-v2 (22M 파라미터)와, 더 무거운 비교군으로 사용되는 ModernBERT-base (149M) 및 DeBERTa-v3-base (184M)로 구성되어 있으며, 동일한 방식으로 구축된 더 큰 비공개 세트(3,000+ 페이로드, 누출 방지 분할, ≥99% 재현율을 달성하기 위해 캘리브레이션 스플릿에서 고정된 임계값, 각 3개의 헤드 시드)에서 평가되었습니다.

주요 결과 (Findings)

• 동일한 공유 Kaggle CPU VM, INT8 동적 양자화 PyTorch, 각 약 26개의 창을 가진 100개 페이로드; 상대적인 비교로 간주하세요 (실제 노트북에서의 ONNX Runtime은 절대적인 측면에서 몇 배 더 빠릅니다).

로컬 측 스토리 (측정됨, 3개 시드, 2% 유병률 평가):

• 22M 파라미터 임베딩 모델이 149M 및 184M 인코더를 능가하다: 3~5배 낮은 오탐률(window당 오탐률 ~0.3% 대 0.9% / 1.9%)로 숨겨진 유출을 완벽하게 검색했습니다. 대비적으로 학습된 문장 임베딩은 이 작업에 대해 _선형 분리 가능_하지만, 원시 언어 모델 피처는 그렇지 않습니다. 배포 계획이 고정된 인코더 + 작은 헤드(배포하기 저렴하고 재학습 시간이 몇 초)인 경우, 임베딩 튜닝 모델이 파라미터 수보다 훨씬 뛰어난 성능을 발휘합니다.
• DeBERTa-v3는 경고 피로의 교훈: 거의 최고 수준의 검색률(97.5%)을 보였지만, 페이로드 오탐률은 36%에 달했습니다. DLP 분야에서 거짓 알람을 계속 발생시키는 도구는 제거됩니다. 검색률만으로는 잘못된 모델을 선택했을 것입니다.
• 유출을 숨겨도 사라지지 않는다: 14k 문자 길이의 방대한 데이터 속에서 바늘을 찾는 탐지 성능이 독립적으로 같은 유출을 탐지하는 것과 같거나 능가했습니다(희석 정도 ≈ 0에서 모든 모델에 대해 음수). 장문맥 희석은 사람들이 가정하는 실패 모드가 아닙니다.
• 2%의 유병률에서 FDR이 정직한 헤드라인이다: 우승 모델의 거짓 발견 건수가 실제 포착 건수를 능가했습니다(~99% 검색률 임계값 기준, 단 60개의 보정 양성 샘플로 조정된 경우 약 4:1). 임계값은 평가 세트(eval set)가 아닌 보정 분할(calibration split)에서 반드시 조정해야 하며, 알림 정밀도가 5분의 1 대 11분의 1인 차이가 사람들이 신뢰하는 도구와 비활성화시키는 도구를 가릅니다.

LLM 측 이야기 (4개의 호스팅 모델, 879회의 점수화 실행, 단일 고정 프롬프트):

• 모델 클래스별 탐지율 추적: gemini-2.5-pro는 숨겨진 유출을 모두 포착(1.000)했지만, flash는 4%를 놓쳤고(0.962), gpt-oss-120b는 17%(0.825), 21B인 gpt-oss-20b는 4분의 1을 놓쳤다(0.750). 최첨단 모델은 정확도 기준을 넘었지만, 작은 오픈 가중치 추론 모델들은 그렇지 못했다.
• 재현율 우승자는 오탐지률 우승자: gemini-2.5-pro는 깨끗한 난이도 하드 네거티브(hard negatives)의 **39.3%**를 플래그 지정했는데, 이는 DeBERTa-v3의 36%보다 높은 수치로, 로컬 측면에서는 주의가 필요하다. 호스팅되는 모델 중 어느 것도 17.1% 미만으로 떨어지지 않았으며, 로컬 22M 모델은 7.3%로 작동한다(주의: LLM은 하나의 프롬프트에 의해 암시된 운영 지점에 위치하는 반면, 인코더의 임계값은 보류된 분할에서 99% 재현율로 조정된다; 이 비교는 공정성 측면에서 인코더에 유리하며, 그럼에도 불구하고 여전히 우위를 점한다).
• 유출 지점을 가리킬 수 있는 모델은 최첨단 모델뿐: gemini-2.5-pro는 이를 거의 그대로 인용(IoU 0.85)할 수 있지만, flash는 평범하다(0.39). gpt-oss 모델들은 페이로드를 플래그 지정하지만 사용 가능한 전문적인 구절을 생성하지 못한다(0.036–0.060; 엄격한 채점: 의역된 인용은 점수가 0이다). 경고 UI에는 종(bell)뿐만 아니라 구절(span)이 필요하다.

숫자가 뒷받침하는 가설: 호스팅되는 LLM은 재현율의 상한선에 도달하지만, 엔드포인트 계층으로서는 구조적으로 잘못되었다. 모든 모델이 22M 로컬 모델보다 2.3–5.4배 더 많은 오탐지(false-alarms)를 유발하며, 각 페이로드는 네트워크 왕복 시간과 호출당 비용을 소모하고, 이들을 사용한다는 것은 의심되는 정확한 텍스트를 장치 외부로 전송하는 것을 의미하는데, 이는 DLP 제품이 막기 위해 존재하는 행동이다. 로컬에서, 적은 오탐지율로 동등하거나 더 나은 재현율을 달성할 수 있다. 그리고 그 격차는 느낌(vibes)이 아니라 측정된다.

한계점들을 명확히 밝힙니다: 합성 코퍼스(실제 직원 데이터 없음, 설계상); 호스팅 모델의 비율은 단일 실행이며 확률적입니다 (전체 스위트를 반복하면 포착/오탐률이 최대 7pp까지 변동했습니다; 순위는 유지됨); LLM 스위트의 경우 암(arm)당 80/140 페이로드, 인코더의 경우 100개의 평가 유출 데이터가 사용되었습니다 (재현율 CI ±5–8pp); 현지화 점수는 엄격합니다 (문자 그대로의 인용구가 페이로드에 나타나야 함); 인코더 헤드는 고정된 특징(frozen features)에 대한 선형 프로브이며, 이는 하한선일 뿐 최대치는 아닙니다 (미세 조정하면 일부 격차를 메울 가능성이 높음); 인코더 지연 시간은 최적화되지 않은 백엔드를 사용하는 공유 Kaggle CPU VM에서 측정되었습니다 (상대적인 비교만 가능).

나의 벤치마크

Semantic DLP: 데이터 유출 포착하기: 페이로드 세트는 첨부되어 있으며 완전히 합성적이기 때문에 누구나 재실행하거나 모델을 추가하거나 세 가지 작업(leak_catch_rate / stay_silent_rate / locate_leak)을 포크할 수 있습니다. 공개 리더보드는 처음에 플랫폼의 단일 실행 출력을 통해 게시된 모델들을 나열합니다; 전체 4개 모델 스위트 결과는 위 표에 있으며 다음에서 확인 가능합니다: https://www.kaggle.com/code/karthiksethuraman6/leak-catch-rate/output : 요약 파일 dlp_llm_summary.csv와 모든 모델의 원시 실행 기록이 담긴 backup_runs/ 폴더가 모두 있습니다. 보드는 'Add Models'를 통해 확장할 수 있습니다. 재현을 위한 한 가지 주의사항: 추론 모델(gpt-oss)은 출력을 <think> 블록으로 감싸므로, 판정기 파서(verdict parser)는 엄격한 구조화된 출력 파싱을 신뢰하기보다는 원시 응답에서 마지막 JSON 객체를 추출합니다.

다음 단계: 우승 인코더에 대한 스팬 레벨 헤드 추가 (코퍼스는 이미 유출의 정확한 문자를 레이블링했으므로, 분류는 사용 가능한 경고의 절반일 뿐입니다); 2점 정밀도/재현율 곡선을 위한 95% 재현율에서의 두 번째 작동 지점; 조건부 임계값(conformal thresholds); 그리고 코퍼스를 더 많은 유출 카테고리로 확장하는 것입니다.