API 키 노출 점검: AI 에이전트가 5분 만에 쓰는 비밀정보, 교체·폐기 순서 [2026]

Microsoft는 11월 5일, 공격자가 에이전트형 AI 공격 도구(ARTEX)로 공개 GitHub 저장소에서 키와 비밀번호를 찾아 바로 클라우드 침입에 쓰고 있다고 발표했습니다. 한 사례에서는 GitHub 검색에서 Azure Key Vault 데이터 반출까지 5분이 걸렸습니다.

같은 주에 보안 기업 Apiiro는 Anthropic의 AI 코딩 도구가 승인한 명령을 비밀번호째 프로젝트 설정 파일에 저장한다고 밝혔습니다. 공개 GitHub에 올라온 이 설정 파일 1,122개에서 실제 비밀정보 1,379건이 나왔고, 에이전트 대화 기록·메모리 파일·git 과거 기록까지 합하면 저장소 1,994곳에서 2,539건이었습니다.

이 글은 두 발표를 묶어 봅니다. 키가 어디서 새고, 공격자가 그 키를 얼마나 빨리 쓰며, 우리 회사가 오늘부터 무엇을 어떤 순서로 해야 하는지 다룹니다. 핵심은 하나입니다. 공개된 적 있는 키는 지운 것만으로 끝나지 않습니다. 먼저 바꾸고(교체), 옛 키를 끊고(폐기), 그다음 정리합니다.

한눈에 보기

항목	내용
무엇이 일어났나	공격자가 에이전트형 AI 공격 프레임워크로 공개 저장소의 비밀정보를 대량 검색하고, 찾은 키로 로그인해 클라우드 자원을 조회·반출
언제부터	2026년 8월부터 GitHub 대량 검색 관측. 10월 28일부터 유출된 앱 자격증명으로 Entra ID 로그인 성공 관측(Microsoft)
속도	한 사례에서 GitHub 비밀정보 검색부터 Azure Key Vault 데이터 반출까지 5분
노린 것	앱 자격증명(client secret), AI 서비스 API 키, 스토리지 계정 키, 연결 문자열, 배포 자격증명, Kubernetes 자격증명
또 다른 유출 경로	AI 코딩 도구에서 "Yes, and don't ask again"을 고르면 명령 전체가 프로젝트 안 로컬 설정 파일(settings.local.json)에 저장. 공개 사본 104,185개 중 1,122개에 실제 비밀정보(Apiiro)
일반 스캐너의 빈틈	비밀정보가 든 1,122개 파일 중 gitleaks 564개, TruffleHog 643개만 탐지. 215개는 둘 다 놓침
기업이 할 일	노출 범위 확인 → 키 교체 → 옛 키 폐기·세션 끊기 → 사용 기록 조사 → 저장소 정리와 재발 방지

무엇이 일어났나: 찾는 데 5분, 쓰는 데도 몇 분

Microsoft 발표(11월 5일)

Microsoft 위협 인텔리전스는 2026년 8월부터 공격자가 에이전트형 AI 공격 프레임워크로 GitHub에 비밀정보 검색 질의를 대량으로 보내는 것을 관측했다고 밝혔습니다. 에이전트형 AI란 사람이 한 단계씩 지시하지 않아도 목표를 받아 스스로 도구를 고르고 다음 행동을 정하는 AI를 말합니다. 질의에는 대상 회사 이름, 비밀정보 관련 단어, 클라우드 서비스 이름, 다른 AI 서비스 공급자 이름이 섞여 있었습니다.

예전에는 저장소를 찾고 읽고 키를 써 보는 데 사람 손이 많이 들었습니다. Microsoft는 ARTEX 같은 도구가 검색, 결과 분석, 후속 공격까지 이어서 해 사람 손을 크게 줄인다고 설명합니다. 그 결과가 '검색에서 Key Vault 반출까지 5분'입니다.

10월 28일부터는 유출되거나 탈취된 앱 자격증명으로 여러 조직의 Microsoft Entra ID(구 Azure AD)에 로그인하는 활동이 확인됐습니다. 판매 회사가 만든 멀티테넌트 앱(여러 고객사 환경에 함께 설치되는 앱)의 자격증명이 원천에서 털려 고객사 여러 곳으로 이어진 경우도 있었습니다. 공격자가 한 일은 다음과 같습니다.

