Microsoft Execution Containers 1.0.0 — AI 에이전트를 정책으로 격리합니다

AI 요약

AI 에이전트는 파일과 네트워크, 애플리케이션을 다루며 생산성을 높이지만, 필요한 권한을 넘어서 행동할 위험도 있습니다. Microsoft는 에이전트에 무제한 접근을 허용하거나 생산성 향상을 포기하는 양자택일 대신, 실행 경계를 두는 Windows 플랫폼 기능을 개발하고 있습니다. Microsoft Execution Containers(MXC) 1.0.0은 이 가운데 격리 기능을 제공하며 정식 출시됐습니다.

에이전트와 실행 경계

에이전트가 자기 권한을 스스로 정하도록 두면 안 됩니다. 개발자나 조직이 경계를 정하고, 에이전트와 별개로 운영체제가 이를 집행해야 합니다. 예를 들어 웹사이트 코딩 에이전트에는 저장소 읽기·쓰기와 빌드·테스트 도구 접근을 허용하고, 서버 설정 파일은 읽기만 허용할 수 있습니다. 에이전트가 서버 설정을 바꾸려 해도 실행 환경이 작업을 막습니다.

MXC는 신뢰하기 어려운 코드나 동적으로 생성되는 작업을 위한 정책 기반 실행 계층입니다. 모델이 만든 코드, 플러그인, 도구, 에이전트 실행기(harness), 또는 에이전트 전체를 격리할 수 있습니다. 개발자는 필요한 파일과 네트워크 대상 같은 자원을 JSON 설정과 다국어 SDK로 선언합니다. MXC는 Windows·macOS·Linux에서 선택한 격리 백엔드에 맞춰 정책을 적용하며, 에이전트가 정책을 바꿔 권한을 늘리는 일은 허용하지 않습니다. Windows 365에서도 MXC를 정식 지원해 Cloud PC에서 에이전트를 실행할 수 있습니다.

작업에 맞춰 격리 수준 선택

프로세스 컨테이너는 Windows 11·macOS·Linux에서 사용할 수 있으며, 빠른 응답이 필요한 코드 실행과 도구 사용에 맞습니다. Windows에서는 AppContainer, macOS에서는 Seatbelt, Linux에서는 Bubblewrap 등 플랫폼별 프로세스 샌드박스를 씁니다. 세션 컨테이너는 Windows 11 전용이며 별도 계정과 운영체제 세션에서 실행합니다. 에이전트의 데스크톱, 클립보드, UI, 입력을 사용자 세션과 분리해 장시간 자동화나 데스크톱 작업에 대응합니다. WSL 컨테이너(WSLc)는 Windows 11에서 Linux 개발 환경이 필요한 작업에 씁니다. MicroVM은 Windows 11·Linux에서 실험적으로 제공하며, 하드웨어 기반 격리와 Linux 호환성을 제공합니다. 각 백엔드는 보안 특성이 다르므로 작업에 맞춰 골라야 합니다.

정책과 운영 모드

정책은 격리 환경, 실행 명령과 인수·작업 디렉터리·환경 변수, 파일 시스템 권한, 네트워크 연결, 사용자 인터페이스 접근을 다룹니다. 조직은 Intune 같은 관리 정책을 추가해 에이전트 개발자가 정한 권한을 더 제한할 수 있습니다. Intune을 이용한 Windows 11 프로세스 컨테이너 관리 기능은 곧 제공될 예정입니다.

MXC에는 세 가지 운영 모드가 있습니다. Enforcement는 허용된 작업만 실행하고 정책을 벗어난 접근은 차단합니다. Learning은 접근을 차단하면서 JSON 활동 보고서에 기록해, 실패 원인과 필요한 권한을 확인하도록 돕습니다. Permissive는 정책이 막을 접근도 허용하되 기록하므로, 작업을 진행하면서 필요한 자원을 파악할 때 씁니다. Permissive 모드도 운영체제나 조직의 다른 제한을 무시하지는 않습니다. Windows 프로세스 컨테이너는 활동 보고서를 지원합니다.

