공격 에이전트는 금고까지 5분이었다(Microsoft 공개 사례): 작은 회사의 열쇠 점검 2주

AI 에이전트에게 일을 맡기기 전에 회사가 먼저 할 일은 API 키, 토큰, OAuth 허용 같은 열쇠가 몇 개이고 누구 것이며 얼마나 빨리 회수되는지 세어 보는 일입니다. 2026년 11월 5일 Microsoft는 공격자가 에이전트형 도구 ARTEX로 공개 GitHub 저장소에서 노출된 비밀값을 찾고 있다고 밝혔고, 한 사례에서는 GitHub에서 클라이언트 시크릿을 찾기 시작해 Azure Key Vault에서 데이터를 빼내기까지 5분이 걸렸습니다. 그래서 LeanX는 열쇠 장부를 만드는 데서 시작해 회수 시간을 재 보는 데서 끝나는 2주 점검을 제안합니다.

그림 1. 공개된 사고와 발표 여섯 가지를 열쇠의 눈으로 다시 모은 포스터. 날짜와 출처는 본문에 다시 적었습니다.

직원이 열 명인 회사를 떠올려 보세요. 개발자가 급하게 올린 저장소에 클라우드 클라이언트 시크릿이 한 줄 들어 있고, 그걸 아무도 기억하지 못합니다(예시이고, 실제 고객 사례가 아닙니다). 예전에는 누군가 그 저장소를 우연히 열어 봐야 사고가 났어요. 이제는 열쇠만 찾으러 다니는 프로그램이 있습니다.

공격 에이전트는 열쇠를 찾는 데 얼마나 걸렸나요?

한 사례에서 5분이었습니다. Microsoft Security 블로그(2026년 11월 5일)에 따르면 ARTEX는 공개 GitHub 저장소에서 노출된 비밀값을 검색하는 에이전트형 공격 프레임워크이고, 쓴 사람은 신원이 밝혀지지 않았습니다. Microsoft가 든 예는 에이전트가 GitHub에서 클라이언트 시크릿을 찾기 시작해 Azure Key Vault에서 데이터를 빼내기까지 5분 만에 진행한 경우입니다.

찾아낸 비밀값은 종류가 다양했습니다. 애플리케이션 자격 증명, AI 추론 API 키, 스토리지 계정 키, App Service 설정과 연결 문자열, 게시 자격 증명, AKS 사용자 자격 증명이 나옵니다. 악용된 자원도 Key Vault와 스토리지에 그치지 않고 Azure AI 서비스, SharePoint와 OneDrive, 가상 머신, Azure DevOps까지 이어졌습니다.

여기서 두 가지를 구분해야 합니다. 이 사건에서 에이전트를 쓴 쪽은 공격자입니다. 우리가 쓰는 에이전트의 열쇠가 털린 사례는 이번 자료에 없습니다. 5분은 Microsoft가 적은 한 사례의 시간이라서, 모든 침해가 이렇게 빠르다는 뜻으로 읽으면 안 됩니다. 그래도 노출된 열쇠가 하나 있으면 그 열쇠로 어디까지 열리는지를 프로그램이 분 단위로 확인한다는 점은 달라지지 않습니다.

Microsoft의 권고는 단순해요. 노출된 자격 증명을 즉시 교체하고, 서비스 주체(애플리케이션용 계정)에는 최소 권한만 주고, 비밀값을 저장해 두는 대신 관리 ID를 쓰고, OAuth 앱을 비밀값 기반 인증에서 옮기라는 것입니다. 이 글은 Azure 사례만 확인했고 다른 클라우드의 비슷한 통계는 찾지 못했습니다.

사고가 난 뒤 공지는 어떻게 이어졌나요?

사고가 난 뒤의 모습을 두 사건으로 봅니다. 서로 다른 사건이라 시간을 직접 비교할 수는 없습니다. Chainalysis의 사고 공지(2026년 10월 30일 공개, 11월 6일까지 갱신)를 날짜순으로 보면 다음과 같습니다.

날짜(공지에 적힌 미 동부 시간)	공지 내용
10월 30일	외부 행위자가 "offensive agentic techniques"로 시스템과 내부 도구에 접근했다고 공개. 이름, 이메일, 조직 내 역할 같은 정보가 노출됐고, 당시에는 비밀번호 평문, MFA 비밀값, 세션 토큰 접근 정황을 찾지 못했다고 적음
11월 2일	예방 차원에서 Reactor와 Data Solutions를 오프라인으로 전환
11월 4일 오전 9시 50분	"on-path attack"으로 일부 고객 비밀번호가 노출됐다고 알림
11월 4일 오전 10시 30분	비정상 활동을 감지해 KYT, Address Screening, 로그인 페이지를 오프라인으로 전환
11월 4일 밤 11시	전체 사용자의 이름, 사용자명, 비밀번호 해시, 유효 토큰이 노출됐다고 갱신. KYT 계정이 무단 접근된 정황이 있는 고객에게는 직접 알림
11월 6일 오전 3시 30분	단계적 복구 시작. 이용하려면 비밀번호 재설정과 API 키 교체가 먼저

첫 공지와 일주일 안의 갱신이 많이 다르다는 점을 눈여겨보세요. 첫 공지의 "토큰 접근 정황 없음"은 닷새 뒤 "유효 토큰 노출"로 바뀌었습니다. 그리고 Chainalysis의 복구 조건은 고객 쪽 숙제, 곧 비밀번호 재설정과 API 키 교체였습니다.

한 가지는 분명히 해 둡니다. 공개된 내용만으로는 이 사고가 에이전트의 열쇠가 유출돼서 생겼는지 알 수 없습니다. "agentic"은 Chainalysis 자신의 표현이고, 침입 경로와 도구는 공개되지 않았습니다.

Vercel 사고는 모양이 다릅니다. Vercel의 공지(2026년 4월 19일 첫 갱신, 10월 16일 종료)에 따르면 제3자 AI 도구 Context.ai가 침해됐고, 공격자는 그 접근을 이용해 Vercel 직원 한 명의 Vercel Google Workspace 계정을 장악했고, 그 직원의 Vercel 계정으로 들어갔습니다. 거기서 "민감함"으로 표시되지 않은 환경 변수를 열거하고 복호화했습니다. 첫 갱신부터 종료 선언까지 약 6개월입니다(LeanX 계산). Vercel이 고객에게 한 권고는 민감함으로 표시하지 않은 환경 변수를 검토해 교체하고, 다중 인증(MFA)을 켜고, 활동 로그를 확인하라는 것이었습니다.

작은 회사에 쓸 만한 교훈은 하나입니다. 업무에 연결해 쓰는 제3자 AI 도구 하나가 회사 계정으로 가는 길이 될 수 있습니다.

에이전트 신원 관리는 대기업만 쓰는 물건인가요?

지금은 제품도 표준도 대기업 쪽에서 먼저 나오고 있습니다. IBM은 2026년 10월 27일 TechXchange에서 에이전트 신원과 통제 제품군을 발표했습니다. HashiCorp Vault 2.2와 Agent Identity는 정식 출시(GA)이고, Secure Hub는 공개 프리뷰, watsonx Orchestrate의 탐지·차단(discover and contain) 기능은 기술 프리뷰입니다. IBM은 Vault의 단기 자격 증명과 최소 권한 통제로 에이전트의 접근 범위와 기간을 줄일 수 있고, 허가되지 않은 행동은 거부하고 세션을 실시간으로 끊을 수 있다고 설명합니다. 이건 업체의 주장이고, 독립적인 시험 결과는 찾지 못했습니다.

IBM이 보도자료에 인용한 Gartner 문장은 이렇습니다. 2028년까지 Fortune 500 기업 평균이 15만 개가 넘는 AI 에이전트를 쓰게 되고, 에이전트 거버넌스를 제대로 갖췄다고 믿는 조직은 13%뿐이라는 내용입니다. 15만 개는 전망이고, 13%는 조직이 그렇게 믿는 비율입니다. 통제 능력을 직접 잰 값은 따로 없습니다. 이 글을 쓰면서 Gartner 원문 페이지는 열리지 않아 IBM이 옮긴 문장을 따랐고, 조사 표본의 크기는 확인하지 못했습니다.