구독, 리소스 그룹, 권한, AI 모델 배포 현황을 조회해 환경 지도를 만들었다.
스토리지 계정 키, App Service 설정, 연결 문자열, 배포 자격증명, AKS(Azure Kubernetes Service) 자격증명처럼 '또 다른 자격증명을 돌려주는' 기능을 노렸다.
SharePoint·OneDrive 파일을 내려받고 메일함 항목에 접근했다.
Azure DevOps에서 또 비밀정보를 찾았고, 가상머신에서 스크립트를 실행하는 Run Command 기능도 썼다.
탈취한 Azure AI 서비스가 작동하는지 확인했다.

눈여겨볼 대목은 '스스로 고치는' 행동입니다. Key Vault 조회 요청이 잘못된 API 버전 때문에 400 오류를 받자 약 28초 뒤 올바른 버전으로 다시 보내 성공했습니다. 다른 요청에서도 약 60초, 80초 만에 같은 방식으로 고쳤습니다. 오류를 만나도 1분 안팎에 스스로 고쳐 다시 시도한다는 뜻입니다. 방어하는 쪽이 '키가 공개된 걸 알았으니 다음 주에 바꾸자'고 하면 이미 늦을 수 있다는 뜻입니다.

Microsoft는 AI 에이전트가 특히 주요 AI 서비스 공급자의 API 키와 Azure AI 계열 서비스에 접근하는 앱 자격증명에 집중했다고 적었습니다.

Todyl 관측(11월 3일 첫 공개, 11월 6일 갱신)

보안 관제 기업 Todyl은 같은 공격 주소에서 11월 1일부터 시작된 활동을 따로 보고했습니다. 약 18개 조직의 앱 등록 약 45개가 표적이 됐고 그중 33개 넘게 로그인에 성공했습니다. 이 앱을 통해 관리 서비스 업체(MSP)의 고객사까지 27개 조직에 닿았고, 약 25개 테넌트에서 검색, 파일 81개 다운로드, 메일함 항목 약 2,279건 접근이 있었습니다. Todyl은 Microsoft 제품의 취약점은 쓰이지 않았다고 밝혔습니다. 문은 부서진 게 아니라 유효한 열쇠로 열렸습니다.

Apiiro 연구(11월 5일 공개, 11월 8일 갱신)

11월 5일 공개된 Apiiro 연구는 키가 새는 경로 하나를 구체적으로 보여 줍니다. 이 연구는 위 공격 사건과 별개이며, Microsoft는 ARTEX가 찾은 키가 어떤 파일에서 나왔는지 밝히지 않았습니다.

Anthropic의 AI 코딩 도구는 셸 명령을 실행하기 전에 사용자에게 묻습니다. 이때 "Yes, and don't ask again"을 고르면 그 명령을 허용 규칙으로 .claude/settings.local.json에 저장합니다. 명령에 비밀번호나 토큰이 들어 있었다면 그 값도 그대로 저장됩니다. 공식 문서에 따르면 도구는 이 파일을 처음 만들 때 사용자 PC의 전역 git 제외 목록에 추가해 커밋되지 않게 합니다. 그러나 Apiiro는 이 보호가 그 PC 한 대에만 적용되고 프로젝트의 .gitignore에는 들어가지 않으며, 이미 커밋된 파일에는 효과가 없다고 지적합니다. 공식 문서도 파일을 직접 만들었다면 .gitignore에 스스로 추가하라고 안내합니다.

Apiiro가 11월 1일부터 3일까지 공개 GitHub를 검색한 결과는 다음과 같습니다.

항목	수치
공개된 `settings.local.json` 사본	104,185개(저장소 103,617곳)
실제 비밀정보가 든 파일	1,122개(약 1.1%), 서로 다른 비밀정보 1,379건
비밀정보 종류	데이터베이스 비밀번호 379건, Supabase 서비스 키 122건, Supabase 계정 토큰 103건, SSH 로그인 43건, GitHub·GitLab·npm 토큰 42건, AWS 키 23건, 개인키 6건
방치 기간	11월 2일 기준 전부 기본 브랜치에 남아 있음. 중앙값 217일, 118곳은 1년 넘게
지운 뒤에도 남은 것	과거 버전에만 남은 비밀정보 734건(저장소 509곳), 포크 211개(원본 74곳)에 같은 비밀정보
다른 파일	팀이 일부러 커밋하는 공유 설정 파일 76,011개 중 298개, 에이전트 대화 기록 120개(저장소 87곳), 에이전트 메모리 파일 9곳, 작업 인수인계 메모 33개, VS Code Copilot 자동 승인 설정 9곳
합계	서로 다른 실제 비밀정보 2,539건, 저장소 1,994곳
피해 조직	63곳. 데이터베이스 업체의 관리 권한 클라우드 키, 의료기록 앱 데이터베이스 소유자 비밀번호 등

