Windows Agent Runtime — Microsoft가 에이전트 샌드박싱(Agent Sandboxing)에 대해 올바르게 접근한 방식

OS가 에이전트 플랫폼이 되었습니다

Build 2026에서 Microsoft는 프로덕션 AI 에이전트를 운영하는 모든 이들에게 가장 중요한 발표를 했습니다: Windows가 퍼스트 클래스 에이전트 런타임(first-class agent runtime)이 됩니다. 단순히 에이전트를 실행하는 앱이 아닙니다. 옆에 덧붙여진 컨테이너 오케스트레이터(container orchestrator)도 아닙니다. 운영체제(OS) 자체가 이제 에이전트가 무엇인지, 무엇을 할 수 있는지, 그리고 언제 차단해야 하는지를 이해합니다.

저는 1년 넘게 Windows에서 멀티 에이전트 플랫폼을 운영해 왔습니다 — 가족의 일정부터 콘텐츠 파이프라인까지 모든 것을 관리하는 50개 이상의 에이전트를 운영 중입니다. 따라서 Microsoft가 에이전트를 위한 OS 수준의 샌드박싱(sandboxing)을 발표했을 때, 저는 단순한 기능 발표를 평가하는 것이 아니었습니다. 제가 이미 고생하며 구축한 시스템과 비교하며 노트를 대조하고 있는 것입니다.

여기서 그들이 무엇을 제대로 했는지, NVIDIA의 경쟁 방식이 설계 공간(design space)에 대해 무엇을 드러내는지, 그리고 여전히 가장 중요한 격차는 무엇인지 설명하겠습니다.

권한 부여 모델 (Capability Grant Model) — 에이전트를 위한 모바일 권한

Windows Agent Runtime은 파일 시스템 범위(file system scope), 네트워크 액세스(network access), 애플리케이션 실행 권한(application launch permissions)의 세 가지 차원을 아우르는 **에이전트별 권한 부여 시스템(per-agent capability grant system)**을 제공합니다. 사용자는 설치 중에 이러한 권한을 승인하며, 이는 모바일 앱의 권한 대화 상자와 유사합니다.

이것이 올바른 추상화(abstraction)입니다.

저의 hookflow 거버넌스 계층(hookflow governance layer)을 포함하여 제가 접한 모든 프로덕션 에이전트 시스템은 결국 동일한 통찰에 도달합니다: 에이전트에게는 행동에 대한 신뢰(behavioral trust)가 아니라 선언적 권한 경계(declarative permission boundaries)가 필요하다는 점입니다. 에이전트가 올바르게 행동할 것이라고 믿지 마십시오. 에이전트가 할 수 있는 일을 제한한 다음, 경계(boundary)에서 검증하십시오.

저의 플랫폼인 hookflows는 관점 지향적 가로채기 (aspect-oriented interception)를 통해 이 패턴을 강제합니다. 모든 도구 호출 (tool call)은 거버넌스 규칙을 평가하는 실행 전 훅 (pre-execution hooks)을 통과합니다. dev-guard 훅플로우 (hookflow)는 가공되지 않은 git 명령어를 차단하고 관리되는 개발 워크플로우 도구를 강제합니다. safe-content-write 훅플로우는 에이전트가 PowerShell을 통해 대용량 파일을 쓰는 것을 방지합니다. 에이전트가 준수 여부를 결정하는 것이 아니라, 시스템이 불이행을 불가능하게 만듭니다.

Microsoft의 권한 부여 (capability grant) 모델도 OS 계층에서 동일한 작업을 수행합니다. 파일 범위가 %USERPROFILE%\Documents\ProjectA로 제한된 에이전트는 물리적으로 해당 경로 외부의 파일에 접근할 수 없습니다. 커널 (kernel)이 이를 강제하기 때문입니다. 그 어떤 프롬프트 인젝션 (prompt injection)이나 혼동된 대리인 공격 (confused-deputy attacks)도 이 경계를 바꿀 수 없습니다.

그들이 옳았던 점: 권한 부여를 선언적 (declarative)으로 만들고 설치 시점에 사용자가 볼 수 있게 한 것입니다. 이는 더 위험한 범주의 소프트웨어에 대해 모바일 권한 방식이 올바르게 적용된 사례입니다.

Windows Agent Runtime이 OS 수준에서 에이전트별 권한 부여를 강제하는 방식 — 커널이 불이행을 불가능하게 만듭니다

NVIDIA OpenShell과의 비교

NVIDIA의 OpenShell 또한 동일한 근본적인 통찰, 즉 에이전트에게는 행동에 대한 약속이 아니라 시스템 수준의 격리 (containment)가 필요하다는 점을 취하여, OS 통합 대신 컨테이너 격리 (container isolation)를 통해 이를 적용합니다.

OpenShell의 아키텍처는 시사하는 바가 큽:

