Microsoft ‘MXC’ 정식 공개…AI 에이전트에 파일·네트워크 경계
Microsoft가 AI 에이전트와 생성 코드의 실행 권한을 운영체제 수준에서 제한하는 ‘Microsoft Execution Containers(MXC)’를 정식 공개했습니다. 개발자가 파일·네트워크·화면 접근 정책을 선언하면 에이전트가 바꿀 수 없는 외부 경계에서 집행합니다. Windows 11의 세션 컨테이너와 WSL 격리, 여러 운영체제의 프로세스 컨테이너를 제공하지만 Intune 관리와 Entra 신원 귀속은 추후 기능입니다.
AI가 실행하기 전에 운영체제가 경계를 정한다
Microsoft는 10월 7일 Microsoft Execution Containers, 줄여서 MXC를 정식 공개했습니다. AI 에이전트가 내려받거나 만들어 낸 코드를 곧바로 호스트 환경에서 실행하지 않고, 허용된 자원만 보이는 격리 공간에서 돌리는 오픈소스 실행 계층입니다. 모델이 더 많은 작업을 대신할수록 ‘무엇을 생각했는가’뿐 아니라 ‘어디까지 행동할 수 있는가’를 통제해야 한다는 문제를 겨냥합니다.
핵심은 정책의 주도권입니다. 개발자는 에이전트가 읽거나 쓸 파일과 폴더, 접속할 네트워크, 시작할 프로세스, 화면·클립보드 같은 사용자 인터페이스 자원을 선언합니다. 정책은 에이전트 바깥에서 집행되므로 에이전트가 프롬프트나 코드로 스스로 권한을 넓히는 일을 막습니다. 정상 작업에 필요한 최소 권한만 주는 ‘최소 권한’ 원칙을 에이전트 실행에 적용한 셈입니다.
하나의 API 아래 네 가지 격리 방식
MXC는 같은 정책 모델 아래 서로 다른 백엔드를 둡니다. 프로세스 컨테이너는 Windows 11의 AppContainer, macOS의 Seatbelt, Linux의 Bubblewrap를 활용해 세 운영체제를 지원합니다. Windows 11 전용 세션 컨테이너는 별도 계정·로그인 세션·데스크톱을 만들어 화면, 입력과 클립보드까지 분리합니다. 그래픽 앱을 다루는 에이전트에 필요한 경계입니다.
Windows 11의 WSL 컨테이너는 Linux 도구 체인을 격리해 쓰게 하고, Windows 11과 Linux에서 시험 중인 마이크로VM은 가상화 경계를 더합니다. 다만 이름이 모두 ‘컨테이너’여도 성질은 같지 않습니다. 프로세스 수준 격리와 별도 데스크톱, 가상머신은 공격면과 시작 속도, 호환성이 다르므로 개발자는 업무 위험도에 맞춰 백엔드를 골라야 합니다.
차단·학습·허용을 분리한 세 모드
운영 모드는 Enforcement, Learning, Permissive로 나뉩니다. Enforcement는 정책 밖의 행동을 차단하고, Learning은 차단한 시도를 기록해 필요한 권한을 찾는 데 씁니다. Permissive는 정책 위반을 기록하되 행동은 허용합니다. 마지막 모드는 기존 작업의 의존성을 파악하는 관찰 도구이지 실제 보호막이 아닙니다. 배포 환경에서 세 모드를 혼동하면 감사 로그는 남아도 위험한 행동은 실행될 수 있습니다.
파일·네트워크·프로세스·UI라는 정책 영역을 따로 둔 점도 실무적입니다. 예를 들어 코드 수정 에이전트에는 저장소 쓰기와 패키지 레지스트리 접속만 허용하고, 개인 문서나 사내 다른 도메인은 숨길 수 있습니다. 화면 조작 에이전트라면 별도 세션에 필요한 앱만 열어 두는 식입니다. ‘모델이 안전할 것’이라는 기대를 구체적인 운영체제 권한으로 바꾸는 접근입니다.
Codex·Copilot부터 연결, 기업 관리는 다음 단계
Microsoft는 GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio, OpenShell, Unsloth 등이 이미 MXC를 지원한다고 밝혔고 Anthropic Claude Code 등 추가 연동도 예고했습니다. 서로 다른 에이전트가 공통 격리 계층을 쓰면 도구마다 별도 샌드박스를 설계하는 부담을 줄이고, 같은 정책 문법으로 실행 흔적을 비교할 수 있습니다.
하지만 기업 배포의 퍼즐이 모두 완성된 것은 아닙니다. Intune에서 정책을 관리하는 기능과 Microsoft Entra 신원으로 어떤 에이전트가 행동했는지 귀속하는 기능은 ‘곧 제공’으로 표시됐습니다. 정식 공개는 MXC 핵심 실행 계층의 상태를 뜻하며, 조직 전반의 승인·감사·신원 관리가 이미 준비됐다는 의미는 아닙니다.
보안 경계는 방어층이지 면책 조항이 아니다
MXC는 프롬프트 인젝션이나 악성 의존성이 에이전트를 속여도 피해 범위를 제한하는 데 유용합니다. 그러나 허용 목록 자체가 넓거나 민감한 자격 증명을 컨테이너 안에 넣으면 경계 안에서 피해가 발생할 수 있습니다. 정책 설계, 비밀 관리, 로그 검토와 사람의 승인 절차는 여전히 필요합니다. Microsoft도 격리 방식별 보호 특성을 확인하고 위험에 맞게 선택하라고 강조합니다.
이번 발표의 의미는 AI 에이전트 보안을 모델 평가만의 문제에서 운영체제 집행 문제로 확장했다는 데 있습니다. 앞으로의 관전점은 기본 정책이 얼마나 보수적인지, Learning 로그가 과도한 권한을 줄이는 데 실제로 도움 되는지, Entra·Intune 연동이 여러 에이전트의 행동을 일관되게 추적하는지입니다. 에이전트가 많아질수록 실행 경계는 선택 기능이 아니라 기본 인프라에 가까워질 전망입니다.
기사가 마음에 드셨다면 하트를 눌러주세요.
기사 읽고, 잠깐 게임 한 판 어떠세요?
공격을 주고받으며 실시간으로 겨루는 AI 블록 대전
미니게임 고르기 ▶