시장 쪽 신호도 있습니다. TechCrunch(2026년 11월 5일)는 Palo Alto Networks가 AI 에이전트의 회사 시스템 접근을 지키는 스타트업 Clutch Security를 현금 5억 달러에 성과 연동 추가 지급을 더해 사려고 협의 중이라고 전했습니다. 익명의 관계자를 인용한 보도이고, 두 회사 모두 논평 요청에 답하지 않았습니다. 확정된 거래가 아닙니다.

표준 쪽에서는 NIST가 2026년 10월 27일 에이전트 신원 관리 시스템의 설계 원칙 열 가지를 블로그에 올렸습니다. 이 가운데 작은 회사가 손으로도 따라 할 수 있는 네 가지가 있습니다. 에이전트를 다른 신원과 구분할 것, 쉬는 동안에는 상시 권한을 0으로 둘 것, 접근 권한은 시간 제한을 두고 회수할 수 있게 할 것, 위험이 일정 수준에 닿으면 사람 검토를 거칠 것입니다.

그래서 LeanX는 이렇게 읽어요(추정입니다). 직원 5명에서 300명 규모의 회사가 Vault나 Agent Identity를 바로 도입하는 건 비용과 복잡도가 맞지 않을 가능성이 큽니다. 15만 개라는 숫자도 우리 회사 규모로 환산할 근거가 없습니다. 먼저 필요한 건 제품이 아니라 원칙을 지키는 장부와 습관입니다.

에이전트가 아닌 것이 에이전트를 움직이면 어떻게 되나요?

권한은 그 에이전트를 움직일 수 있는 가장 약한 연결 고리의 권한이 됩니다. Forever Security 연구자가 2026년 11월 4일 공개한 ThisBash 사례가 그렇습니다. claude.ai를 제어할 수 있는 브라우저 확장 프로그램이 로그인된 세션으로 Dispatch 명령을 보내면, 연결된 기기의 Claude Desktop이 악성 npm 패키지를 설치하고 계산기를 실행했습니다. 연구자가 만든 시연이고 실제 피해가 보고된 건 아닙니다.

연구자의 기록에 따르면 2026년 5월 14일 Anthropic에 신고했고, 5월 19일 유효한 취약점으로 인정됐지만 내부 이슈와 중복으로 처리됐으며, 10월 13일 Anthropic이 Dispatch를 10월 말쯤 종료한다고 알렸습니다. 이 일정은 연구자 글의 기록이고 Anthropic의 설명을 따로 확인하지는 못했습니다. 이 글을 쓰는 11월 7일 기준으로 종료가 실제로 끝났는지도 확인하지 못했습니다.

연구자의 권고 중 우리가 가져다 쓸 수 있는 건 두 가지입니다. 에이전트가 돌아가는 기기의 브라우저 확장 프로그램을 업무용 소프트웨어처럼 관리하는 것, 그리고 화면에 뜬 확인 창이 공격자가 만든 화면일 수 있다는 점을 가정하는 것입니다.

작은 회사는 열쇠를 어떻게 점검하나요?

LeanX는 2주를 제안합니다. 아래는 공개된 권고와 공식 문서를 순서대로 놓은 것이고, 이 순서를 고객사에서 돌려 본 결과는 아직 없습니다.

