Microsoft MXC 프리뷰, Windows 에이전트 실행 격리

AI 요약

• 무슨 일: Microsoft가 Build 2026에서 Microsoft Execution Containers SDK early preview를 공개했습니다.
  • Windows와 WSL에서 에이전트가 생성한 코드, tool, plugin 실행을 정책 기반으로 격리하는 계층입니다.
• 실무 영향: 로컬 coding agent의 권한을 user session 전체가 아니라 파일, 네트워크, UI 접근 정책으로 쪼개려는 시도입니다.
• 운영 축: Agent 365, Defender, Entra, Intune, Purview가 로컬 에이전트 발견, 정책, 감사, 데이터 보호로 연결됩니다.
  • Windows 365 for Agents는 Intune-managed Cloud PC에서 에이전트를 실행하는 옵션으로 GA 상태입니다.
• 주의점: GitHub 저장소는 현재 MXC profile을 security boundary로 취급하지 말라고 경고합니다.

Microsoft가 2026년 6월 2일 Build 2026에서 Microsoft Execution Containers, 줄여서 MXC SDK의 early preview를 공개했습니다. Windows Developer Blog의 발표는 에이전트가 파일을 읽고, 서비스를 호출하고, 환경을 바꾸며, 여러 작업을 빠르게 연결하는 상황을 출발점으로 삼습니다. 이제 보안 질문은 "이 앱을 설치해도 되는가"에서 "이 에이전트가 방금 만든 코드를 어느 권한으로 실행해도 되는가"로 내려갑니다.

이번 발표가 다른 Build 2026 AI 발표와 다른 지점은 위치입니다. Work IQ API, Foundry Hosted Agents, Scout, Copilot SDK는 에이전트가 무엇을 알고 어디에 배포되는지를 설명합니다. MXC는 에이전트가 사용자 기기나 WSL 환경에서 실제 명령을 실행할 때, 운영체제가 어떤 경계를 강제할 수 있는지를 묻습니다. 모델 품질보다 runtime containment가 앞에 오는 발표입니다.

Microsoft는 MXC를 Windows와 WSL을 위한 cross-platform, policy-driven execution layer라고 설명했습니다. 개발자는 agent app이나 tool 실행에 필요한 제약을 정의하고, Windows는 그 제약을 런타임에 적용합니다. 발표문은 MXC가 low-level isolation detail을 직접 다루지 않도록 abstraction layer를 제공한다고 적었습니다. 에이전트 개발자가 AppContainer, Windows Sandbox, WSL, micro-VM 같은 선택지를 일일이 조립하지 않고 정책 모델을 앞에 두게 하려는 방향입니다.

Microsoft Security Blog도 같은 발표를 보안 제품 관점에서 풀었습니다. 이 글은 MXC SDK가 process isolation과 session isolation 같은 OS 격리 기술을 통해 containment와 policy를 적용한다고 설명합니다. 여기에 Agent 365 SDK, Windows 365 for Agents, Defender, Entra, Intune, Purview가 연결됩니다. 즉 MXC는 독립 실행형 sandbox 라이브러리라기보다 Microsoft가 로컬 에이전트를 enterprise control plane 안으로 넣기 위한 실행 계층입니다.

GitHub에 공개된 microsoft/mxc README는 더 직접적입니다. 저장소는 MXC를 Windows, Linux, macOS에서 untrusted code, model output, plugin, tool을 실행하기 위한 sandboxed code execution system이라고 정의합니다. 지원 백엔드는 ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, MicroVM, Hyperlight, IsolationSession, WSLC처럼 여러 단계로 나뉩니다. 같은 "에이전트 격리"라도 빠른 process isolation부터 더 무거운 VM 계열까지 workload에 따라 다른 무게를 쓰겠다는 설계입니다.

이 표에서 제품 선택보다 더 중요한 항목은 README의 경고입니다. microsoft/mxc 저장소는 early preview 코드이며, underlying sandbox가 계속 바뀔 수 있다고 적습니다. 더 강한 문장도 있습니다. 현재 SDK가 생성하는 policy 중 지나치게 permissive한 알려진 사례가 있고, 현재 MXC profile을 security boundary로 취급해서는 안 된다는 경고입니다. 보안 발표 기사에서 이 문장을 빼면 독자는 MXC를 이미 production-grade 격리 경계로 오해할 수 있습니다.

