Microsoft Execution Containers: AI 에이전트를 위한 정책 기반 격리

에이전트는 고객에게 엄청난 생산성 향상을 가져다주고 있지만, 파일, 네트워크 및 애플리케이션 전반에서 작동하는 능력은 새로운 보안 위험을 초래할 수 있습니다. 이로 인해 고객들은 마치 두 가지 선택지밖에 없는 것처럼 느끼게 될 수 있습니다. 즉, 에이전트에게 무제한 액세스를 허용하고 아무 일도 일어나지 않기를 바라거나, 아니면 에이전트를 차단하여 그들이 제공하는 생산성 향상 혜택을 잃는 것입니다. 어느 쪽도 받아들일 수 없습니다.

그래서 우리는 에이전트를 더 안전하게 실행하고 관리할 수 있도록 Windows 플랫폼 기능을 구축하고 있으며, 다음 기능부터 시작합니다:

격리(Containment): 에이전트가 액세스하고 수행할 수 있는 것을 제한하는 것.
신원(Identity): 에이전트의 활동을 사람의 활동과 구별하는 것.
관리 용이성(Manageability): 조직에 액세스를 관리하고 에이전트 활동을 모니터링하는 도구를 제공하는 것.

이제 일반적으로 사용 가능한 **Microsoft Execution Containers (MXC)**는 격리 계층을 제공합니다. 개발자와 IT 관리자는 에이전트가 사용할 수 있는 파일 및 네트워크 대상과 같은 리소스를 정의하고, MXC는 적절한 컨테이너를 사용하여 런타임에 이러한 정책을 강제합니다.

Windows는 또한 Microsoft Entra가 에이전트 활동을 사용자 활동과 구별하는 데 도움을 주어, 에이전트 액세스 제한이 필요할 때도 사용자가 생산성을 유지할 수 있도록 할 것이며, IT 팀이 MXC 컨테이너를 관리하고, 정책을 적용하며, 에이전트 활동을 모니터링할 수 있도록 Microsoft Agent 365 제어를 온디바이스 로컬 에이전트로 확장할 것입니다.

에이전트가 관리되는 실행 경계가 필요한 이유

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

웹사이트를 업데이트하도록 요청받은 코딩 에이전트를 생각해 봅시다. 이 에이전트는 웹사이트 저장소에 읽기 및 쓰기 액세스가 필요하며, 변경 사항을 빌드하고 테스트하는 데 필요한 개발 도구에 대한 액세스도 필요합니다. 애플리케이션 배포 방식을 이해하기 위해 프로덕션 서버 구성 파일을 읽어야 할 수도 있지만, 그 구성을 수정할 수는 없어야 합니다.

관리되는 실행 경계(managed execution boundary)가 없다면, 에이전트는 서버 구성을 변경하는 것이 작업을 완료하는 가장 빠른 방법이라고 판단하고 프로덕션 사이트를 손상시킬 수 있습니다. 이러한 행동은 에이전트의 관점에서는 합리적일 수 있지만, 개발자가 부여하고자 했던 권한을 초과할 수 있습니다.

격리(Containment)는 바로 그러한 관리되는 경계를 생성합니다: 에이전트는 저장소(repository)를 읽고 쓸 수 있고, 서버 구성을 읽을 수는 있지만, 접근 권한이 부여되지 않은 다른 것은 아무것도 할 수 없습니다. 만약 에이전트가 서버 구성을 수정하려고 시도하더라도, 격리 환경은 모델, 생성된 코드, 플러그인 또는 도구가 무엇을 결정하든 관계없이 해당 작업을 방지하도록 설계되었습니다.

Microsoft Execution Containers (MXC)란 무엇인가?

Microsoft Execution Containers (MXC)는 신뢰할 수 없는 코드(untrusted code)나 동적으로 생성된 워크로드에 대한 정책 기반 실행 계층입니다. 에이전트 시나리오에서 개발자는 MXC를 사용하여 모델이 생성한 출력, 플러그인, 도구, 에이전트 하네스 또는 전체 에이전트를 격리할 수 있습니다. 이는 무언가 잘못되었을 경우의 영향 범위를 제한하여 에이전트 워크로드가 접근할 수 있는 것을 제한합니다.

개발자는 파일 및 네트워크 목적지 등 워크로드에 필요한 리소스를 선언하고, MXC는 적절한 컨테이너를 통해 그 결과 경계를 강제합니다. 정책은 에이전트 워크로드의 통제를 벗어나기 때문에, 에이전트나 생성된 코드가 스스로 추가적인 접근 권한을 부여할 수 없습니다.

