10월 7일, Microsoft가 Microsoft Execution Containers(MXC)의 정식 제공을 발표했습니다. 같은 날 GitHub도 MXC 기반 Copilot 로컬 샌드박스의 정식 제공을 알렸습니다.
핵심 문장을 먼저 옮깁니다.
에이전트는 스스로 보안 주체가 될 수 없다. 에이전트는 개발자나 조직이 정하고 에이전트와 독립적으로 강제되는 경계 안에서 돌아야 한다.
에이전트가 코드를 직접 실행하는 시대에, 파일 하나·네트워크 한 줄을 정책으로 가르는 일이 제품 기능이 됐습니다. 이 글은 MXC가 뭘 가르는지, Copilot에서 어떻게 켜지는지, 내 프로젝트에 어떻게 옮기는지를 정리합니다.
왜 필요한가: 빠른 지름길이 운영 사고가 된다
공식 블로그의 예시가 정확해서 그대로 씁니다. 웹사이트를 고치는 코딩 에이전트를 시켰다고 하세요.
필요한 권한:
- 웹사이트 저장소 읽기·쓰기
- 빌드·테스트 도구 실행
- 운영 서버 설정 읽기 (배포 방식 이해용)
주면 안 되는 권한:
- 운영 서버 설정 수정
- 저장소 밖 개인 파일 접근
- 임의 네트워크 연결
경계가 없으면 에이전트는 선의로 잘못 갑니다. 배포 설정을 고치는 게 가장 빠른 해결책처럼 보이면 그대로 실행합니다. 에이전트 입장에서는 합리적이지만, 개발자가 준 권한을 넘은 행동입니다. 결과는 운영 사이트 장애입니다.
MXC의 답은 단순합니다. 저장소는 읽고 쓰게, 서버 설정은 읽기만, 나머지는 주지 않는다. 에이전트가 설정을 고치려 하면 모델·생성 코드·플러그인·도구가 뭐라고 하든 막는다. 권한은 에이전트가 아니라 밖에서 정합니다.
MXC란: 정책은 JSON으로, 강제는 OS로
MXC는 신뢰할 수 없는 코드나 동적 생성 워크로드를 위한 정책 기반 실행층입니다. 에이전트 시나리오에서는 모델 출력물, 플러그인, 도구, 하네스, 심지어 에이전트 전체를 감쌀 수 있습니다.
개발자가 선언 (JSON 정책 + SDK):
"이 작업은 이 파일과 이 네트워크만 쓴다"
MXC가 강제 (런타임):
Windows → AppContainer
macOS → Seatbelt
Linux → Bubblewrap (등, 백엔드별 매핑)
정책은 워크로드 밖에 있다
→ 에이전트가 스스로 권한을 늘릴 수 없다
개발자는 통합 JSON 스키마 하나만 씁니다. 플랫폼별 격리 디테일은 MXC가 백엔드에 매핑합니다. 로컬 기기부터 클라우드까지 같은 containment 모델을 쓴다는 게 공식 설명이고, Windows 365 지원도 이번에 정식 제공에 포함됐습니다.
격리 고르기: 네 단계 스펙트럼
작업마다 필요한 격리가 다릅니다. 저장소에서 코딩하는 에이전트는 낮은 지연을 원하고, 민감 데이터를 다루는 에이전트는 강한 격리를 원합니다.
| 백엔드 | 제공 범위 | 어울리는 일 | 특징 |
|---|---|---|---|
| Process 컨테이너 | Windows 11·macOS·Linux | 가벼운 격리, 모델 생성 코드·도구 실행 | AppContainer / Seatbelt / Bubblewrap |
| Session 컨테이너 | Windows 11 전용 | 오래 도는 에이전트, 데스크톱 필요 작업 | 별도 Windows 계정·세션, 데스크톱·클립보드·UI·입력 분리 |
| WSL 컨테이너 | Windows 11 전용 | Linux 도구 체인 | WSL 경유 Linux 실행 환경 |
| MicroVM | Windows 11·Linux, 실험적 | 고위험 작업 | 하드웨어 기반 가상화 경계 |
Session 컨테이너만 Windows 전용이라는 점, MicroVM은 아직 실험적이라는 점을 구분해서 읽으세요. 전부 똑같이 쓸 수 있는 게 아니라 작업 위험도에 따라 고르는 스펙트럼입니다.
정책 다섯 영역: 파일·네트워크가 핵심
웹사이트 예시로 돌아옵니다. MXC 정책이 가르는 다섯 영역입니다.
| 영역 | 정하는 것 |
|---|---|
| Containment | 어떤 격리에서 도는가 (프로세스·세션 등) |
| Process | 명령·인자·작업 디렉터리·환경 |
| File system | 수정 가능 / 읽기 전용 / 접근 금지 위치 |
| Network | 인바운드·아웃바운드, 루프백 경유 여부 |
| User interface | 데스크톱·UI 자원 접근 여부 |
Copilot의 기본값이 감을 잡게 해줍니다. 샌드박스를 켜면 현재 작업 디렉터리는 읽기·쓰기, 나머지 시스템은 대체로 읽기 전용이거나 접근 불가입니다. 셸 명령과 기본 로컬 MCP·언어 서버는 경계 안에서 돕니다. 내장 파일 도구는 하네스 안에서 정책을 검사하고, 원격 MCP 서버는 로컬 프로세스 샌드박스 밖에 있어 연결 정책만 검사합니다. 경계 안과 밖을 나눠 생각해야 한다는 뜻입니다.
조직 정책과 합치기: Intune이 곧 온다
MXC의 설계가 좋은 지점은 개발자 선언과 조직 제약을 분리한 것입니다.
개발자 정책: "이 에이전트 작업에 이런 자원이 필요하다"
조직 정책 (Intune, 곧 제공): "우리 회사는 이 범위를 넘지 않는다"
→ 같은 에이전트가 회사마다 다른 경계에서 돈다
→ 개발자가 회사 보안 상태를 앱에 하드코딩하지 않는다
조직 정책에 막히면 에이전트는 이렇게 행동해야 한다고 공식 문서가 못 박습니다. 조용히 실패하지 말고, 사용 가능 권한 안에서 못 끝냈다고 설명하거나, 사용자·관리자 조치를 요청하거나, 안전한 대안을 고르라는 것입니다. 침묵 실패 금지는 MCP 재인증 글에서 본 원칙과 같습니다.
처음부터 강제하지 마라: 세 가지 모드
최소 권한 정책을 처음부터 맞추긴 어렵습니다. 에이전트가 뭘 만질지 미리 다 모르니까요. Windows 프로세스 컨테이너는 에이전트 활동 보고서를 뽑아 정책 초안을 돕습니다.
| 모드 | 미승인 접근 | 보고서 | 용도 |
|---|---|---|---|
| Enforcement | 차단 | 없음 | 운영 정책으로 실행 |
| Learning | 차단 + 기록 | 있음 (JSON) | 실패 진단, 최소 권한 확인 |
| Permissive | 허용 + 기록 | 있음 | 정책 작성 중 관찰 |
권장 순서:
Permissive로 돌려본다 (뭘 만지는지 수집)
→ Learning으로 좁힌다 (차단되는 게 정당한지 확인)
→ Enforcement로 운영한다 (운영 정책 고정)
MXC에 처음 올리면 정당하게 필요한 것도 막힐 수 있습니다. 그 거부가 경계를 어디로 넓혀야 하는지 알려줍니다. 필요한 것만 열어주는 과정 자체가 설계입니다.
Copilot에서 켜기: /sandbox 한 줄
GitHub 발표는 짧습니다. Copilot CLI, Copilot 앱, Agent Host를 쓰는 VS Code 세션에서 로컬 샌드박싱이 정식 제공됩니다. MXC가 공통 샌드박스 정책을 Windows·macOS·Linux 네이티브 제어로 번역해 줍니다.
CLI에서:
/sandbox → 설정 열기
"Sandbox new sessions" 켜기 → 이 프로젝트의 새 세션은 기본 샌드박스
기본값:
현재 작업 디렉터리 = 읽기·쓰기
나머지 = 읽기 전용 또는 접근 불가
지원 현황도 정리해 둡니다. 이미 MXC를 쓰는 쪽은 Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio, Unsloth AI, NVIDIA OpenShell 등이고, Claude Code, Box, Egnyte, Manus, Perplexity, Raycast, Simular 등이 지원을 예고했습니다. Claude Code 사용자라면 "곧"이라는 단어를 기억해 두세요. 오늘 당장 되는 것과 로드맵을 구분하는 게 재검증의 기본입니다.
CodeBridge Mini Lab: 내 샌드박스 만들기
① 프로젝트 1개를 정한다 (에이전트가 만지는 저장소)
② 정책을 5줄로 쓴다:
[ ] 수정 가능: 저장소 경로 (읽기·쓰기)
[ ] 읽기 전용: 빌드 설정·운영 설정 (읽기만)
[ ] 접근 금지: 개인 문서·자격 증명 (~/.ssh, 토큰 파일 등)
[ ] 네트워크: 인바운드 차단, 아웃바운드는 필요한 곳만
[ ] UI: 데스크톱 접근 차단 (필요 없으면)
③ Permissive로 1회 실행 → 보고서에서 만진 자원 확인
④ Learning으로 좁히기 → 정당한 차단을 정책에 반영
⑤ Enforcement로 고정 → 회귀 테스트 1개 만들기
(에이전트가 금지 구역을 만지려 하면 막히는지)
실제 프로젝트 붙이기의 검증 루프에 샌드박스 한 줄을 추가하는 것입니다. 소스는 쓰게, 문서는 못 보게, 자격 증명은 건드리지 못하게. 그게 브리핑의 액션입니다.
결론: 자율성이 클수록 울타리가 먼저다
한 줄로 정리합니다.
에이전트에게 자유를 주기 전에 경계를 정하세요. 막힌 로그가 다음 정책이 된다.
MXC 정식 제공의 의미는 격리 기술 하나가 아닙니다. 에이전트 실행이 권한·신원·관리의 문제로 넘어왔다는 신호입니다. 신원은 곧 Entra와 Agent 365로, 관리는 Intune으로 이어집니다. 오늘은 작은 것부터 하세요. 작업 폴더만 쓰게 하고 나머지는 막는 샌드박스 하나. 그 울타리가 에이전트를 오래 쓸 수 있게 합니다.
함께 읽으면 좋은 글
참고 자료
- Microsoft: Microsoft Execution Containers — Policy-driven containment (Oct 7, 2026)
- GitHub Changelog: Local sandboxing for GitHub Copilot now GA (Oct 7, 2026)
- Microsoft Command Line: Local models and sandboxed tools (Oct 8, 2026)
- MXC Repository
이 주제를 직접 따라가며 배우고 싶다면
검증과 제약이 있는 개발 흐름으로 AI 코딩을 통제하는 연습이 필요하다면, Claude Code로 프로젝트 규칙과 권한 환경을 정리하는 과정이 이 글의 샌드박스 설계와 바로 이어집니다.