그 경고가 발표의 가치를 낮추지는 않습니다. 오히려 지금 MXC가 서 있는 위치를 정확히 알려줍니다. Microsoft는 Windows에 agent runtime policy plane을 넣으려 하지만, 공개 저장소 수준에서는 아직 개발자 피드백을 받는 단계입니다. enterprise 보안팀이 당장 "이제 로컬 에이전트가 안전하다"고 결론 내릴 수는 없습니다. 대신 "어떤 권한을 OS가 표현하고, 어떤 백엔드가 어느 risk class에 맞는가"를 검토할 재료가 생겼습니다.

개발자 입장에서 MXC가 겨냥하는 실패 사례는 익숙합니다. coding agent가 test를 실행하려고 shell을 열었다가 홈 디렉터리 전체를 읽습니다. package install 과정에서 network가 외부로 열립니다. browser automation tool이 clipboard나 local credential store에 접근합니다. 모델이 생성한 script가 의도보다 넓은 glob pattern으로 파일을 지웁니다. 지금까지 이런 문제는 prompt, repo sandbox, Docker, VM, 권한 낮춘 계정, CI runner를 섞어 막았습니다. MXC는 이 문제를 Windows와 WSL의 실행 정책으로 끌어내리려 합니다.

Windows Developer Blog는 이 구조를 "composable sandbox"라고 부릅니다. 같은 policy model과 SDK가 workload 요구에 따라 다른 isolation construct로 매핑될 수 있다는 설명입니다. coding agent와 enterprise data-processing agent가 같은 경계를 필요로 하지 않는다는 점도 명시합니다. 이 말은 격리 수준이 단일 on/off 스위치가 아니라는 뜻입니다. 에이전트가 읽는 데이터, 실행하는 코드의 출처, 네트워크 필요성, 사용자 UI 접근 여부에 따라 backend와 policy가 달라져야 합니다.

Agent 365와의 결합은 엔드포인트 관리 쪽에서 더 큰 사건입니다. Microsoft Security Blog는 Agent 365 Agent Registry가 Defender, Entra, Intune을 통해 unmanaged local agents를 드러내는 기능을 설명합니다. Registry는 coding agents, AI desktop applications, local and remote MCP servers를 포함해 20종 이상의 local agent type을 지원한다고 적었습니다. Purview 쪽 발표는 Claude Code, GitHub Copilot, OpenAI Codex, OpenClaw 같은 coding agent가 민감 데이터에 접근하는 방식을 감지하고, prompt 단계에서 runtime DLP를 적용하는 방향을 제시합니다.

이 구조에서는 에이전트가 더 이상 "개발자가 설치한 도구"로만 남지 않습니다. 보안팀의 inventory, identity, DLP, audit, endpoint policy 대상이 됩니다. 로컬에서 돌아가는 agent binary, MCP server, shell command, file access가 모두 관리 plane에 올라옵니다. 개발팀에는 불편한 변화일 수 있습니다. 그러나 기업 환경에서 Codex, Claude Code, Copilot CLI, OpenClaw 같은 도구가 실제 repo와 production credential 근처에서 움직인다면, 보안팀이 탐지와 차단 권한을 요구하는 것은 자연스러운 수순입니다.

파트너 목록도 Microsoft의 의도를 보여줍니다. Windows 발표는 Hermes, Manus, NVIDIA, OpenAI, OpenClaw를 언급했습니다. OpenClaw는 Windows companion app으로 node와 gateway를 설정하거나 기존 claw에 연결할 수 있다고 설명됩니다. NVIDIA는 MXC 기반 OpenShell을 Windows로 가져온다고 발표문에 들어갔습니다. OpenAI의 David Wiesen은 Codex capability와 MXC execution environment를 결합해 intent에서 reliable execution으로 빠르게 이동하면서 enterprise security와 control을 유지하는 패턴을 탐색한다고 말했습니다.

여기서 Codex 언급은 단순한 로고 나열보다 큽니다. coding agent는 모델 답변을 넘어 파일 수정, shell 실행, dependency install, test run, PR 작성까지 연결됩니다. 이 작업은 생산성 지표로 보면 매력적이지만, 권한 지표로 보면 사용자 세션을 빌린 자동 실행자입니다. MXC 같은 계층이 실제로 성숙하면 "Codex가 내 repo에서 test를 돌린다"는 말은 "어느 directory를 read-only로 보고, 어느 temp path만 write하고, outbound network를 막은 상태에서 test를 돌린다"는 구체적 정책 문장으로 바뀔 수 있습니다.

