在一篇题为“面向 AI 智能体的 Windows 安全”的 Windows 开发者博客文章中，微软将 Windows 定位为面向自治智能体的可信操作系统，并推出了微软执行容器(Microsoft Execution Containers，MXC) SDK 作为该策略的核心。文章主张应该在操作系统层面构建隔离机制、身份与可管理性，以便在大规模场景部署智能体时实现安全治理，该文描述了从进程与会话隔离到规划中的 microVM 与 Linux 容器的隔离谱系，所有这些均是由 MXC 策略驱动的。
MXC 被描述为 Windows 与 WSL 之上面向智能体的策略驱动执行层，用来抽象底层的隔离原语。开发者可以使用 JSON 或 TypeScript SDK 声明智能体可访问的资源，当智能体需要单独的桌面和标识时，Windows 会使用进程隔离来实现限制和会话隔离。对于高风险的工作，计划会通过 microVM 来提供支持，对依赖 Linux 的工具链，则支持 Linux 容器。此外，微软还计划将其集成到 Windows 365 中，以便在云 PC 上运行部分工作负载。IT 团队可通过 Entra ID 与 Intune 集中管理 MXC 策略，Defender 与 Purview 将提供保护、可观测性与智能体行为的审计轨迹。
“隔离、身份标识与可管理性作为 Windows 的基础原语进行构建，将安全扩展到超越应用与模型的操作系统层面。”
-- Dana Huang
文章认为，智能体模型可以植根于长期的安全投资，例如，Secure Boot、无密码登录、热修复补丁、内存安全驱动以及 Insider 构建中的后量子密码学。文章称，智能体可以继承这些安全基础，Defender 将增加针对提示词注入与其他智能体特有威胁的防护。该文强调了为智能体分配独立的身份标识、最低权限访问以及通过代理的工具调用。
行业报道关注到了 MXC 的结构化特征。CSO Online 的报道指出，MXC 在统一配置与 SDK 下提供了多种隔离后端。对 Microsoft Build 公告的独立分析则认为，将 MXC 纳入 Windows 与 WSL 是微软重塑操作系统的努力，使其既可供人类使用，也可以作为 AI 智能体的可控运行时。
早期的评论对于将 MXC 视为最终安全解决方案仍持谨慎态度。来自 byteiota.com 的技术评述指出，预计相同的策略模式将在 Windows、Linux 与 macOS 上运行，但对 macOS 的支持仍属实验性质。文章引用了微软文档中关于 MXC 配置目前不宜视为安全边界的警告，并强调了需要修正的已知过度宽松策略的案例。文中还指出，出站的网络过滤尚未到位，鉴于智能体攻破经常表现为以数据外泄的形式，这一点尤其重要。
“智能体的价值不只在于它能做什么，而在于它在生产环境中是否值得信任。”
-- Dana Huang
云提供商、Linux 发行商以及独立的项目也在推动针对其他平台的智能体安全性。在 Windows 生态之外，基于 Linux 的平台也在朝相似的方向发展，这个方向通常更强调内核级或硬件支持的隔离。NVIDIA 的开源运行时 OpenShell 被描述为面向自治智能体的安全私有运行时，结合了沙箱运行时控制与声明式策略，以防止未授权的文件访问、数据外泄与不受控的网络活动。NVIDIA 开发者指南展示了内核级的隔离，并在沙箱中强制执行文件系统、网络与进程级控制，它适用于长期运行的自演化智能体。Red Hat 宣布已经将它的 AI 平台与 OpenShell 集成，并在混合云系统中通过机密容器（confidential container）与基于 SELinux 的强制执行实现面向企业 AI 智能体的零信任模型。
围绕 Kubernetes 上的智能体沙箱也涌现出了一些新的项目与指南。有一篇关于智能体沙箱控制器的 InfoQ 文章描述了一个 Kubernetes 插件，该插件使用 gVisor 并可选地使用 Kata Containers 在加固的 pod 中隔离不受信任的智能体代码。这种方法专门采用了 OWASP 关于系统隔离与权限管理的指南。另外，InfoQ 还有一篇关于 Azure Container Apps 沙箱的报道，介绍了微软在云端对不受信任智能体代码的 microVM 支持，其中每个沙箱在硬件隔离的 microVM 中运行，并由代理强制执行默认拒绝的出站策略。
Linux 发行版与安全厂商也正在使用 cgroups、namespaces、seccomp、Landlock 与 eBPF 等原生机制构建面向智能体的沙箱。运行在标准容器中的智能体执行沙箱共享宿主内核，生产级安全的智能体执行通常需要 microVM 或用户空间内核的硬件级隔离，并配合严格的文件系统与网络策略。例如，Guardian Shell 项目将智能体在启用 Landlock、seccomp 与 eBPF 钩子的隔离 cgroup 中启动，在内核层面强制执行每个智能体的策略，而无需修改智能体的代码。该方法试图将智能体特有的控制加入现有 Linux 安全模块与容器运行时，而不是在操作系统层面构建新的 SDK 与策略层。
对安全团队而言，直接结论就是，目前并不存在单一主导的 AI 智能体平台安全模型。Windows 的 MXC 预览为 Windows 与 WSL 世界带来了操作系统集成的策略驱动包含机制，但其文档与独立分析均强调这仍是早期软件，不应被视为最终且完整的安全边界。Linux 与 Kubernetes 生态已提供内核级与硬件支撑的选项，比如，OpenShell、gVisor、Kata Containers 与云端 microVM 沙箱。
查看英文原文：Windows Platform Security and the Race to Secure AI Agents
