마이크로소프트(Microsoft)가 AI 에이전트(Agent)의 안전한 실행 환경을 구축하기 위한 새로운 프레임워크를 공개했다. ‘윈도우 AI 에이전트를 위한 플랫폼 보안(Windows platform security for AI agents)’이라는 제목의 윈도우 개발자 블로그 게시물을 통해 마이크로소프트는 마이크로소프트 실행 컨테이너(Microsoft Execution Containers, MXC) SDK를 핵심 전략으로 제시했다. 이 SDK는 에이전트가 접근할 수 있는 자원을 정책으로 정의하고, 운영체제(OS) 수준에서 격리·신원 관리·감사 추적을 제공해 대규모 AI 에이전트 배포를 안전하게 가능하게 하겠다는 것이다. 격리(Containment), 신원(Identity), 관리 가능성(Manageability)을 운영체제의 기초 요소로 내재화한다는 선언이다.
MXC의 작동 방식은 다음과 같다. 개발자는 에이전트가 접근할 수 있는 자원 범위를 JSON 또는 타입스크립트(TypeScript) SDK로 기술하면, 윈도우가 이를 바탕으로 프로세스 격리 또는 세션 격리를 적용한다. 위험도가 높은 작업에는 마이크로 가상머신(micro-VM)을, 리눅스(Linux) 도구체인이 필요한 환경에는 리눅스 컨테이너를 활용하는 계획도 담겼다. 또한 윈도우 365(Windows 365)와 연동해 일부 에이전트 작업 부하를 클라우드 PC에서 실행하는 통합도 예정되어 있다. IT 팀은 MXC 정책을 엔트라 ID(Entra ID)와 인튠(Intune)으로 중앙 관리할 수 있고, 디펜더(Defender)와 퍼뷰(Purview)가 프롬프트 인젝션(prompt injection) 등 에이전트 특유의 위협으로부터 보호·감사 추적을 제공한다. 에이전트에게는 별도 신원을 부여하고, 최소 권한 원칙과 프록시 경유 도구 호출이 적용된다.
마이크로소프트는 MXC가 시큐어 부트(Secure Boot), 패스워드리스 로그인, 핫패칭(Hotpatching), 메모리 안전 드라이버, 포스트-퀀텀 암호화(Insider 빌드에 포함) 등 기존 윈도우 보안 투자의 연장선상에 있다고 설명한다. 에이전트가 이 안전한 기반을 그대로 물려받는 구조라는 것이다. 업계 분석가들은 MXC가 단일 설정과 SDK 뒤에 여러 격리 백엔드를 추상화한 구조적 장점을 주목한다. 마이크로소프트가 AI 에이전트와 인간 모두를 위한 통제된 런타임으로 윈도우를 재정의하는 시도의 일환이라는 해석도 나온다. 마이크로소프트 Build 2026에서 발표된 AI 에이전트 전략과 연결해 보면, MXC는 그 구체적 실행 수단에 해당한다.
그러나 초기 반응은 상당히 조심스럽다. 기술 분석 사이트 바이트아이오타(byteiota.com)는 MXC 정책 스키마가 윈도우·리눅스·맥OS(macOS) 모두에서 실행될 것으로 설계됐지만 맥OS 지원은 아직 실험 단계라고 지적한다. 더 중요한 것은 마이크로소프트 자체 문서가 “MXC 프로파일을 아직 보안 경계(security boundary)로 취급해서는 안 된다”고 경고하고 있다는 점이다. 과도하게 허용적인 정책이 남아 있고, 아웃바운드 네트워크 필터링이 아직 작동하지 않는다는 알려진 문제도 있다. 에이전트 침해는 종종 데이터 유출로 나타나는 만큼, 네트워크 필터링 부재는 특히 심각한 빈틈이다.
AI 에이전트 보안을 둘러싼 경쟁은 윈도우 생태계 밖에서도 활발하다. 엔비디아(NVIDIA)의 오픈소스 런타임 오픈셸(OpenShell)은 자율 에이전트를 위한 안전하고 프라이빗한 런타임으로, 샌드박스 런타임 제어와 선언적 정책을 결합해 무단 파일 접근·데이터 유출·무통제 네트워크 활동을 막는다. 레드햇(Red Hat)은 AI 플랫폼과 오픈셸의 통합, 컨피덴셜 컨테이너, SELinux 기반 집행을 하이브리드 클라우드 시스템의 제로 트러스트(zero-trust) 모델로 묶어 발표했다. 쿠버네티스(Kubernetes) 생태계에서는 에이전트 샌드박스 컨트롤러(Agent Sandbox Controller)가 gVisor와 카타 컨테이너(Kata Containers)를 이용해 신뢰할 수 없는 에이전트 코드를 강화된 파드에서 격리한다. 리눅스 네이티브 방식으로는 가디언 셸(Guardian Shell)이 Landlock·seccomp·eBPF 훅을 조합해 에이전트 코드 변경 없이도 커널 수준의 정책을 적용한다. AI 에이전트 보안 샌드박스 기술 비교에서 볼 수 있듯, 플랫폼별 접근 방식은 크게 달라도 지향점은 같다 — 에이전트 행동을 예측 가능하게 통제하는 것이다.
이 경쟁 구도는 표준화 측면에서 중요한 함의를 갖는다. 현재 AI 에이전트 보안에서 지배적인 단일 플랫폼 모델은 없다. 윈도우 MXC, 엔비디아 오픈셸, 리눅스 커널 기반 샌드박스, 클라우드 마이크로VM 등 여러 접근이 공존하며 각자 강점과 약점이 있다. 기업들은 자신의 인프라, 에이전트의 위험도, 운영팀의 역량에 따라 다른 선택을 해야 하는 상황이다. 윈도우 MXC의 장점은 기존 엔터프라이즈 윈도우 관리 도구와의 통합이지만, 리눅스 기반 솔루션들은 더 성숙한 커널 수준 격리를 제공한다. 한쪽 솔루션이 모든 요구를 충족하기까지는 시간이 필요하다.
한국 기업과 개발자 입장에서도 이 흐름을 주목해야 할 이유가 있다. AI 에이전트를 실제 업무에 도입하려는 기업들이 늘어나는 상황에서, ‘에이전트가 무엇을 할 수 있는가’보다 ‘에이전트를 얼마나 안전하게 통제할 수 있는가’가 도입 결정의 핵심 변수가 되고 있다. 마이크로소프트의 엔터프라이즈 생태계를 이미 사용하는 기업이라면 MXC 기반 접근이 자연스러운 출발점이 될 수 있다. 그러나 현재 MXC가 완성된 보안 경계가 아니라는 마이크로소프트 자체의 경고를 고려하면, 고위험 업무 환경에 섣불리 도입하기보다 파일럿 수준에서 역량과 한계를 먼저 검증하는 접근이 현명하다. AI 에이전트 엔터프라이즈 도입 보안 가이드를 참고해 단계적 검토를 권장한다.
AI 에이전트의 가치는 무엇을 할 수 있느냐뿐 아니라 프로덕션 환경에서 얼마나 신뢰받을 수 있느냐에 달려 있다. MXC가 이 신뢰 기반을 실제로 구축할 수 있을지는 현재 진행 중인 프리뷰 단계에서의 반응과 독립 보안 감사 결과에 달려 있다. 마이크로소프트 외의 플랫폼에서도 비슷한 방향의 기술들이 경쟁적으로 성숙해 나가고 있는 만큼, 향후 1~2년이 AI 에이전트 보안 표준이 실질적으로 자리 잡히는 결정적 시기가 될 것으로 보인다.