Windows 365 for Agents는 로컬 격리와 다른 축입니다. Microsoft는 이 기능이 now generally available이며, 에이전트가 Intune-managed Cloud PC에서 실행된다고 설명합니다. 사용자 기기와 완전히 분리된 Cloud PC에서 agent workflow를 실행하고, 문제가 생기면 영향 범위를 disposable cloud instance로 묶는 방식입니다. 로컬 개발 속도와 cloud-managed containment 사이의 선택지가 생기는 셈입니다. 금융, 법무, 의료처럼 endpoint 데이터가 민감한 조직은 이 모델을 먼저 검토할 가능성이 있습니다.

다만 Cloud PC 격리가 모든 것을 해결하지는 않습니다. 에이전트가 cloud instance 안에서 외부 SaaS를 호출하고, 이메일을 보내고, PR을 만들고, ticket 상태를 바꾸면 부작용은 instance 밖에 남습니다. 격리는 파일 시스템 피해를 줄일 수 있지만, 잘못된 business action을 되돌리지는 못합니다. 그래서 MXC와 Agent 365 논의는 tool approval, action log, rollback, idempotency, secret scope와 함께 가야 합니다. 실행 환경만 깨끗하게 버릴 수 있어도, 에이전트가 이미 호출한 API 결과는 별도 보상 절차가 필요합니다.

Microsoft가 같은 날 공개한 Windows 개발자 발표에는 Aion 1.0 Instruct와 Aion 1.0 Plan도 들어 있습니다. Aion 1.0 Plan은 14B parameter, 32K context의 reasoning and tool-calling model로 소개됐고, capable device에서 Windows 일부로 제공될 예정이라고 적혔습니다. 이 모델 발표는 MXC와 직접 같은 제품은 아니지만, Microsoft가 로컬 agentic capability를 Windows에 넣으려 한다는 배경을 만듭니다. 로컬 모델이 tool을 부르고 파일을 다룰수록 OS 수준 정책의 필요성도 커집니다.

이번 발표를 경쟁 관점에서 보면 Microsoft는 세 층을 한 번에 묶고 있습니다. 첫째, Foundry Hosted Agents와 Windows 365 for Agents 같은 managed runtime입니다. 둘째, Windows와 WSL의 MXC 격리입니다. 셋째, Agent 365, Defender, Entra, Intune, Purview의 governance입니다. OpenAI, Anthropic, Google, AWS도 각자 agent runtime과 sandbox를 말하지만, Microsoft의 차별점은 Windows endpoint와 Microsoft 365 tenant 관리 체계를 한 묶음으로 끌고 온다는 점입니다.

기업 개발팀이 지금 할 일은 MXC를 곧바로 production 보안 경계로 채택하는 것이 아닙니다. 먼저 agent task를 risk class로 나누는 일이 필요합니다. 코드 검색과 문서 요약처럼 read-only에 가까운 작업, test 실행처럼 제한된 write path가 필요한 작업, dependency install처럼 network가 필요한 작업, 배포나 고객 데이터 수정처럼 외부 부작용이 있는 작업은 같은 sandbox 정책으로 다루면 안 됩니다. MXC의 backend 선택지는 이 분류표가 있어야 의미가 생깁니다.

두 번째는 MCP server와 local tool inventory입니다. Microsoft Security Blog는 Agent 365 Registry가 local and remote MCP servers까지 관리 대상으로 본다고 설명했습니다. 개발팀은 사내 노트북과 devcontainer, CI runner에 어떤 MCP server가 열려 있는지 모르면 정책을 만들 수 없습니다. filesystem, browser, github, database, cloud, email 같은 tool category를 나누고, agent별로 필요한 최소 권한을 적어야 합니다. 그 목록이 없으면 MXC든 다른 sandbox든 default deny와 예외 정책을 운영하기 어렵습니다.