• 이중 프로세스 컨테이너 (Dual-process containers): 권한을 가진 감독 프로세스 (privileged supervisor)가 격리 경계 (isolation boundary)를 설정합니다. 권한이 없는 에이전트 프로세스 (unprivileged agent process)는 그 내부에서 실행됩니다. 에이전트는 호스트 시스템을 직접 절대 볼 수 없습니다.
• 선언적 YAML 정책 (Declarative YAML policies): 정적 정책 (파일 시스템, 프로세스)은 샌드박스 생성 시점에 고정됩니다. 동적 정책 (네트워크, 추론 라우팅)은 런타임 (runtime) 중에 업데이트될 수 있습니다. 이는 설치 시 권한 부여 (install-time grants)와 런타임 거버넌스 (runtime governance) 사이의 구분을 반영합니다.
• 도구 호출별 평가 (Per-tool-call evaluation): 정책 엔진은 실행이 진행되기 전에 선언된 정책에 따라 각 도구 호출 (tool invocation)을 평가합니다. 이는 기능적으로 제가 사용하는 hookflow onPreToolUse 패턴과 동일합니다.

핵심적인 차이점: OpenShell은 인프라 수준 (infrastructure-level)이며, Windows Agent Runtime은 OS 수준 (OS-level)입니다.

OpenShell은 Linux 컨테이너가 실행되는 곳이라면 어디에서든 실행됩니다. 이는 이식성이 있고, 조합 가능하며 (composable), 특정 운영 체제를 요구하지 않습니다. 반면 Windows Agent Runtime은 Windows 커널, Entra ID, 그리고 Microsoft Store 배포 파이프라인과 깊게 통합되어 있습니다.

이미 Windows 생태계에 전념하고 있는 기업들에게는 OS 수준의 접근 방식이 배포 마찰 (deployment friction) 측면에서 승리합니다. 멀티 클라우드나 Linux 중심의 환경을 가진 곳에는 OpenShell의 컨테이너 모델이 더 실용적입니다. 저와 같이 Windows 워크스테이션에서 매일 에이전트 시스템을 실행하는 개발자들에게, Windows Agent Runtime은 제가 현재 애플리케이션 계층 거버넌스 (application-layer governance)를 통해 해결하고 있는 문제들을 다루면서도, 스택의 더 낮고 더 신뢰할 수 있는 계층에서 이를 처리해 줍니다.

에이전트 격리(agent containment)에 대한 세 가지 접근 방식: OS 수준의 권한 부여 (capability grants), 컨테이너 격리 (container isolation), 그리고 애플리케이션 계층의 행동 거버넌스 (behavioral governance) — 각각은 뚜렷한 트레이드오프 (trade-offs)를 가집니다.

동적 프로필 (Dynamic Profiles) 및 자격 증명 주입 (Credential Injection) — 진정한 혁신

여기서부터 아키텍처가 흥미로워집니다. Windows Agent Runtime 프리뷰 문서는 동적 기능 프로필 (dynamic capability profiles)을 설명합니다. 이는 재설치 없이 현재 작업 컨텍스트 (task context)에 따라 에이전트의 권한 범위 (permission scope)를 조정할 수 있는 능력입니다.

이는 저의 하네스 엔지니어링 관행 (harness engineering practice)에서 제가 **문맥적 거버넌스 (contextual governance)**라고 부르는 패턴과 일치합니다. 서로 다른 에이전트는 서로 다른 시점에 서로 다른 권한을 필요로 합니다. 콘텐츠 작성 에이전트는 글을 쓰는 동안 블로그 저장소 (repo)에 대한 파일 시스템 접근 권한이 필요하지만, 외부 소스만 읽는 조사 단계에서는 해당 접근 권한을 상실해야 합니다. 금융 에이전트는 청구서 처리 중에 은행 통합 서비스에 대한 API 접근 권한이 필요하지만, 일상적인 대화 중에는 해당 자격 증명 (credential)이 절대 범위 (scope) 내에 있어서는 안 됩니다.

저의 시스템에서는 이를 프록시 계층 자격 증명 주입 (proxy-layer credential injection)을 통해 처리합니다. 에이전트는 자격 증명을 직접 보유하지 않습니다. 확장 계층 (extension layer)이 에이전트의 현재 선언된 범위 (declared scope)를 기반으로 호출 시점에 자격 증명을 주입합니다. 만약 훅플로우 (hookflow)가 에이전트가 현재 특정 서비스에 접근해서는 안 된다고 판단하면, 자격 증명은 단순히 주입되지 않으며 — 에이전트는 호출을 시도조차 할 수 없습니다.

Microsoft의 접근 방식은 이 개념을 운영체제 (OS) 수준으로 가져옵니다:

• Entra ID 통합: 에이전트 ID는 Microsoft의 ID 플랫폼을 통해 관리되며, 현재 작업에 범위가 제한된 단기 토큰 (short-lived tokens scoped to the current task)을 사용합니다.
• Intune 정책 강제 (policy enforcement): 기업 관리자는 장치 관리에 사용하는 것과 동일한 MDM 도구를 통해 에이전트 권한 경계 (permission boundaries)를 정의합니다.
• 자동 환경 정리 (Automatic environment cleanup): Windows 365 for Agents는 작업이 완료되면 토큰, 캐시된 데이터 및 세션 상태 (session state)를 자동으로 파기합니다.

이것은 자격 증명 주입 (credential injection)이 플랫폼 기본 요소 (platform primitive)로 격상된 것입니다. 각 에이전트 플랫폼이 자체적인 보안 자격 증명 관리 (제가 확장 계층 주입 (extension-layer injection)을 통해 수행하는 방식처럼)를 구현하는 대신, OS가 이를 네이티브로 제공합니다.

여전히 부족한 점 — 거버넌스의 공백 (The Governance Gap)

Microsoft는 샌드박싱 (sandboxing)을 완벽하게 해냈습니다. 권한 부여 (capability grants)를 올바르게 처리했습니다. 자격 증명 주입 모델도 견고합니다. 하지만 결정적인 공백이 하나 있습니다. 바로 런타임 행동 거버넌스 (runtime behavioral governance) 입니다.

샌드박싱은 에이전트가 무엇에 접근할 수 있는지를 알려줍니다. 하지만 에이전트가 그 접근 권한을 가지고 무엇을 '해야 하는지'는 알려주지 않습니다. 정당한 파일 시스템 권한을 가진 에이전트라도 운영 환경의 설정 파일 (production config)에 쓰레기 데이터를 작성할 수 있습니다. 네트워크 접근 권한이 있는 에이전트는 비즈니스 로직을 위반하는 API 호출을 여전히 수행할 수 있습니다. 애플리케이션 실행 권한이 있는 에이전트는 여전히 비상식적인 방식으로 소프트웨어와 상호작용할 수 있습니다.

이 지점이 바로 제 시스템에서 hookflows와 턴별 평가 (per-turn evaluation)가 공백을 메우는 부분입니다. "이 에이전트가 이 리소스에 접근할 수 있는가?"를 넘어, 저는 "현재 컨텍스트를 고려할 때, 이러한 특정 파라미터를 가진 이 특정 동작이 허용 가능한가?"를 강제합니다.

제 운영 플랫폼의 예시:

• calendar-date-guard 훅플로우 (hookflow)는 계산된 날짜가 에이전트가 주장하는 요일과 일치하지 않을 때 캘린더 이벤트 생성을 차단합니다.
• validate-email-urls 훅플로우는 본문의 URL 중 하나라도 200 상태 코드가 아닌 값을 반환하면 외부 이메일 발송을 차단합니다.
• linkedin-brand-safety 훅플로우는 제가 경쟁사 AI 도구를 사용한다고 주장하는 모든 메시지를 방지합니다.

이 중 그 어느 것도 샌드박싱의 문제는 아닙니다. 에이전트는 캘린더 이벤트를 생성하고, 이메일을 보내고, LinkedIn에 게시할 권한을 가지고 있습니다. 거버넌스 계층 (governance layer)은 에이전트가 그 일들을 올바르게 수행하도록 보장합니다.

Microsoft의 Agent Governance Toolkit은 POSIX에서 영감을 받은 권한 기반 보안 (capability-based security)을 통해 이 문제의 일부를 해결합니다. 즉, 읽기, 쓰기, 실행 및 네트워크 액세스에 대한 명시적 허용 (explicit grants)과 위험한 도구 카테고리를 차단하는 엄격 모드 (strict mode)를 제공합니다. 하지만 이는 여전히 행동의 정확성 (behavioral-correctness) 수준이 아닌, 리소스 액세스 (resource-access) 수준에서 작동하고 있습니다.

다음 진화 단계는 명확합니다: OS 수준의 샌드박싱 (현재 존재하는 것)과 선언적 행동 거버넌스 (declarative behavioral governance, 여전히 애플리케이션 계층에 머물러 있는 것)의 결합입니다. 이 두 가지를 통합된 기본 요소 (primitives)로 제공하는 플랫폼이 승리할 것입니다.

거버넌스 격차 (The governance gap): 리소스 액세스와 자격 증명 (credentials)은 OS/인프라 계층에서 해결되지만, 행동의 정확성은 오늘날 훅 플로우 (hookflows)와 턴별 평가 (per-turn evaluation)만이 다룰 수 있는 애플리케이션 계층의 문제로 남아 있습니다.

이것이 에이전트 개발자에게 의미하는 바

현재 프로덕션 에이전트 시스템을 구축하고 있다면, 다음과 같은 실질적인 시사점이 있습니다: