AI 에이전트를 로컬에서 실행할 때, localhost에 닫혀 있기 때문에 안전하다고 생각하기 쉽습니다.

localhost에서도 위험한 경우는 외부 페이지에서 로컬 제어면(control plane)까지 경로가 연결되는 경우입니다. 에이전트나 내장 브라우저가 신뢰할 수 없는 페이지를 능동적으로 렌더링하고, 동일한 머신 상의 로컬 제어면에도 접근할 수 있다면, 신뢰할 수 없는 페이지의 영향을 받은 네트워크 툴 호출이 개발자의 머신 상의 제어면에 도달할 수 있습니다.

이 기사에서는 Microsoft가 2026년 6월 18일에 공개한 AutoJack의 해설을 소재로, AI 에이전트를 로컬에서 테스트하기 전에 무엇을 확인해야 하는지 정리합니다.

AutoJack에서 배워야 할 점은 AutoGen Studio만의 개별 버그가 아닙니다.

AI 에이전트가 신뢰할 수 없는 Web 콘텐츠를 능동적으로 렌더링하거나, 신뢰할 수 없는 입력의 영향을 받은 네트워크 툴 호출이 가능하다면, localhost 상의 제어면도 공격면(attack surface)으로 취급해야 합니다.

특히 다음의 조합은 위험합니다.

• 에이전트나 내장 브라우저가 신뢰할 수 없는 페이지의 JavaScript를 실행한다
• browser worker나 agent process에서 loopback · private network로 도달할 수 있다
• WebSocket, MCP, debug API, code runner가 독립적인 인증 · 인가(authorization)를 갖지 않는다
• 외부 입력 유래의 command / args / env가 프로세스 기동으로 전달된다
• 에이전트가 개발자와 동일한 OS 사용자 · browser profile · credential을 공유한다

이 기사에서 수행하는 것은 공개 정보의 사실 정리, wheel의 정적 확인, 로컬 Mock을 통한 설계 체크입니다.

이 기사는 개별 취약성의 재현 절차가 아니라, localhost 경계 설계의 확인 기사입니다. 취약한 버전의 도입, 기동, 접속 시도, 공격 재현은 다루지 않습니다.

먼저 자신의 환경에서 확인하려면 이 5가지 포인트입니다. 이것은 위험 조건의 스크리닝이므로, 해당 있음 또는 불명이 있다면 후반부의 실무 체크리스트로 넘어갑니다.

용어는 다음의 의미로 사용합니다.

근거는 본문 중에서 요점만 사용하며, 상세 내용은 여기에 정리합니다.

링크는 근거 확인용입니다. 취약한 버전의 도입, 기동, 접속 시도, 공격 재현은 권장하지 않습니다.

확인일: 2026-06-24

이 기사는 3부 구성입니다.

• AutoJack의 사실 정리: Microsoft의 설명, 공개 코드, 배포물로부터 읽을 수 있는 것
• 로컬 Mock: 그 사실을 일반화할 때 놓치기 쉬운 설계 관점
• 실무 체크리스트: 자신의 AI 에이전트를 로컬에서 테스트하기 전의 확인 항목

중요한 것은 AutoJack 본체의 이야기와 이 기사의 자체 제작 Mock을 섞지 않는 것입니다. AutoJack의 사실 정리는 공개 정보와 정적 확인에 기반한 것입니다. Mock은 그 읽는 법을 실무 체크로 변환하기 위한 보조 예시입니다.

먼저 이 기사의 입장을 명확히 하자면, 주장은 다음과 같습니다.

AI 에이전트를 로컬에서 실행할 때는 localhost인지 여부가 아니라, 신뢰할 수 없는 입력으로부터 로컬 제어면까지의 경로를 확인해야 한다.

PoC 미실행이나 정적 확인에 그친 점은 말미의 「이번의 한계」에 정리합니다.

Microsoft의 설명에 따르면, AutoJack는 AutoGen Studio 개발 중인 MCP WebSocket 측면의 취약점 체인(vulnerability chain)으로서 설명되고 있습니다. 주요 요소는 다음 3가지입니다.

• localhost를 신뢰한 Origin 제어
• MCP / WebSocket 경로의 인증 부족
• 클라이언트 지정의 server_params에 포함된 command / args가 프로세스 기동으로 전달된 것