세 번째는 관측성입니다. GitHub README는 MXC가 debug logging과 Event Tracing for Windows를 제공한다고 적습니다. enterprise 배포에서는 이 로그가 어디로 가는지, Agent 365와 Purview audit이 어떤 event를 남기는지, 실패한 policy decision이 developer workflow에 어떻게 표시되는지를 확인해야 합니다. 에이전트는 실패를 숨기고 다른 경로로 재시도할 수 있습니다. 따라서 "차단했다"는 사실뿐 아니라 어떤 prompt, tool, path, network target, backend에서 차단됐는지 기록해야 postmortem이 가능합니다.

네 번째는 개발자 경험입니다. 에이전트 격리는 보안팀만 만족시키면 실패합니다. coding agent가 매번 permission prompt에 걸리거나, test마다 network policy가 깨지거나, Windows와 WSL 사이 path mapping이 흔들리면 개발자는 우회로를 찾습니다. MXC가 성공하려면 policy template, repo별 권한 선언, local dry-run, 실패 로그, 예외 요청이 IDE와 CLI 안에서 짧게 이어져야 합니다. Microsoft가 VS Code, Copilot, Windows, Intune을 모두 갖고 있다는 점은 이 UX를 묶을 수 있는 강점입니다.

커뮤니티 반응은 아직 얕습니다. HN에서 MXC 자체가 긴 토론을 만든 흔적은 확인하지 못했습니다. Reddit과 보안 매체는 대체로 "Microsoft가 AI 에이전트에 OS 수준 sandbox를 붙인다"는 식으로 요약합니다. CSO Online은 MXC를 Agent 365와 Defender, Entra, Intune, Purview에 연결되는 runtime containment offering으로 봤습니다. 이 반응은 방향을 잘 짚지만, GitHub 저장소의 early preview 경고를 같이 읽어야 합니다.

이번 발표의 한계도 명확합니다. MXC는 prompt injection을 없애지 않습니다. 에이전트가 합법 tool을 잘못된 이유로 호출하는 문제, MCP server supply chain, tool description poisoning, credential leakage, memory poisoning, 외부 SaaS 부작용은 별도 방어가 필요합니다. 특히 README가 말한 것처럼 현재 profile이 security boundary가 아니라면, 보안팀은 MXC를 layered defense의 후보로 보되 단독 통제로 배포해서는 안 됩니다.

그래도 Microsoft의 발표는 AI 에이전트 보안 논의를 한 단계 더 구체적으로 만듭니다. "에이전트를 신뢰할 수 있는가"라는 질문은 너무 큽니다. MXC가 던지는 질문은 좁고 측정 가능합니다. 이 agent가 어느 directory를 읽을 수 있는가. 어느 path에 쓸 수 있는가. network outbound를 막을 수 있는가. clipboard와 UI 접근을 분리할 수 있는가. long-running session을 어떻게 시작하고 멈추는가. 이 질문에 답이 있어야 로컬 에이전트를 기업 기기 위에 올릴 수 있습니다.

devlery가 최근 다룬 Microsoft Build 2026 발표들을 함께 놓으면 그림이 선명해집니다. Work IQ는 에이전트가 조직 문맥을 읽는 방법을 다룹니다. Foundry Hosted Agents는 agent runtime과 tracing, evaluation을 다룹니다. Scout는 상시 개인 업무 에이전트를 보여줍니다. MDASH는 보안 취약점 검증에 agent swarm을 씁니다. MXC는 그 모든 방향이 endpoint와 user session 가까이 내려왔을 때 필요한 실행 경계입니다. 화려한 데모보다 덜 보이지만, 실제 배포에서는 이 층이 빠지면 보안 리뷰를 통과하기 어렵습니다.

Microsoft MXC 프리뷰의 결론은 단순합니다. Windows는 AI 에이전트를 실행하는 화면이 아니라, 에이전트가 할 수 있는 일을 제한하는 정책 집행자로 자리 잡으려 합니다. 현재 공개 저장소는 early preview이고 보안 경계로 취급하면 안 된다는 단서가 붙어 있습니다. 그래서 지금의 실무 과제는 도입보다 분류입니다. 팀의 agent workflow를 read, write, network, UI, secret, external action으로 나누고, 각 작업이 어떤 sandbox backend와 감사 로그를 요구하는지 적어야 합니다. MXC가 성숙할 때 그 표가 없으면 에이전트 권한은 여전히 사용자 계정 전체를 빌려 쓰는 자동화에 머물게 됩니다.