Microsoft Execution Containers (MXC) 1.0.0 릴리스: AI 에이전트를 위한 정책 기반 격리

TL;DR – MXC 1.0.0이 제공하는 기능과 그 중요성

Microsoft Execution Containers (MXC) 1.0.0은 AI 에이전트를 호스트 시스템으로부터 격리하는 정식 출시된 정책 기반 실행 계층입니다. 개발자는 파일, 네트워크 및 UI 접근을 제한하는 JSON 정책을 선언하며, MXC는 플랫폼별 컨테이너(프로세스, 세션, WSL 또는 실험적 MicroVM)를 통해 해당 제한을 강제합니다. 이를 통해 기업은 "무제한 접근 허용 또는 전체 차단"이라는 딜레마를 피하면서 에이전트의 생산성을 확보할 수 있는 구체적인 방법을 얻게 됩니다.

격리는 에이전트 보안의 핵심 기본 요소입니다

에이전트는 스스로의 보안 권한을 가질 수 없습니다. MXC는 에이전트가 개발자나 조직에 의해 정의되고 에이전트 코드 외부에서 강제되는 경계 내에서 실행되도록 합니다. 실제로 웹사이트를 업데이트하는 코딩 에이전트에게 리포지토리에 대한 읽기/쓰기 권한과 프로덕션 구성에 대한 읽기 전용 권한을 부여할 수 있으며, 모델의 의도와 상관없이 해당 구성을 수정하려는 모든 시도는 컨테이너에 의해 차단됩니다.

"관리되는 실행 경계가 없으면 에이전트는 서버 구성을 변경하는 것이 작업을 완료하는 가장 빠른 방법이라고 판단하여 프로덕션 사이트를 손상시킬 수 있습니다." – Microsoft 블로그

MXC 아키텍처 및 지원되는 백엔드

백엔드	플랫폼	일반적인 사용 사례	주요 격리 속성
프로세스 컨테이너	Windows 11, macOS, Linux	저지연 워크로드, 모델 생성 코드, 도구 실행	AppContainer(Win), Seatbelt(macOS), Bubblewrap(Linux) 사용 – 경량 샌드박스
세션 컨테이너	Windows 11 전용	데스크톱, 클립보드, UI 격리가 필요한 장기 실행 에이전트	별도의 Windows 계정 및 세션; 데스크톱, 클립보드, 입력 격리
WSL 컨테이너 (WSLc)	Windows 11 전용	Linux 우선 도구 체인, Linux 패키지에 의존하는 워크로드	WSL 내에서 실행되어 완전한 Linux 환경 제공
MicroVM	Windows 11, Linux (실험적)	하드웨어 기반 격리가 필요한 고위험 워크로드	하드웨어 강제 VM 경계, 완전한 Linux 호환성

각 백엔드는 동일한 JSON 정책을 플랫폼별 강제 메커니즘에 매핑하여 개발자가 호스트 OS와 관계없이 단일 정책 파일을 작성할 수 있도록 합니다.

정책 스키마 – 무엇을 제한할 수 있나요?

MXC 정책은 다음 5가지 영역으로 나뉩니다:

격리(Containment) – 백엔드(프로세스, 세션 등) 선택.
프로세스(Process) – 명령줄, 인수, 작업 디렉터리, 환경.
파일 시스템(File system) – 읽기, 쓰기 및 접근 불가 경로에 대한 명시적 허용/거부 목록.
네트워크(Network) – 인바운드/아웃바운드 규칙, 루프백 활성화/비활성화.
사용자 인터페이스(User interface) – 데스크톱, 클립보드 또는 UI 요소와 상호 작용할 권한.

코딩 에이전트를 위한 일반적인 정책은 다음과 같습니다:

{
  "containment": "process",
  "process": {"command": "python", "args": ["agent.py"]},
  "filesystem": {"allowRead": ["/repo/**"], "allowWrite": ["/repo/**"]},
  "network": {"allowOutbound": ["git.example.com:443"]},
  "ui": {"allowDesktop": false}
}

정책은 에이전트 외부에 존재하므로 에이전트가 스스로 권한을 상승시킬 수 없습니다.

운영 모드 – 학습에서 강제까지

MXC는 팀이 최소 권한 정책을 반복하는 데 도움이 되는 세 가지 상호 배타적인 모드를 지원합니다:

