AI 에이전트 개발 환경에 비밀 정보 유출 게이트를 직접 만들고 2주간 운영한 결과, 오경보가 없었습니다

AI 코딩 에이전트에게 개발을 맡기게 되면, 커밋이 사람이 따라잡을 수 없는 속도로 쌓입니다. 필자의 환경에서는 동시에 작동하는 여러 에이전트 세션이 30일 만에 340개 이상의 커밋을 쌓았습니다.

이 상황에서 가장 무서운 것은 코드의 품질이나 버그가 아니라, **'실수로 비밀 정보(API 키, 토큰)를 공개 리포지토리에 push하는 것'**입니다. 한번 공개되면 봇이 몇 분 만에 수집하여 악용하기 때문에 삭제로는 역부족입니다.

사람의 눈으로 리뷰하는 것은 물리적으로 불가능하므로, 공개 직전에 자동으로 막아주는 문지기(게이트)를 직접 만들었습니다. 이 글은 그 설계와 2주간의 운영 실적 기록입니다.

'막아야 할 것은 확실히 막고, 불필요하게는 막지 않는다.' — 이것이 수치로 확인되었기 때문에, 본 운영에 승격시켜 키트 형태로 공개했습니다.

'하나의 강력한 탐지'에 의존하기보다, 3가지 역할을 분담시키는 구성으로 했습니다.

[Layer 1] pre-push hook …… 공개 직전 관문 (막는 역할)
[Layer 2] GitHub Actions CI … 뒷문 대비책 (Layer 1을 우회한 push도 매주 전체 이력을 검색)
[Layer 3] 사람의 리뷰 …… 문맥 판정 위임처 ('이것은 테스트용 더미인가?'는 기계가 판단하지 않도록)

git push
직전에 작동하며, push하려는 차이점(diff)만을 검색합니다 (과거 전체 이력을 보지 않기 때문에 예전의 더미 데이터로 오작동하지 않습니다).

탐지기는 다음 2종류입니다.

gitleaks(유명한 OSS) — 수백 종류의 알려진 패턴으로 '실제 키와 유사한 형태'를 탐지 -
직접 만든 단순 패턴 — `token =

Linux (WSL2)에서는 완벽하게 작동했던 키트가 Windows에서는 5가지 문제로 인해 작동하지 않았습니다. 같은 고민을 가진 분들을 위해, 해결책을 남겨둡니다:

(개발 과정에서 구현 실수로 '존재하는 gitleaks까지 .exe로 덮어쓰는' 버그도 만들었지만, 테스트가 실제 동작에서 이를 포착해 주었습니다. 테스트를 작성해 두면 손해가 아닙니다)

(정규 표현식의 단어 경계 문제나 CI 단계의 gitleaks는 잡아낼 가능성이 있습니다). 문맥 판별을 넣지 않은 설계 방침의 대가로, 솔직하게 README에 적습니다. token2 = ...와 같은 접미사(suffix)가 붙은 변수명은 단순 패턴 단계를 통과합니다 - hook만으로는 --no-verify로 우회할 수 있습니다 (최종 방어선은 CI 측).

• AI 에이전트가 대량으로 커밋하는 환경에서는, 비밀 정보의 실수 유출은 '발생을 전제'로 대비해야 합니다.
• 탐지는 하나의 강력한 도구만으로는 부족하며,
  **hook (차단) + CI (백도어) + 인간 (문맥)**의 3단계 분담이 현실적입니다. - 도입하고 끝내는 것이 아니라,
  2주간의 운영 데이터(진양성 5건・오경보 0건)로 효과가 있음을 수치로 확인한 후에 본 운영 단계로 승격했습니다.

키트는 여기에서 이용하실 수 있습니다. issue / PR도 환영합니다.

※ 이 글 자체도, 공개 전에 기사 본문에 대한 민감 정보 스캔(gitleaks)을 거쳤습니다. 게이트에 대해 이야기하는 글이 게이트를 빠져나가면 웃을 수 없기 때문입니다.

본 기사는 개인 Zenn에서도 공개했습니다.