Dev loop 의 LLM 이 시크릿 위험에 빠뜨리는 5가지 다른 방법. 벡터 아는 게 방어의 절반.
1. 직접 파일 읽기
Agent 가 Read 도구 가짐. "내 deploy 어떻게 생겼어?" 물음. Agent 가 context 위해 docker-compose.yml + .env 읽음. .env 내용이 이제 모델 context window 에 — 즉 API 요청에 — 즉 네 컨트롤 밖 서버에.
2. 도움 되는 echo
Stack trace 붙여넣음. trace 에 비밀번호 박힌 connection string 포함. 모델이 에러 요약: "Postgres at postgres://app:HUNTER2@db.internal:5432/prod 가 connection 거부합니다". 이제 비밀번호가 채팅 transcript 에.
3. Reasoning-trace 누출
최근 reasoning 모델 (o-series, Claude thinking, DeepSeek R1, Gemini Thinking 등) 이 종종 *thinking* 블록 생성. 그 블록은 사용자한테 보이거나, 가끔 숨겨지거나, 가끔 별도 로그. 많은 제품이 billing/QA 위해 trace 를 upstream 으로 보냄. 모델이 "비밀번호가 HUNTER2 라고 공개하면 안 된다" 생각하면 그 정확한 문자열이 이제 trace 에.
4. 하드코딩하는 제안 코드
"DB 연결하는 스크립트" 요청. 모델이 도움 되게 방금 context 에서 본 비밀번호 채워. 제안 받아들임. 이제 시크릿이 commit 된 코드에, 디스크에, (git 히스토리는 영원하니까) repo 의 영구 기록에.
5. Cross-conversation bleed (memory 기능)
최근 assistant 의 "Memory" 기능이 session 가로질러 fact 를 persist. Session A 가 (.env 읽기로) API key 학습하면 session B 가 가끔 recall 가능.
| 벡터 | 시크릿이 끝나는 곳 | cleanup 가장 어려운 부분 |
|---|---|---|
| 직접 파일 읽기 | API 요청, provider 로그, 가능하면 훈련 데이터 | 삭제 완전히 증명 못 함 |
| 도움 되는 echo | 채팅 transcript, 스크린샷, 공유 | 분배 통제 불가 |
| Reasoning trace | Trace 로그, billing 시스템 | 사용자한테 종종 invisible |
| 제안에 하드코딩 | 네 repo, git 히스토리, deploy artifact | Git 히스토리 rewrite 는 고통스럽고 부분적 |
| Memory bleed | provider 의 persistent memory store | audit 어렵고 선택적 purge 어려움 |