모드	접근 결과	활동 보고서	권장 단계
강제(Enforcement)	차단된 작업은 거부됨	보고서 없음	프로덕션
학습(Learning)	차단된 작업은 거부 및 기록됨	JSON 활동 로그	정책 작성
허용(Permissive)	모든 작업은 허용 되지만 기록됨	JSON 활동 로그	초기 테스트

학습 모드에서는 거부된 파일 접근 시도가 활동 보고서에 나타나므로, 개발자는 시스템을 위험에 노출하지 않고도 누락된 경로를 정책에 추가할 수 있습니다.

Microsoft Entra 및 Agent 365와의 통합 (향후)

Microsoft는 Entra가 곧 로그인한 사용자와 별도로 에이전트 활동에 고유한 ID를 태그할 것이라고 발표했습니다. 이를 통해 다음이 가능해집니다:

Microsoft Agent 365 내 에이전트별 감사 추적.
인간 사용자가 아닌 에이전트 주체를 대상으로 하는 정책 강제 적용으로, 손상된 에이전트가 사용자의 더 넓은 접근 권한에 영향을 미치는 것을 방지.
세분화된 거버넌스 (예: 직원의 생산성은 유지하면서 오작동하는 단일 에이전트만 차단).

실제 도입 – 파트너 및 프레임워크

블로그에는 다음과 같은 초기 도입 사례가 나열되어 있습니다:

NVIDIA OpenShell – 파일, 네트워크 및 자격 증명 제어를 위해 MXC 통합.
GitHub Copilot, OpenAI Codex, Replit, LM Studio, Unsloth AI – 개발자 워크플로우를 위한 MXC 샌드박싱 이미 적용.
Anthropic Claude Code, Box, Egnyte, Heidi Health, Nous Research의 Hermes Agent, Manus, Perplexity, Raycast, Simular 등의 지원 예정.

이러한 통합은 MXC가 단순한 개념 증명이 아님을 보여줍니다. 이는 리포지토리와 도구 체인에 대한 세밀한 접근 권한이 필요하면서도 호스트 시스템을 보호해야 하는 프로덕션급 코딩 어시스턴트에서 사용되고 있습니다.

커뮤니티 피드백 – 강점 및 우려 사항

긍정적인 반응 – 관리자 권한 없이 앱 권한을 최종적으로 잠글 수 있는 기능(예: 권한 상승 없이 AppContainer 생성을 허용하는 Windows 11 25H2 관련 참고)에 대해 높이 평가.
성숙도에 대한 비판 – 일부 사용자는 문서화의 미흡함(특히 Bubblewrap 통합)과 더 깊은 보안 모델 개편의 필요성을 언급하며, 이번 릴리스를 진정한 1.0 GA가 아닌 "기술 프리뷰"로 평가.
기업 중심 – MXC가 기업 고객에게만 제한될 것인지에 대한 질문이 제기되었으며, 일반 사용자가 동일한 수준의 보호를 받지 못할 수 있다는 우려가 있음.
대안 솔루션 – 한 댓글 작성자는 기존 Linux 컨테이너/VM 사용을 제안하며, Linux에서는 이미 "잘 작동하는" 솔루션이 존재한다고 주장.

이러한 관점은 MXC가 Windows 중심의 에이전트 보안 격차를 메우고 있지만, 도입 여부는 도구의 성숙도, 명확한 문서화, 그리고 기업 라이선스를 넘어선 더 넓은 가용성에 달려 있음을 시사합니다.

시작하기

MXC 리포지토리 복제: https://github.com/microsoft/mxc.
리포지토리의 README에서 언어별 SDK(C#, Python 등) 설치.
위 스키마를 사용하여 JSON 정책 초안 작성.
학습(Learning) 모드에서 에이전트를 실행하여 활동 보고서 생성.
정책을 다듬은 후 프로덕션을 위해 강제(Enforcement) 모드로 전환.

피드백 및 버그 보고서는 GitHub Issues 트래커를 통해 환영합니다.

결론

Microsoft Execution Containers 1.0.0은 개발자에게 주요 OS 전반에서 AI 에이전트를 샌드박싱할 수 있는 구체적이고 정책 중심적인 방법을 제공하며, 에이전트가 할 수 있는 일(격리)과 에이전트가 누구인지(향후 Entra ID)를 분리합니다. 다중 격리 백엔드, 명확한 JSON 정책 모델, 안전한 정책 반복을 위한 세 가지 운영 모드를 제공함으로써 MXC는 도구가 성숙해지고 문서화가 뒷받침된다면 "무제한 또는 차단"이라는 딜레마를 관리 가능한 보안 상태로 전환할 수 있게 합니다.