여기서 '실제 비밀정보'는 알려진 키 형식과 맞거나 공개 서버 주소 옆에 붙은 비밀번호·토큰을 뜻합니다. Apiiro는 어떤 키도 직접 써 보지 않았다고 밝혔습니다. 다만 연락을 받은 한 조직은 자기 키가 살아 있었다고 확인했습니다.

허용 목록이 길수록 위험도 컸습니다. 8KB가 넘는 파일은 10개 중 1개에 비밀정보가 있었고, 500바이트 미만은 500개 중 1개도 안 됐습니다. '다시 묻지 않기'를 오래 눌러 온 프로젝트일수록 많이 쌓인다는 뜻입니다. Apiiro는 문서를 비교한 코딩 에이전트 16종 중 승인한 명령 전체를 기본으로 프로젝트 파일에 쓰는 것이 확인된 도구는 이 하나뿐이라고 했습니다.

Apiiro에 따르면 Anthropic의 해당 도구 책임자는 11월 7일 Hacker News에서 "막을 방법을 살펴보고 있다"며 자동 모드에서 이를 잡아내는 방법과 기본 비밀정보 검사 기능을 시험해 보겠다고 답했습니다. 같은 동작은 2025년 8월부터 GitHub 이슈로 여러 번 보고됐습니다.

일반 스캐너가 놓치는 이유

비밀정보 스캐너는 대개 'AKIA로 시작하는 20자'처럼 알려진 키 모양을 찾습니다. 그런데 명령 안에 쓴 비밀번호는 모양이 없습니다. PGPASSWORD= 뒤나 mysql -p 뒤에 붙은 단어는 스캐너 눈에 평범한 명령어 한 줄입니다. 그래서 1,122개 파일 중 215개를 두 도구 모두 놓쳤습니다. 스캐너를 돌렸으니 안전하다고 결론 내리기 전에, 우리 스캐너가 명령 속 비밀번호도 보는지 확인해야 합니다.

왜 우리 회사 문제인가

공격 속도가 사람 대응 속도를 앞질렀습니다. 검색에서 반출까지 5분이면, 키가 공개된 뒤 '다음 정기 점검'까지 기다릴 여유가 없습니다.
지워도 남습니다. Microsoft는 공개됐던 자격증명은 원본을 고치거나 지웠어도 탈취된 것으로 보라고 권고합니다. git 과거 기록, 포크, 캐시, 보관본에 사본이 남기 때문입니다.
AI 키가 표적입니다. 공격자는 AI 서비스 키를 특히 노렸습니다. 요금 폭탄뿐 아니라 연결된 데이터와 다른 자격증명으로 이어질 수 있습니다.
협력사 키가 우리 문을 엽니다. 판매사 앱이나 MSP의 자격증명 하나로 고객사 여러 곳에 들어간 사례가 이미 나왔습니다.
AI 코딩 도구를 쓰는 팀이면 새 경로가 생겼습니다. 개발자 PC의 에이전트 설정 폴더, 대화 기록, 메모리 파일이 .env 파일과 같은 수준의 비밀정보 보관 장소가 됐습니다.

우리 회사에 해당하는지 확인하는 법

아래 표에서 하나라도 '예'면 대응 순서로 넘어갑니다.

확인할 것	어떻게 보나	'예'일 때 뜻
회사 GitHub·GitLab 조직에 에이전트 설정 파일이 있나	조직 단위 코드 검색으로 `.claude/settings.local.json`, `.claude/settings.json`, `.gemini/`, `.specstory/` 같은 에이전트 폴더를 찾는다	지금 누구나 읽을 수 있는 파일일 수 있다
지금은 없어도 예전에 커밋된 적 있나	저장소마다 git 기록에서 해당 파일 경로의 변경 이력을 본다	포크와 복제본에도 같은 내용이 있다
파일 안에 비밀정보가 있나	허용 목록의 각 줄에서 비밀번호, 토큰, 연결 문자열, `PGPASSWORD=`, `sshpass -p`, `mysql -p`, 인증 헤더를 찾는다	교체 대상
개인 공개 저장소에 회사 키가 있나	직원 개인 계정, 외주 개발사 저장소, 데모·교육용 저장소를 함께 본다	회사 저장소만 보면 놓친다
저장소 밖으로 나간 사본이 있나	배포한 npm 패키지, Docker 이미지, 압축 파일, 공유 폴더 안에 에이전트 설정 폴더가 들어갔는지 본다	git 정리만으로는 회수되지 않는다
이미 누가 시도했나	Entra ID 서비스 주체(앱이 로그인할 때 쓰는 신원) 로그인 기록에서 AADSTS7000215(잘못된 비밀), AADSTS7000222(만료된 비밀) 오류를 찾고, 출발지가 아래 공개 공격 주소이거나 평소와 다른 곳인지 본다	정상 앱의 설정 오류나 키 만료로도 생기는 오류다. 낯선 출발지와 겹치면 시도 신호로 보고, 실패 뒤 성공이 있으면 긴급
한 주소가 여러 앱으로 로그인했나	한 IP가 서비스 주체 3개 이상에 성공·실패가 섞여 로그인했는지, 한 앱이 짧은 시간에 ARM·Key Vault·Storage·Graph 토큰을 연달아 받았는지 본다	Microsoft가 제시한 행동 신호