적어도 수정 직전의 공개 코드에 있는 해당 핸들러(handler) 단독의 정적 확인(Static Analysis) 결과로는, MCP WebSocket 핸들러(handler) 자체에 Origin 검증이나 인증 호출이 보이지 않습니다. 또한, 사용되었던 HTTP용 미들웨어(middleware)는 WebSocket 스코프(scope)를 동일하게 처리하지 않는 구조입니다. 이것이 상위 계층이나 모든 배포 설정을 망라하여 확인했다는 의미는 아닙니다.

표준적인 WebSocket의 Origin은 접속 대상이 아니라 접속을 시작한 페이지의 Origin입니다. 따라서 단순히 "같은 머신이니까 localhost Origin이 된다"라고 해석하는 것은 부정확합니다. 본고에서는 PoC를 재현하지 않았으므로, localhost Origin이 성립된 구체적인 기제까지 단정하지 않고, "WebSocket 연결에 유효한 Origin 검증과 인증이 부족했다"라고 정리합니다.

Microsoft 공식 측은 PyPI를 통해 통상적으로 설치하는 AutoGen Studio 사용자는 이 특정 취약점 체인(vulnerability chain)에 노출되지 않는다고 설명하고 있습니다. 본고에서는 이 설명을 stable install(안정적 설치)에 관한 설명으로 취급합니다. 한편, PyPI에는 0.4.3.dev1과 0.4.3.dev2라는 프리릴리스(pre-release) 버전도 존재합니다.

이 기사에서는 배포 파일을 설치하거나 실행하지 않고, 필자의 정적 확인 범위 내에서 읽었습니다. 안정 버전(stable version) 0.4.2.2에는 autogenstudio/web/routes/mcp.py가 포함되지 않으며, 0.4.3.dev1 / 0.4.3.dev2에는 해당 파일이 포함되어 WebSocket query로부터 server_params를 복호화하여 StdioServerParameters로 전달하는 처리가 있었습니다.

여기서 얻을 수 있는 교훈은 "localhost니까 안전하다"가 아니라, "신뢰할 수 없는 입력으로부터 로컬 제어면에 이르는 경로를 차단해야 한다"는 것입니다.

이후 내용은 AutoJack 본체에 대한 검증이 아닙니다. 기사 필자가 만든 로컬 Mock을 통한 가상 실험, 즉 설계 리뷰를 위한 시나리오 분석입니다. PoC를 실행한 것이 아니며, 취약성 성립을 확인하는 단계가 아닙니다.

비교한 것은 다음 두 가지뿐입니다.

고정 케이스(fixed case)로는 신뢰할 수 없는 페이지의 JavaScript가 loopback 상의 WebSocket으로 접속하는 상황, WebSocket 핸들러(handler)에 독립적인 인증이 없는 상황, query로부터 실행 명령/인자/환경 변수를 받는 상황 등을 설정했습니다. 성공 조건은 위험 조건을 허용하지 않고, 거부하거나 인간의 승인으로 넘기는 판정이 되는 것입니다. 비성공 조건은 localhost라는 점만을 근거로 허용하는 것입니다.

이 시나리오 분석에서는 방어 중심 안으로서 적어도 다음의 관점들을 남겨두어야 한다고 정리했습니다.

• WebSocket의 Origin 검증, 인증, 조작 단위의 인가 (Authorization)
• 서버 측 파라미터 바인딩 (server-side parameter binding)
• 실행 파일과 인자 스키마 (argument schema)의 허용 목록 (allowlist)
• loopback / private / link-local / 메타데이터 엔드포인트 (metadata endpoint)로의 이그레스 (egress) 제어
• 저권한 사용자, 컨테이너 (container), VM에 의한 격리
• 프로세스 트리 (process tree), 네트워크 목적지 (network destination), 도구 결정 (tool decision)의 감사 로그 (audit log)

이 비교에서 중요한 점은, 방어 중심 안이 "localhost", "WebSocket 인증", "기동 명령·인자의 전달"을 별개의 논점으로 다루는 것이 아니라, 신뢰할 수 없는 웹 콘텐츠로부터 로컬 제어 영역에 이르는 경로로서 다룬다는 점입니다. 리뷰 관점으로는 이러한 시각이 누락을 줄이기에 더 용이합니다.

Codex를 사용하는 경우에도 확인해야 할 논점은 동일합니다. 신뢰할 수 없는 입력을 기점으로 한 조작은 곧바로 실행 가능한 조작으로 흘려보내지 않고, 거부하거나 인간의 승인(human approval) 단계로 넘기도록 설계합니다. 필자가 준비한 7가지 고정 케이스에서는 기대 판정과 일치했습니다.