에이전트 신원과 도입 현황

격리가 에이전트가 할 수 있는 일을 제한한다면, 신원 기능은 누가 작업을 수행했는지 구분합니다. Microsoft는 곧 Entra와 Agent 365를 통해 에이전트 활동을 사용자 활동과 분리하고, 관리자가 에이전트별로 행동을 조사하거나 정책을 적용하도록 지원할 예정입니다. 에이전트가 문제를 일으켜도 직원의 접근 권한까지 함께 막지 않는다는 구상입니다.

GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, Unsloth AI는 이미 MXC를 지원합니다. Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent, Manus, Perplexity, Raycast, Simular 등도 지원을 준비하고 있다고 밝혔습니다. NVIDIA는 파일·추론 서비스 접근 정책과 네트워크 제어, 자격 증명 관리, 기업용 OCSF 감사 기능을 OpenShell에 통합했습니다.

Hacker News 반응

• @chris_money202 — 좋은 생각이며 기업 고객이 좋아할 것 같습니다.
• @Joker_vD — 에이전트가 자기 보안 권한을 정하게 하지 말고, 사람 사용자와 별개의 보안 주체로 만들면 되지 않나요? 실행 경계가 있어도 에이전트는 서버 설정을 바꾸기로 결정할 수 있습니다. 중요한 점은 실제로 그 행동을 실행할 수 있느냐입니다. 전반적으로 발표문이 허술합니다.
  • @esafak — 별도의 보안 주체라는 말은 보안 컨텍스트가 있다는 전제를 둡니다. 이 제품이 그 컨텍스트를 제공하는데, 그게 아니라면 보안 주체를 어디서 설정하나요?
  • @freeone3000 — Windows에는 파일과 API 권한을 다루는 다중 사용자 보안 컨텍스트가 이미 있습니다. 보통 ‘사용자’나 RBAC라고 부릅니다. 읽어도 일주일 전에는 할 수 없던 일이 무엇인지 잘 모르겠습니다.
  • @MrBuddyCasino — 사용자별로 접근 가능한 IP 대역을 제한할 수 있나요?
  • @trollbridge — Linux에서는 꽤 간단합니다. 특정 앱만 다른 특정 앱과 통신하게 하는 식으로 사용합니다. 예를 들어 어떤 프로세스가 Google에만 연결하도록 제한하기도 쉽습니다.
• @3eb7988a1663 — 이걸 일반적인 앱 권한 경계로 쓸 수 있나요, 아니면 앱을 에이전트인 것처럼 꾸며야 하나요? 음악 플레이어가 SSH 키를 읽지 못하게 막을 방법이 필요합니다. 이런 보안 기능은 기업 고객만 쓰고 일반 사용자는 비싼 라이선스를 사야 하는 건가요?
  • @tuwtuwtuwtuw — 제한하면 좋을 대상이 많습니다. NPM 설치가 떠오릅니다. 개발 컨테이너와 통합해 더 강한 격리로 실행할 수 있을지도 궁금합니다.
  • @tomrod — 개발자들이 VS Code Workspaces를 쓰는 걸 봤습니다. 제한적이지만 제가 원하는 방향으로 가는 괜찮은 첫걸음입니다.
  • @tuwtuwtuwtuw — VS Code Workspaces는 보호 기능을 제공하지 않는 것 같습니다. GitHub Codespaces를 말하는 건가요?
  • @tomrod — 아니요, VS Code Workspaces를 말했습니다. 이제 경계가 어디까지인지 알아보려고 더 파고들게 됐네요.