Microsoft가 밝힌 공격 주소는 199.19.77[.]84, 199.19.77[.]18, 65.87.223[.]26, 157.22.126[.]128입니다. 이 중 199.19.77[.]18은 Tor 출구 노드라 무관한 트래픽도 섞일 수 있습니다. 공격자는 주소와 User-Agent를 쉽게 바꾸므로 주소 검색은 출발점일 뿐입니다. 로그가 남아 있는 가장 이른 시점부터 찾습니다.

대응 순서

오늘

공개 저장소와 git 기록에서 찾은 비밀정보를 목록으로 만든다. 값 자체를 공유 문서에 붙여 넣지 말고, 어느 서비스의 어느 키인지와 위치만 적는다.
공개 서버 주소와 짝을 이룬 비밀번호, 데이터베이스 비밀번호, 클라우드 키, AI 서비스 키부터 교체한다. Apiiro는 공개 서버와 짝을 이룬 자격증명이 실제 접근을 주므로 먼저 처리하라고 권합니다.
교체 뒤 옛 키를 폐기한다. 새 키 발급만 하고 옛 키를 살려 두면 공격자는 계속 씁니다. Entra 앱이면 client secret, 인증서, 페더레이션 자격증명을 지우고 필요하면 서비스 주체를 끈다. Microsoft는 이미 발급된 토큰은 만료 전까지 유효하다고 적었습니다.
영향받은 사용자의 세션, Azure DevOps 개인 접근 토큰(PAT), SSH 키를 끊는다.
침입 흔적이 보이면 해당 앱이 읽을 수 있던 Key Vault 안의 비밀정보 전부와, 접근된 문서 속 자격증명까지 교체 범위를 넓힌다.

이번 주

앱 로그인 기록, Azure 활동 로그, Key Vault·Storage 진단 로그, Entra 감사 로그, Microsoft 365 통합 감사 로그를 확인한다. 비밀 조회, 파일 다운로드, 앱·권한·파이프라인 변경을 본다.
추적 중인 에이전트 설정 파일을 git 추적에서 뺀다(git rm --cached 후 프로젝트 .gitignore에 추가). 정리는 교체 다음이다. 순서를 바꾸면 '지웠으니 됐다'는 착각이 생긴다.
개발자 PC에서 커밋한 적 없는 설정 파일도 열어 비밀정보가 든 허용 규칙을 지운다. 이 파일은 평문 JSON이라 PC를 노리는 악성코드가 그대로 읽을 수 있다.
MSP나 외주 개발사가 우리 테넌트에 접근하는 앱이 있다면 그쪽에도 같은 점검을 요청하고 결과를 받는다.

이번 달

명령에 비밀번호를 직접 쓰지 않게 한다. 비밀정보 관리 도구에서 $DB_URL 같은 변수로 불러오면 저장되는 규칙에는 변수 이름만 남는다.
에이전트 승인은 한 줄짜리 명령 대신 Bash(npm run:*) 같은 패턴으로 준다.
회사 .gitignore 템플릿에 에이전트 로컬 설정 파일을 넣고, 커밋 전 검사와 CI 비밀정보 검사에 에이전트 폴더와 git 기록을 포함한다. 알려진 키 모양뿐 아니라 명령 속 비밀번호를 잡는지 시험한다.
GitHub 비밀정보 검사(secret scanning)와 푸시 보호(push protection)를 켠다. Azure DevOps라면 해당 보안 기능을 켠다.
오래 쓰는 client secret을 줄인다. Microsoft는 가능하면 관리 ID(managed identity)로 옮기라고 권합니다. 코드에 비밀이 없으면 샐 것도 없습니다.
서비스 주체 권한을 업무에 필요한 범위로 줄이고, 앱 등록 권한을 일부 관리자로 제한한다. 백업·복구 자원 접근도 좁힌다.
키마다 담당자, 발급일, 교체 주기, 폐기 절차를 적은 대장을 만든다. 다음 노출 때 '이 키가 어디에 쓰이는지 몰라서 못 바꾸는' 상황을 막는다.