주	할 일	근거
1주	열쇠 장부를 만들어 모든 API 키, 토큰, OAuth 허용에 담당자, 범위, 만료일, 마지막 사용일을 적는다	OWASP 비인간 신원 Top 10(2025)의 부적절한 퇴출(NHI1), 비밀값 유출(NHI2), 과다 권한(NHI5), 장수 비밀값(NHI7)
1주	Google Workspace 관리자 콘솔의 보안, 액세스 및 데이터 제어, API 컨트롤, 앱 액세스 관리에서 모르는 AI 앱을 제한하거나 차단하고 위험한 범위를 막는다	Google Workspace 관리자 도움말(앱 접근 상태: 신뢰, 제한, 특정 데이터, 차단)
1주	GitHub 개인 토큰을 세분화된 토큰으로 바꾸고, 저장소를 지정하고, 권한을 줄이고, 만료일을 둔다	GitHub 문서("가능하면 fine-grained 토큰을 쓰라")
1주	노출됐을 수 있는 키는 바로 교체한다	Microsoft 권고, Vercel 권고
2주	에이전트마다 따로 계정과 키를 주고, 사람 계정의 키를 같이 쓰지 않는다	NIST 설계 원칙(에이전트 구분), OWASP NHI9(재사용), NHI10(사람이 쓰는 비인간 신원)
2주	읽기 전용부터 시작하고, 쓰기 권한은 사람 검토를 거친 뒤 올린다	NIST 설계 원칙(최소 권한, 사람 검토)
2주	환경 변수에 "민감함" 표시를 하고 MFA를 켠다	Vercel 권고
2주	회수 훈련으로 에이전트 하나의 접근을 전부 끊는 데 몇 분 걸리는지 직접 잰다	LeanX 제안(NIST의 회수 가능한 짧은 권한 원칙을 손으로 해 보는 것)
2주	에이전트가 도는 기기의 브라우저 확장 프로그램은 권한을 평가하고 설치를 통제한다	Forever Security 연구자의 권고(허용 목록 방식은 LeanX의 구체화)

2주 뒤에 남겨 둘 숫자는 세 개면 됩니다. 열쇠가 모두 몇 개인지, 마지막 사용이 90일 넘은 열쇠가 몇 개인지, 하나를 회수하는 데 몇 분 걸렸는지입니다. 90일은 LeanX가 정한 임시 기준이고 표준이 아닙니다.

에이전트 등록부를 만들고 2주 동안 읽기 전용으로 시험하는 방법은 AI 에이전트 기업 도입 사례 글에, 에이전트에게 이메일 주소를 줄 때 경계를 어떻게 그을지는 inbox boundary 설계 글에, 규칙을 문장 대신 스크립트로 옮기는 방법은 지시 파일 감사 글에 있습니다. 어디부터 볼지 모르겠다면 30문항 무료 AX 진단으로 먼저 점검해 볼 수 있습니다.

이 글이 확인하지 못한 것은 무엇인가요?

• Gartner 원문은 열리지 않았습니다. 15만 개와 13%는 IBM 보도자료에 인용된 문장을 따랐고, 조사 표본은 모릅니다.
• Chainalysis의 침입 경로, 도구, 접근 기간은 공개되지 않았습니다. 에이전트의 열쇠 유출 사고라는 근거도 없습니다.
• Palo Alto Networks와 Clutch Security는 보도된 협의일 뿐 확정되지 않았습니다.
• IBM의 단기 자격 증명과 실시간 회수는 업체 설명이고, 일부 기능은 아직 프리뷰입니다.
• 5분은 Microsoft가 든 한 사례입니다. Azure 외 다른 클라우드의 비슷한 통계는 확인하지 못했습니다.
• ThisBash는 연구자의 시연이고 실제 피해 사례가 아닙니다. Dispatch의 종료 여부는 확인하지 못했습니다.
• 한국 중소기업의 열쇠 현황을 보여 주는 자료는 찾지 못했습니다. 작은 회사의 위험이 개인 SaaS 가입과 개인 키에 몰려 있다는 건 LeanX의 추정입니다.

출처

• Microsoft Security Blog, Threat actors use agentic AI tooling to find and abuse exposed secrets (2026-11-05)
• Chainalysis, Security Incident Information (2026-10-30 공개, 2026-11-06 갱신)
• Vercel, April 2026 security incident (2026-04-19 첫 갱신, 2026-10-16 종료)
• IBM Newsroom, IBM Introduces Identity and Control for AI Agents (2026-10-27)
• NIST, Design Tenets for Agent Identity Management Systems (2026-10-27)
• Forever Security, ThisBash Escape: Claude Dispatch Flaw (2026-11-04)
• TechCrunch, Palo Alto Networks in talks to buy AI agent security startup Clutch for $500M (2026-11-05)
• OWASP, Non-Human Identities Top 10 (2025)
• Google Workspace 관리자 도움말, Control which apps access Google Workspace data (2026-11-07 확인)
• GitHub Docs, Managing your personal access tokens (2026-11-07 확인)