• @moomin — Bubblewrap에 대응하는 건 반갑지만, 업계의 권한 관리 문제는 여전히 해결되지 않았습니다. 읽기 전용 자원 접근을 설정해도 JIRA에 연결하면 다른 신원 체계와 자원 모델이 생겨 복잡성이 커집니다. 보안 모델을 계속 복잡하게 만드는 방식은 작동하지 않습니다. 문제가 생기면 설정을 제대로 하지 않았다고 말할 수 있을 뿐입니다. 에이전트를 보호하려면 보안을 근본부터 다시 생각해야 합니다.
  • @xienze — 개발자도 승인 버튼을 계속 누르기 싫어합니다. 세밀한 권한 설정과 승인 피로 사이에서 선택해야 하는데, 쉽지 않습니다.
  • @Melatonic — 모바일 기기는 어떤 면에서 더 나은 일을 해왔습니다. 기본적으로 최소 권한을 적용하는 표준이 필요하고, 지금보다 훨씬 덜 헷갈려야 합니다.
• @amluto — 백엔드별 문서를 훑어보니 프로젝트 대부분이 사용 사례에 맞는 보안 설계를 하기보다, 최근 세대 LLM이 ‘무슨 수를 써서든 작동하게 만들라’는 지시를 받은 결과처럼 보입니다. Bubblewrap 통합 문서조차 생각나는 대로 쓴 글 같습니다. 결과물을 거의 신뢰하지 못하겠습니다.
  • @andix — 한동안 프로젝트를 지켜보고 여러 버전을 시험했습니다. 전반적으로 허술하고 문서도 사실상 없습니다. 이런 추상화는 좋은 생각이지만 1.0 출시에는 아직 멀었습니다.
  • @amluto — Bubblewrap과 Hyperlight 모두에 잘 맞는 추상화가 어떻게 가능한지 상상하기 어렵습니다. 둘 다 좋은 프로젝트지만 서로 다른 문제를 다른 방식으로 풉니다. 둘 다 ‘샌드박스’라고 부를 수는 있어도, 나쁜 추상화는 보안 시스템을 만드는 나쁜 방법입니다.
• @nilleb — 가장 반가운 소식은 Windows 11 25H2의 8월 누적 업데이트로 관리자 권한 없이 App Container를 설정할 수 있게 됐다는 점입니다. 그 위에 MXC를 만들었습니다. 아직 불확실하고 불안정해 개선이 많이 필요하지만, 탐색할 수 있는 첫걸음입니다.
  • @agentdev001 — 기업에 큰 소식입니다. 지금은 ChatGPT Desktop용 Windows Sandbox를 사용자에게 중앙 배포하는 일이 번거롭습니다. Intune과 Agent 365 신원 기능도 곧 제공된다는 점이 두 번째로 반갑습니다.
• @truetraveller — 앱이 특정 디렉터리만 읽고 쓰도록 제한하는 아주 간단한 방법이 필요합니다. 20년 전에 이미 있었어야 할 기능입니다. 대부분 보안 문제를 사용하기 쉽게 해결할 수 있을 것 같습니다. MXC가 그런 기능인지는 모르겠습니다.
  • @jcoc611 — MXC로 임의 실행 파일을 시작할 수 있지만, 백엔드마다 보안 보장이 다릅니다. Windows의 LPAC 같은 백엔드는 PowerShell을 포함해 많은 실행 파일이 시작 단계에서 실패합니다.
  • @truetraveller — 백엔드 같은 건 신경 쓰고 싶지 않습니다. 저는 프로그래밍 언어와 IDE, 고성능 데이터베이스를 만들었습니다. 일반 사용자라면 어떻겠습니까? 왜 이렇게 복잡하게 만드나요? 정보는 고맙습니다.
• @andix — 직접 써봤는데 1.0 출시라고 부를 수준이 아닙니다. 초기 기술 프리뷰에 더 가깝습니다.
  • @not_a_bot_4sho — 더 자세히 설명해 주실 수 있나요?

원문: Microsoft Windows Developer Blog / 번역·요약: Trawling