GitHub, 푸시 시 Anthropic 키 유형 2가지 추가 차단. 아직 놓치고 있는 것은?

• 도서: AI Agents Pocket Guide
• 저자 소개: Thinking in Go (2권 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구로 배포하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

코딩 에이전트가 작업을 완료하고, git add -A로 모든 것을 스테이징한 후 푸시합니다. 이 커밋 어딘가에는 Anthropic API 키가 포함된 .env 파일이 있습니다.

10월 13일 이후 GitHub는 이러한 푸시를 막을 확률이 높아졌습니다. 2026년 10월 13일자 GitHub 변경 로그에 따르면, secret scanning이 이제 두 가지 새로운 Anthropic 비밀 유형인 anthropic_user_api_key와 anthropic_service_api_key를 감지하며, 푸시 보호(push protection)가 기본적으로 이 두 가지 모두를 차단합니다. 해당 항목에 따라, secret scanning이 활성화된 저장소에서는 (무료 공개 저장소를 포함하여) 키가 포함된 커밋은 자동으로 차단됩니다.

이는 실질적인 개선입니다. 하지만 들리는 것보다 범위가 좁습니다. 기본 설정 상태의 비공개(private) 저장소는 여전히 차단되지 않습니다.

GitHub가 10월 13일에 변경한 사항

변경 로그는 세 가지를 통합하고 있습니다:

• Anthropic의 새로운 탐지기 두 가지(anthropic_user_api_key 및 anthropic_service_api_key)와 Cloudsmith API 키 탐지기가 추가되었습니다.
• Salesforce가 비밀 스캐닝 파트너로 합류하여 Marketing Cloud API OAuth2 토큰을 지원합니다. 공개 저장소에서 발견된 파트너의 비밀 정보는 발급자에게 전송되어 해당 정보를 폐기하거나 순환(rotate)할 수 있도록 합니다.
• 새로운 Anthropic 유형 두 가지 모두 기본적으로 푸시 보호가 차단하는 목록에 추가되었습니다.

이 항목에는 또한 이러한 탐지기가 비밀 스캐닝이 활성화된 공개 또는 비공개 저장소에서 알림으로 표시된다고 명시되어 있습니다.

Anthropic은 이 프로그램에 처음 참여한 것이 아닙니다. GitHub는 2024년 8월 20일 Anthropic을 비밀 스캐닝 파트너로 발표했으며, GitHub의 지원 패턴 테이블에는 이미 anthropic_api_key, anthropic_admin_api_key, 그리고 anthropic_session_id가 나열되어 있습니다. 키가 공개 저장소에 유출될 경우, Anthropic의 키 보안 문서는

GitHub의 patterns table에는 두 감지기 이름이 'Anthropic User API Key'와 'Anthropic Service Account API Key'로 되어 있습니다. 제가 이해하기로는, 'user'는 Anthropic에서 개인 키라고 부르는 것을 의미하는 것 같습니다. 어느 쪽도 명시하고 있지는 않습니다.

A git push arrow stopped at a gate by a burnt orange shield, with a small key icon caught in the gate
푸시 보호 기능은 커밋이 GitHub에 도달하기 전에 막습니다. 키는 여전히 로컬 히스토리에 있습니다.

차단(block)이란 무엇이며, 누가 이를 우회할 수 있는가

GitHub의 push protection docs에는 적용되는 곳이 나열되어 있습니다: 명령줄 푸시(command-line pushes), GitHub UI에서 생성된 커밋, 파일 업로드, REST API 요청, 그리고 공개 저장소에 대한 GitHub MCP 서버 상호작용입니다. 마지막 항목은 에이전트가 git을 통하지 않고 GitHub MCP server를 통해 GitHub에 작성하는 경우 중요합니다.

차단은 벽이 아닙니다. 같은 문서에는 기본적으로 '저장소에 쓰기 접근 권한만 있는 사람은 우회 이유(bypass reason)를 지정하여 푸시 보호 기능을 무시할 수 있다'고 나와 있습니다. 저장소 푸시 보호 기능이 켜져 있을 때, 선택하는 이유는 경고가 어떻게 처리될지 결정합니다:

• '테스트에 사용됨(It's used in tests)'은 테스트에 사용된 것으로 간주하여 경고를 닫습니다.
• '오탐임(It's a false positive)'은 오탐으로 간주하여 경고를 닫습니다.
• '나중에 수정할 예정임(I'll fix it later)'은 경고를 열어둡니다.