MXC는 또한 워크로드 요구 사항과 플랫폼별 격리 세부 사항을 분리하여 개발자 경험을 크게 단순화합니다. 개발자는 통합 JSON 구성 스키마와 다중 언어 SDK로 통합하며, MXC는 요청된 제어를 Windows, macOS 또는 Linux의 선택된 백엔드에 매핑합니다.

개발자는 에이전트가 실행되어야 하는 모든 곳—로컬 장치부터 클라우드까지—동일한 격리 모델을 적용할 수 있습니다. Windows 365에서 MXC 지원이 일반적으로 사용 가능해지면서, 개발자들은 Cloud PC에서 기존 작업과 함께 에이전트를 실행하며, 적절한 격리 모델을 사용하여 에이전트 실행을 분리하고 안전하게 유지하는 데 도움을 받을 수 있습니다.

워크로드에 맞는 격리 수준 선택하기

다양한 워크로드는 서로 다른 수준의 격리를 필요로 합니다. 저장소에서 작업하는 코딩 에이전트는 낮은 지연 시간과 응답성을 우선시할 수 있지만, 민감한 데이터를 처리하거나 신뢰할 수 없는 코드를 실행하는 에이전트는 더 강력한 격리가 필요할 수 있습니다. MXC는 개발자와 조직이 각 워크로드에 맞는 적절한 수준의 격리를 선택할 수 있도록 다양한 격리 옵션을 제공합니다.

세션 컨테이너(Session container)는 Windows에서만 지원되며, 사용자 장치에서 별도의 OS 격리 세션으로 에이전트를 실행하고 자체 로컬 에이전트 ID와 격리된 데스크톱, 클립보드, UI 및 입력 경계를 갖습니다.

하드웨어 기반 격리 및 완벽한 Linux 워크로드 호환성을 제공합니다.

각 컨테인먼트 백엔드는 고유한 보안 속성을 가지므로, 워크로드는 해당 컨테인먼트 백엔드와의 적합성에 따라 평가되어야 합니다.

MXC 정책이 워크로드 경계를 정의하는 방법

MXC는 사용자 및 조직이 에이전트에게 더 많은 작업을 위임하도록 돕는 동시에, 각 작업에 필요한 리소스로 제한할 수 있게 해줍니다. 개발자와 IT 부서는 에이전트에게 로그인한 사용자의 전체 권한을 부여하는 대신, 에이전트의 워크로드 주변에 OS가 강제하는 경계를 정의할 수 있습니다.

웹사이트 시나리오의 경우, MXC 정책은 코딩 에이전트에게 로컬 소스 코드 저장소에 대한 읽기 및 쓰기 액세스와 Git과 같은 필요한 개발 도구에 대한 액세스를 부여하는 동시에, 사용자의 문서 폴더와 같은 개인 위치에 대한 액세스는 차단할 수 있습니다. 이 정책은 또한 인바운드 및 아웃바운드 네트워크 연결과 대화형 데스크톱에 대한 액세스도 차단할 수 있습니다.

MXC 지원을 추가하는 것은 에이전트 개발자에게 간단합니다. 좋아하는 코딩 에이전트를 사용하여 MXC SDK를 통합하고 초기 워크로드 정책 초안을 작성한 다음, 결과적인 제어를 검토, 테스트 및 개선할 수 있습니다.

워크로드와 조직 정책의 결합 방식

에이전트 개발자는 자신들의 에이전트 워크로드가 필요로 할 수 있는 리소스를 선언합니다. 조직은 또한 Microsoft Intune 관리 정책과 같은 관리 정책을 통해 추가적인 제약 조건을 적용할 수도 있습니다. 이를 통해 동일한 에이전트가 에이전트 개발자가 조직의 보안 태세를 애플리케이션에 인코딩할 필요 없이 서로 다른 엔터프라이즈 경계 내에서 작동할 수 있게 합니다.

조직이 일관되게 격리를 적용할 수 있을 때 컨테인먼트는 더욱 가치가 높아집니다. Intune 정책은 곧 Windows 11의 MXC 통합 에이전트가 사용하는 MXC 프로세스 컨테이너를 관리하는 데 사용할 수 있게 됩니다. 이러한 정책은 IT 관리자에게 에이전트에 의해 생성된 컨테이너 생성 요청을 Windows가 어떻게 평가할지, 그리고 해당 컨테이너에 의해 강제되는 리소스 경계에 대한 통제권을 제공할 것입니다.

