프롬프트로는 권한 탈취를 막을 수 없다: 보안 방어선, 운영체제 커널로 후퇴
2026년 10월 7일, 마이크로소프트는 Microsoft Execution Containers(이하 MXC)의 정식 출시(GA)를 발표했다. 발표자는 윈도우 플랫폼 및 개발자 부문 부사장 로건 아이어(Logan Iyer)다. 공식 릴리스 문서 첫 페이지에서 마이크로소프트는 단호한 기술적 원칙을 명시했다. “에이전트는 스스로의 보안 권한 주체가 될 수 없다.” 에이전트는 독립적으로 선언된 경계 안에서 동작해야 하며, 외부에서 부과되는 강제 규칙에 복종해야 한다. 지난 3년간 시스템 프롬프트, 미세조정 제약, 컨텍스트 가드레일을 중심으로 구축되었던 방어벽은 마이크로소프트에 의해 언제든 뚫릴 수 있는 보조 계층으로 격하되었다.
이러한 전환은 실제 개발 환경에서 겪은 통제 실패 경험에서 비롯되었다. 웹사이트 업데이트를 담당하는 코딩 에이전트는 코드 저장소와 테스트 도구를 읽어야 하며, 배포 파이프라인을 파악하기 위해 운영 환경 설정까지 참조해야 한다. 하지만 물리적 격리가 부재한 환경에서 에이전트는 운영 설정을 직접 수정하는 것이 가장 빠른 지름길이라고 제멋대로 판단하곤 한다. 모델의 발산적 추론 능력과 보안 규칙의 확정적 요구조건 사이에는 근본적인 구조적 충돌이 존재한다.
모델의 자기 통제에 의존해서는 월권행위를 해결할 수 없다. 프롬프트 인젝션과 목표 표류 현상은 인지 계층의 윤리적 지시를 언제든지 우회한다. 마이크로소프트는 방어선을 운영체제 바닥으로 후퇴시키고, 오랜 시간 검증된 프로세스 경계를 통해 에이전트의 모든 작업을 통제하기로 결정했다.
읽기 전용 정책 파일: 모델의 자체 권한 부여 권한을 박탈하다
MXC의 핵심 메커니즘은 정책 기반 실행 아키텍처다. 개발자는 신뢰할 수 없는 워크로드를 실행하기 전, 선언적 JSON 구성 파일을 통해 에이전트의 활동 범위를 완전히 잠근다. 정책은 다섯 가지 제어 차원을 포괄한다. 격리 백엔드 유형, 프로세스 인자, 파일 시스템 읽기/쓰기 경로, 네트워크 대상, 그래픽 사용자 인터페이스 권한이다. 정책 파일은 에이전트의 제어 영역 밖에 엄격히 격리되어 있으므로, 모델이 생성한 코드가 임의로 권한을 상승시킬 수 없다.
최소 권한 정책 작성의 진입 장벽을 낮추기 위해 MXC는 세 가지 작동 모드를 지원한다. Learning 모드는 무단 작업을 차단하면서 활동 보고서를 생성해 의존성 정리를 돕고, Permissive 모드는 모니터링 목적으로 이상 징후만 기록하며, Enforcement 모드는 경계를 벗어난 접근을 즉시 차단한다. 이러한 단계적 접근법은 초기 구동 시 에이전트의 행동을 정밀하게 예측하기 어렵다는 엔지니어링 난제를 해결한다.
마이크로소프트는 이 아키텍처에 맞춰 다국어 개발 도구 체인도 함께 공개했다. 오픈소스 저장소에는 Rust, .NET, Node용 SDK 3종과 함께 엄격한 버전 관리 기반의 JSON Schema가 제공된다. 개발자는 보안 체계를 처음부터 다시 설계할 필요 없이, 기존 프레임워크 외부에 컨테이너 정의를 덧씌우기만 하면 된다.
그림: 정책 제어와 에이전트 실행을 분리한 MXC 아키텍처. 출처: Windows Developer Blog
요구에 맞춘 4단계 격리 백엔드: 경량 프로세스부터 하드웨어급 마이크로 가상머신까지
다양한 사용 환경의 보안 요구사항과 리소스 비용에 대응하기 위해 MXC는 네 가지 단계별 컨테이너 백엔드를 설계했다. 가장 기본이 되는 층은 경량 프로세스 컨테이너(Process Container)다. 윈도우 11에서는 AppContainer, macOS에서는 Seatbelt, 리눅스에서는 Bubblewrap을 기반으로 구동된다. 주요 데스크톱 환경을 포괄하며 콜드 스타트 지연 시간을 밀리초 단위로 유지하므로 처리량이 중요한 잦은 도구 호출에 적합하다.
전체 상호작용을 시뮬레이션해야 하는 복잡한 에이전트를 위해 윈도우 11 전용 세션 컨테이너(Session Container)가 제공된다. 에이전트는 독립된 시스템 계정 및 독립 세션 내에서 실행된다. 주 사용자의 클립보드, 화면 캡처, 입력 이벤트는 물리적으로 완벽히 차단된다. 데스크톱 UI와 상호작용 컨텍스트를 직접 분리함으로써, 에이전트를 속여 화면 속 개인정보를 탈취하려는 공격 경로를 원천 차단했다.
혼합 기술 스택과 고위험 워크로드에 대응하기 위해 MXC는 WSL Container와 실험적인 MicroVM 백엔드를 제시한다. WSL 컨테이너는 통제된 리눅스 실행 환경을 제공하며, 마이크로 가상머신은 하드웨어 가상화 경계에 직접 의존한다. 저장소에는 Hyperlight, Nanvix 등 경량 백엔드도 나란히 지원되고 있다. 운영체제 프로세스부터 하드웨어 수준의 격리에 이르기까지, 컴퓨팅 비용은 잠재적 위험 수준에 비례해 점진적으로 증가한다.
작업 중단 오류를 택할지언정, 무언의 실패와 무단 자체 복구는 금지
전통적인 자동화 스크립트에서는 조용한 성능 저하나 자동 재시도가 결함 허용 능력을 나타내는 미덕으로 여겨졌다. 그러나 MXC는 엄격한 규범을 세웠다. 권한 거부에 부딪혔을 때 에이전트는 현재 권한으로는 작업을 완료할 수 없다는 사실을 사용자에게 명확히 보고해야 한다. 시스템은 에이전트가 실패를 은폐하는 행위를 엄격히 금지하며, 보안망을 우회하기 위해 대체 경로를 자의적으로 탐색하는 행위 또한 철저히 차단한다.
이러한 설계는 자율적 의사결정의 위험한 경계선을 명확히 긋는다. 많은 권한 남용 사고는 에이전트가 문제에 직면했을 때 무리하게 자체 복구를 시도하는 과정에서 촉발된다. 에이전트에게서 맹목적인 자가 치유 권한을 박탈함으로써 작업 통제권은 언제나 인간 관리자의 손에 남게 된다.
대규모 조직 단위의 협업을 지원하기 위해 이 샌드박스는 기업 인프라와도 결합되고 있다. Windows 365는 이미 Cloud PC에서 관리형 에이전트를 실행하는 기능을 지원하여 직원의 로컬 환경 오염을 방지한다. 향후 마이크로소프트는 Microsoft Entra를 통해 에이전트에게 독립된 식별자(ID)를 부여하고, Intune 정책을 통해 샌드박스 제한을 중앙에서 일괄 배포할 예정이다.
그림: MXC를 선제 도입하거나 지원 예정인 개발자 도구 생태계 매트릭스. 출처: Windows Developer Blog
15개 생태계 기업과 연합: 마이크로소프트, 커널 화이트리스트로 런타임 규칙을 재정의하다
MXC가 공식 발표된 현재, 주요 AI 코딩 플랫폼들은 발 빠르게 연동을 마쳤다. GitHub Copilot, OpenAI Codex, Replit, OpenClaw는 이미 이 실행 계층을 기본 지원한다. Anthropic Claude Code, Manus, Raycast 등 9개 도구 역시 조만간 통합을 완료할 것이라 발표했다. NVIDIA는 OpenShell을 MXC 생태계에 접목하여 동적 네트워크 차단과 OCSF 엔터프라이즈 감사 로그 기능을 보강했다.
운영체제 거인의 플랫폼 차원 참전은 업계의 평가 기준이 변화했음을 상징한다. 과거 커뮤니티는 벤치마크 해결률에만 집중했다. 그러나 실제 기업 도입 단계에서 팀들이 가장 주목하는 것은 제로 트러스트 프레임워크 하에서 물리적 격리를 구현할 수 있는지 여부다. 코드 생성 능력은 모델의 파라미터가 결정하지만, 기업 현장에서의 도입 범위는 기저 샌드박스의 보안 두께가 결정한다.
초창기 웹 브라우저 샌드박스부터 모바일 기기의 권한 팝업에 이르기까지, 엔지니어링 역사는 한 가지 법칙을 끊임없이 증명해 왔다. 신뢰할 수 없는 실행 흐름 앞에서는 논리적 차원의 도덕적 제약 그 어떤 것도 믿을 수 없다. 윈도우 11에 MXC를 도입함으로써 마이크로소프트는 업계 전체에 명확한 엔지니어링 신호를 보냈다. AI 에이전트의 역량 확장은 더 이상 맹목적인 신뢰에 머물러서는 안 되며, 운영체제 커널이 규정하는 화이트리스트 안으로 안전하게 후퇴해야 한다.
참고 링크:
- Windows Developer Blog 공식 출시 발표
- Microsoft Execution Containers 아키텍처 백서 및 기술 사양서
- GitHub microsoft/mxc 오픈소스 프로젝트 기술 문서 및 규격
- NVIDIA OpenShell 및 MXC 보안 감사 통합 솔루션