이 모드에서 각 우회는 감사 로그(audit log)에 추가되고, 해당 저장소를 감시하는 소유자, 보안 관리자 및 저장소 관리자에게 이메일로 전송됩니다. 사용자 기본 푸시 보호 기능만 있는 경우, 문서는 푸시 보호가 저장소 수준에서도 활성화되지 않는 한

사용자의 에이전트는 일반적으로 사용자의 git 자격 증명으로 푸시하므로, 차단된 키를 통과시킬 수 있는 사람은 사용자 본인이거나 해당 자격 증명을 사용하는 어떤 주체입니다. 리포지토리 푸시 보호 기능이 활성화되어 있다면, 에이전트 브랜치에서 알림을 받기 전에 우회 이유(bypass reason)를 읽어보세요.

블록되었다는 것은 또한 그 키가 이미 로컬 커밋에 있다는 것을 의미합니다. 푸시 보호 기능은 GitHub에서 이를 막았을 뿐, 사용자의 브랜치에서 제거한 것이 아닙니다.

적용되지 않는 경우

푸시 보호 문서에서는 두 가지 종류를 설명하며, 이들은 서로 다른 리포지토리를 다룹니다:

• **사용자용 푸시 보호(Push protection for users)**는 기본적으로 활성화되어 있으며

Git에서 API 키가 평문으로 존재하는 곳은 여기뿐만이 아닙니다. 만약 터미널에 export ANTHROPIC_API_KEY=...를 입력한 적이 있다면, 그 내용은 셸 히스토리(shell history)에 남아 있습니다. 저는 Hermes IDE를 개발했기 때문에 이 점을 염두에 두고 말씀드립니다: Hermes 2.3.2는 10월 13일에 출시되었으며, API 키, 토큰 또는 비밀번호가 포함된 명령어에 대한 터미널 제안 기능을 더 이상 제공하지 않습니다. 사용자의 셸 히스토리 파일은 그대로 남아 있으므로, 정리하는 것은 사용자 본인의 몫입니다. Hermes는 GitHub나 Anthropic과 관련이 없습니다.

이번 주에 해야 할 세 가지 일

1. 가능한 곳에서 저장소 푸시 보호(repository push protection)를 활성화하세요. 조직에 GitHub Secret Protection 기능이 있다면, 조직 수준에서 푸시 보호 기능을 활성화해야 합니다. 문서에 따르면, 누군가 조치를 취하기 전까지는 비활성화 상태로 유지됩니다.

2. 에이전트와 CI(Continuous Integration)에 별도의 키를 부여하세요. Anthropic의 문서에서는

저는 Hermes IDE를 구축했습니다. 이 IDE는 Claude Code, Codex 및 기타 에이전트들을 나란히 실행하며, 각 작업은 자체 브랜치와 워크트리에서 처리됩니다. macOS, Windows, Linux 환경에서 무료로 사용 가능하며 소스 코드가 공개되어 있습니다 (BSL 1.1). 이것이 유용하게 들린다면, GitHub에서 별표를 눌러주세요. 만약 자격 증명(credentials)을 다루는 에이전트를 구축하고 있다면, AI Agents Pocket Guide가 관련 가드레일 패턴들을 다루고 있습니다.

AI Agents Pocket Guide: Patterns for Building Autonomous Systems with LLMs