순서가 중요한 이유 저장소에서 파일부터 지우면 화면에서는 사라지지만 키는 그대로 살아 있습니다. 공격자는 이미 사본을 가졌을 수 있고, git 기록과 포크에도 남습니다. 교체 → 폐기 → 조사 → 정리 순서를 지켜야 지운 뒤에도 안전합니다.

자가점검

1. 회사 저장소에서 에이전트 설정 폴더를 검색해 봤는가

현재 파일뿐 아니라 git 기록까지 봤는지 확인합니다. 지운 파일도 기록과 포크에 남습니다.

2. 우리 비밀정보 스캐너는 명령 속 비밀번호를 잡는가

PGPASSWORD=, sshpass -p, mysql -p를 넣은 시험 파일로 직접 돌려 봅니다. 놓치면 규칙을 추가합니다.

3. 노출된 키를 지우기 전에 바꿨는가

교체와 옛 키 폐기를 마친 뒤에 저장소를 정리했는지 봅니다. 지우기만 했다면 그 키는 아직 유효할 수 있습니다.

4. AI 서비스 키도 교체 대상에 넣었는가

공격자는 AI 서비스 키를 특히 노렸습니다. 사용량과 결제 내역에 낯선 급증이 없는지도 함께 봅니다.

5. 앱 로그인 실패 기록을 봤는가

AADSTS7000215, AADSTS7000222 오류는 정상 앱의 설정 오류나 키 만료로도 생깁니다. 출발지가 낯선 IP이거나 Microsoft가 공개한 공격 주소와 겹치면 시도 신호로 보고, 실패 뒤 성공이 있으면 바로 대응합니다.

6. 협력사가 가진 우리 키를 알고 있는가

MSP, 외주 개발사, 판매사 앱이 우리 테넌트에 접근하는 자격증명 목록과 담당자가 있는지 확인합니다.

7. 개발자에게 비밀정보를 명령에 직접 넣지 말라고 안내했는가

변수로 불러오는 방법과 패턴 승인 방법을 팀 규칙으로 정했는지 봅니다.

8. 키 대장에 교체 담당자와 절차가 있는가

키 하나를 바꾸는 데 몇 시간이 걸리는지 실제로 재 봅니다. 5분 만에 쓰이는 키를 며칠 걸려 바꾸면 순서가 의미를 잃습니다.

노출된 키가 어디까지 닿는지 확인하기

공개 저장소의 키 검색과 교체는 회사 안에서 바로 시작할 수 있습니다. 어려운 부분은 그다음입니다. 새어 나간 키 하나로 어떤 API를 부를 수 있고, 그 권한으로 어떤 데이터와 다른 자격증명까지 이어지는지는 실제 서비스 구조를 보고 판단해야 합니다. 보안 전문 기업 SENTRIX는 레드팀을 운영하며 보안 실무 10년의 경험을 쌓았고, 수상 이력은 2025 식약처 주최 AI 레드팀 챌린지 최우수상(구성원)입니다. AI 모의해킹·AI 심화 취약점 진단에서는 AI 자동화와 전문가 검증으로 웹·API의 권한, 비즈니스 로직, 연쇄 공격 경로를 확인하고 LLM·AI 서비스 자체의 보안도 검증합니다. 기업은 웹 서비스 1개에 대해 AI 웹진단 1회를 무료로 받을 수 있고, 조건은 AI 모의해킹·AI 심화 취약점 진단 페이지에 있습니다. 인터넷에 공개된 우리 회사 웹사이트·서버와 사칭 사이트를 찾아 담당자·조치·재확인까지 관리하는 외부 노출·위험 관리(ASM)도 함께 운영합니다. 로그에서 낯선 앱 로그인이나 데이터 반출 흔적이 이미 보인다면 침해사고 진단 문의하기로 바로 연락하십시오. 권한과 공격 경로 점검의 범위와 일정은 진단 문의하기에서 정합니다.

참고 자료

AI 코딩 보안 API 키 노출 AI 에이전트 공격 비밀정보 유출 키 교체 GitHub 시크릿 노출 Entra ID 앱 자격증명 전체 태그 →

노출된 키가 어디까지 닿는지 진단받기

보안 실무 10년 전문가가 기업 환경에 맞는 방안을 제시합니다.

진단 문의하기