이는 보조적인 예시이며, Codex 본체, 샌드박스 (sandbox) 구현, MCP 통신, 모델 판단, OS·네트워크 격리의 안전성을 증명하는 것은 아닙니다.

AI 에이전트에게 웹 브라우징, MCP, 도구 실행, 로컬 API 연동 기능을 부여한다면, 우선 이곳을 확인해야 합니다. 처음부터 모든 것을 완벽하게 감사하기보다는, "신뢰할 수 없는 입력이 로컬 제어 영역이나 도구 실행에 도달하는가"를 차단하는 것이 현실적입니다.

특히, localhost only는 방어책의 일부일 뿐, 인증을 대신할 수는 없습니다.

localhost는 "외부 네트워크에서 직접 도달하기 어렵다"는 도달 제한일 뿐, "동일 호스트 상의 다른 프로세스를 신뢰해도 좋다"는 인가 (authorization) 판단이 아닙니다. egress 차단 구현 방법은 브라우저 실행 환경, OS 방화벽 (firewall), 컨테이너 네트워크 (container network), 프록시 (proxy), DNS / 리다이렉트 (redirect) 검사 등 환경마다 다릅니다.

다음과 같은 상태라면, 브라우징이 가능한 AI 에이전트와 로컬 제어 영역을 동일한 환경에서 구동하는 것은 피해야 할 선택지가 됩니다.

• 일상적으로 사용하는 (daily driver) OS 사용자로 에이전트를 구동하고 있다
• 디버그 API나 MCP 서버가 인증 없이 동작하고 있다
• 도구 실행을 위한 허용 목록 (allowlist)이 없다
• 외부 웹 페이지, issue, PR, 댓글을 그대로 에이전트에게 읽게 한다
• 실패 시 어떤 프로세스가 무엇을 실행했는지 추적할 수 없다

AI 에이전트를 로컬에서 테스트할 때는 다음 순서로 진행하는 것이 현실적입니다.

• 브라우징, 파일 액세스, 명령 실행, MCP 연결을 목록화한다
• localhost, Unix socket, Docker socket를 포함한 로컬 제어 영역을 모두 열거한다
• 브라우저 처리와 에이전트 본체로부터 loopback·private·link-local로의 도달 가능 여부를 확인하고, 필요하다면 차단·프록시·격리를 선택한다
• 각 제어 영역에 독립적인 인증, 조작 단위의 인가, 허용 목록 (allowlist)이 있는지 확인한다
• 에이전트를 저권한 사용자, 컨테이너, VM 중 하나에 격리한다
• process tree, network destination, tool call, policy decision을 기록한다
• 실제 운영용 자격 증명 (credential)이 아닌 검증용 자격 증명을 사용하여, 즉시 중단 및 무효화 절차를 확인한다

환경에 따라 구현 방법은 다릅니다. 여기서는 설정 명령어를 제시하지 않고, 확인해야 할 경계와 실패 조건만을 고정합니다.

팀 단위로 테스트할 경우에는 최소한 이 운영 방침을 결정합니다.

도입 판단은 다음과 같이 나눕니다.

• 실제 공격이나 PoC (Proof of Concept)는 실행하지 않았습니다.
• AutoGen Studio의 현행 버전을 로컬에서 실행 검사한 것이 아닙니다.
• wheel 확인은 정적 확인이며, 취약점 체인 (vulnerability chain)의 성립 확인이 아닙니다.
• 로컬 Mock은 설계 리뷰를 위한 시나리오 분석이며, 실제 환경의 안전성이나 포괄성을 나타내는 것이 아닙니다.
• Codex를 향한 고정 케이스 일치는 자체 제작 정책 판정의 확인이며, Codex 본체, sandbox 구현, MCP 통신, 모델 판단, OS·네트워크 격리의 안전성을 증명하지 않습니다.
• 기사 내 검증에서는 OpenAI API를 통한 성능 측정이나 외부 공개 API 전송은 수행하지 않았습니다.

AutoJack의 핵심은 "이 특정 버그가 무섭다"가 아니라, 신뢰할 수 없는 Web 콘텐츠, 브라우징 에이전트, 로컬 제어면 (control plane), 도구 실행이 연결되면 기존의 개발용 전제가 무너진다는 점입니다.

AI 에이전트의 안전 확인은 모델 성능보다 먼저, 경계 설계 (boundary design)를 보는 것부터 시작합니다. 이 순서가 위험한 경로를 더 빨리 차단할 수 있습니다.