에이전트 개발자는 자신들의 워크로드가 기본 구성보다 더 제한적일 수 있는 경계 내에서 작동하도록 설계해야 합니다. 조직 정책이 특정 리소스를 차단하는 경우, 에이전트는 해당 작업이 사용 가능한 권한 내에서 완료될 수 없음을 설명하고, 지원되는 경우 적절한 사용자 또는 관리자 조치를 요청하거나, 안전한 대안을 선택해야 합니다. 침묵적으로 실패해서는 안 됩니다.

정책 적용 전 관찰 및 개선하기

에이전트 워크로드가 요구하는 모든 리소스를 아직 알지 못할 때 최소 권한(least privilege) 정책을 작성하는 것은 어려울 수 있습니다. Windows에서만 MXC 프로세스 컨테이너는 워크로드가 사용하려고 시도한 리소스를 보여주는 에이전트 활동 보고서(agent activity report)를 생성하여 최소 권한 정책을 만드는 데 도움을 줄 수 있습니다.

MXC는 세 가지 운영 모드를 지원합니다:

강제(Enforcement) 모드에서는 MXC가 활동 보고서 없이 정책을 적용합니다. 허용된 작업은 진행되며, 경계 외부의 작업은 제한됩니다.

학습(Learning) 모드에서는 MXC가 구성된 경계를 계속해서 강제합니다. 허용되지 않은 작업은 차단되고 JSON 활동 보고서에 기록됩니다. 이를 통해 개발자나 IT 담당자는 격리 실패 사례를 재현하고 워크로드가 접근을 시도한 리소스를 이해할 수 있습니다.

허용적(Permissive) 모드에서는 정책이 거부했을 접근을 기록하지만 작업을 계속 진행하도록 허용합니다. 이는 정책 작성 중에 유용하며, 개발자나 IT 담당자가 워크로드의 사용 리소스에 대한 증거를 수집하는 동안 작업이 완료될 수 있게 합니다. 허용적 모드는 다른 적용 가능한 운영 체제 또는 조직 제한을 우회하지는 않습니다.

에이전트를 MXC 컨테이너로 처음 가져올 때, 정책이 워크로드에게 실제로 필요한 기능을 차단할 수 있습니다. 이러한 거부는 경계가 조정되어야 할 곳을 알려주어, 에이전트의 범위를 불필요하게 확장하지 않으면서 필요한 접근 권한을 부여하는 데 도움을 줍니다.

에이전트 식별 및 출처(Agent identity & attribution)

격리(Containment)는 에이전트가 무엇을 할 수 있는지에 대한 답입니다. 식별(Identity)은 어떤 에이전트가 특정 작업을 수행했는지 판단하는 데 도움을 줍니다. 곧 Windows에서는 Microsoft Entra를 통해 Microsoft Agent 365에서 에이전트 활동과 사용자 활동을 구별할 수 있게 될 것입니다.

이러한 분리는 보안 팀이 장치 사용자와는 독립적으로 에이전트의 동작과 위험도를 평가할 수 있도록 할 것입니다. 만약 에이전트가 손상되거나 정책을 위반하더라도, 보안 제어는 직원의 접근을 차단하지 않으면서 보호된 리소스에 대한 에이전트의 접근만 목표로 삼게 됩니다. 조직이 더 많은 에이전트를 배포함에 따라, 오작동하는 하나의 에이전트가 직원의 접근이나 생산성을 방해할 필요가 없습니다.

에이전트 수준의 기여도(attribution) 역시 조사 및 거버넌스를 개선합니다. 관리자는 Agent 365를 사용하여 어떤 에이전트가 실행 중인지 파악하고, 활동을 특정 에이전트에 연결하며, 위험한 동작을 조사하고, 사용자 수준이나 장치 수준의 컨텍스트에만 의존하는 대신 개별 에이전트 또는 에이전트 그룹에 정책을 적용할 수 있습니다.

MXC를 사용하는 현재 에이전트들

NVIDIA는 OpenShell을 MXC에 통합하여, 파일 및 추론 서비스에 대한 에이전트 접근 제어 정책(policy controls)과 고급 네트워크 제어, 자격 증명 관리, 그리고 기업의 경우 OCSF 감사 기능을 통해 MXC를 보완했습니다.

GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, Unsloth AI를 포함하여 주요 에이전트 및 에이전트 프레임워크들이 이미 MXC를 지원합니다. Anthropic Claude Code, Box, Egnyte, Heidi Health, Nous Research의 Hermes Agent, Manus, Perplexity, Raycast, Simular 등 다른 많은 서비스들도 MXC 지원을 출시할 예정입니다. 매일 AI를 사용하는 사람들에게 이러한 안전장치들은 에이전트 경험 자체의 일부가 되어 사용자들에게 이러한 도구들을 더 안전하게 사용할 수 있는 방법을 제공합니다.