마이크로소프트가 AutoGen Studio에서 세 단계짜리 익스플로잇 체인을 공개했습니다. AI 에이전트가 웹페이지를 여는 것만으로 호스트에서 원격 코드가 실행되는데, 소켓 하나를 패치한다고 근본 문제가 사라지지는 않습니다.
사용자가 웹페이지를 열고, AI 에이전트가 그 페이지를 읽어 들이는 순간 공격자는 이미 호스트에서 임의 프로세스를 띄우고 있습니다. 자격증명도, 사용자의 클릭 한 번도, 사전 접근 권한도 필요 없습니다. 이것이 AutoJack입니다. 설정을 잘못한 이야기가 아니라, 런타임 실행 제어 없이 MCP를 붙였을 때 벌어지는 일이죠.
AutoJack이란?
AutoJack은 마이크로소프트의 multi-agent 프레임워크인 AutoGen Studio에서 발견된 3단계 익스플로잇 체인(exploit chain)입니다. AI 에이전트가 웹 서핑을 하는 단 한 번의 세션만으로, 로그인이나 사용자 개입 없이 바로 호스트 권한의 원격 코드 실행(RCE)까지 이어지는 취약점이었죠.
- 1단계: 악성 웹페이지가 AI 브라우징 에이전트를 유인합니다.
- 2단계: 에이전트가 로컬 트래픽을 기본적으로 신뢰하고 별도 인증도 요구하지 않는
localhostMCP 웹소켓(WebSocket)에 연결됩니다. - 3단계: 에이전트가 명령어 실행 엔드포인트를 호출하는데, 이때 받은 문자열을 화이트리스트 검증도 없이 그대로 실행해 버립니다.
결국 브라우저 탭 하나만 열어둬도, 사용자 클릭 한 번 없이 호스트 시스템에서 임의의 프로세스가 실행되어 버리는 구조였습니다.
마이크로소프트는 2026년 6월 18일에 해당 체인을 공개하고 보안 패치를 완료했습니다(commit b047730 / PR #7362에서 수정). 다만 몇 가지 짚고 넘어갈 점이 있는데요. 취약점이 존재했던 코드는 AutoGen Studio의 main 브랜치에만 있었고 PyPI 정식 패키지로는 배포된 적이 없었습니다. 즉, 해당 기간에 소스 코드를 직접 빌드해서 쓰던 개발자들에게만 영향이 있었고, 현재 패키지 버전(0.4.2.2)은 안전합니다. 따라서 AutoJack은 대규모 실전 공격 사례라기보다는 책임감 있게 발견되고 패치된 개발 브랜치 취약점으로 보는 게 맞습니다. 하지만 바로 그렇기 때문에 이 취약점을 하나의 '패턴'으로 분석해 볼 가치가 있습니다. 패치로 해당 소켓은 닫혔지만, 이런 허점을 만들어낸 기본 설정(default setup)들은 여전히 수많은 프로젝트에 남아 있기 때문입니다.
마이크로소프트가 짚은 세 가지 근본 원인
마이크로소프트는 문제 지점을 하나씩 분명히 짚었습니다.
- 오리진 허용 목록이 로컬호스트를 믿었는데, 정작 로컬에서 돌던 에이전트가 바로 그 로컬호스트였습니다. WebSocket은 연결이 로컬 머신에서 왔다는 이유 하나로 그냥 받아 줬습니다. (CWE-1385, WebSocket 오리진 검증 누락)
- 인증 미들웨어가 MCP 경로만 예외로 빼놨습니다. 다른 엔드포인트는 다 보호하면서 MCP 경로에는 인증을 걸지 않은 거죠. (CWE-306, 핵심 기능 인증 누락)
- URL로 넘어온 서버 파라미터를 그대로 실행했습니다. 명령 엔드포인트가 받은 문자열을 검증 없이 돌린 셈이니, 전형적인 OS 명령 주입입니다. (CWE-78)
세 가지 모두 따로따로도 악용할 수 있고, 셋이 맞물리면 안정적으로 재현되는 공격 경로가 완성됩니다.
이런 허점이 AutoGen만의 문제였다면 다행이겠지만, 같은 양상이 MCP 생태계 전반에 퍼져 있습니다.
- Censys가 2026년 4월 28일 기준으로 인터넷에 열려 있는 MCP 서비스를 1만 2,520개 찾았는데, 대부분 인증 없이 접근됐습니다(Censys, 2026년 5월).
- OX Security는 Python, TypeScript, Java, Rust로 짠 MCP 구현 전반에서 RCE 취약점을 공개하며 "The mother of all AI supply chains"라는 제목을 달았습니다.
- LiteLLM의 CVE-2026-42271은 MCP 엔드포인트의 명령 주입 취약점으로, Starlette 인증 우회(CVE-2026-48710)와 엮이면 인증 없이 RCE까지 이어집니다. 같은 달 CISA의 알려진 악용 취약점(KEV) 목록에도 올랐고요.
결국 AutoJack이 드러낸 건 어느 한 제품의 버그가 아닙니다. 공격 대상이 되기 전, 개발 편의를 앞세워 짜인 생태계의 기본 설정 그 자체입니다.
소켓을 닫아도 MCP 보안이 끝나지 않는 이유
AutoGen을 패치하면 AutoJack은 막힙니다. 하지만 다음 에이전트 프레임워크, 다음 MCP 연동, 아직 자기 CVE 번호를 받지 않은 수천 대의 서버까지 막아 주지는 않죠.
세 가지 원인은 하나같이 런타임에서 드러나는 허점입니다. 설정하는 시점이 아니라, 에이전트가 실제로 뭔가를 실행하는 순간에야 터집니다. 소켓을 닫는 건 증상만 누르는 일이고, 진짜 원인은 에이전트가 무엇을 실행하려는지 아무도 판단하지 않았다는 데 있습니다. 그래서 오래가는 해법은 실행 계층에 있습니다. 명령이 타고 들어온 통로를 막는 게 아니라, 권한이 실린 행위 그 자체를 판단하는 것이죠.
런타임 실행 제어란, 에이전트가 우리가 관리하는 호스트에서 하는 모든 권한 행위를 실행 전에 세션의 스코프와 위험도로 따져 보고, 범위를 벗어나면 사람에게 넘기거나 막는 것을 말합니다. 사람 세션이든 에이전트(MCP) 세션이든 같은 잣대를 대기 때문에, 새 프레임워크의 기본 설정이라고 해서 그냥 통과되는 일은 없습니다.
MCP를 런타임에 어떻게 통제할까요?
먼저 이 통제가 정확히 어디에 있는지 짚고 가겠습니다. 에이전트 프레임워크 내부의 전송 경로를 가로채는 제품은 없고, Alpacon도 마찬가지입니다. AutoGen의 로컬 소켓 안에 들어가 있지 않죠. 대신 한 단계 아래에서 통제합니다. 에이전트의 권한 행위가 Alpacon이 관리하는 호스트에 닿는 순간, 그 행위는 호스트의 유저스페이스 에이전트인 Alpamon이 실행하기 전에 Work Session 결정 파이프라인(스코프 → RBAC → 위험 → 의도)을 먼저 거칩니다.
AutoJack의 3단계, 즉 호스트에서 임의 프로세스를 실행하는 상황에 대입하면 이렇습니다.
- 그 행위는 실행 직전에 위험도와 의도에 맞는지를 기준으로 판단됩니다. 브라우징 용도로 스코프가 잡힌 세션에서 임의 프로세스 실행은 범위를 벗어나니까, 맞춰야 할 CVE 시그니처 없이도 행위 자체를 근거로 사람에게 넘어가거나 막힙니다.
- 스코프는 단단한 상한선입니다. 세션이 선언한 범위를 벗어난 행위는 다른 검사보다 먼저 거부되죠. (스코프 상한 집행은 현재 sudo에 적용돼 다른 영역으로 넓혀 가는 중이고, 명령 단위 집행은 monitor에서 enforce로 단계적으로 켜지고 있습니다.)
이 방식이 패치와 달리 널리 통하는 이유가 여기 있습니다. 선언된 의도를 벗어나는 행위라면 무엇이든 걸러 내니까요. 같은 기본 설정을 안고 나오면서 CVE 번호조차 못 받을 다음 프레임워크도 예외가 아닙니다. 물론 이 방식이 못 하는 것도 분명합니다. 에이전트 프레임워크 안쪽 소켓까지 막지는 않습니다. 침해된 에이전트가 우리가 관리하는 호스트에 아예 닿지 않는다면, 그건 애플리케이션 위생 문제이지 실행 제어의 몫이 아니고, 그런 경우는 패치로 풀면 됩니다.
패치보다 오래 남는 질문
AutoJack이 끝나고 진짜 던져야 할 질문은 "이 소켓을 패치했나"가 아닙니다. AI 에이전트가 돌아가며 살아 있는 MCP 엔드포인트로 도구 호출을 쏟아 내는 순간, 그 실행을 무엇이 통제하느냐입니다.
AutoJack은 공개된 사례 하나일 뿐입니다. 열려 있는 1만 2,520개 서비스도, OX Security의 생태계 경고도, CISA가 지목한 LiteLLM 체인도 결국 같은 질문을 다른 얼굴로 던지고 있습니다. 그 답이 매번 엔드포인트 자신의 허용 목록뿐이라면, 패턴은 이미 뻔합니다.
Alpacon은 AI 에이전트를 위한 실행 제어 계층입니다. 관리하는 호스트가 행위를 실행하기 전에, 권한이 실린 행위 하나하나를 세션의 스코프와 의도에 비추어 판단합니다. 사람 세션이든 에이전트(MCP) 세션이든 잣대는 같습니다.
