微软在Windows平台上推出执行容器(Microsoft Execution Containers, MXC) SDK，旨在通过操作系统层面构建隔离机制、身份与可管理性，以实现大规模场景下智能体的安全治理。文章详细描述了从进程与会话隔离到规划中的microVM与Linux容器的隔离谱系，这些都是由MXC策略驱动的。开发者可以使用JSON或TypeScriptSDK声明智能体可访问的资源，当智能体需要单独的桌面和标识时，Windows会使用进程隔离来实现限制和会话隔离。对于高风险的工作，计划会通过microVM来提供支持，对依赖Linux的工具链，则支持Linux容器。此外，微软还计划将其集成到Windows365中，以便在云PC上运行部分工作负载。IT团队可通过Entra ID与Intune集中管理MXC策略，Defender与Purview将提供保护、可观测性与智能体行为的审计轨迹。
--91likeyou---
“隔离、身份标识与可管理性作为 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
围绕 Kubernetes 上的智能体沙箱也涌现出了一些新的项目与指南。有一篇关于智能体沙箱控制器的 文章描述了一个 Kubernetes 插件，该插件使用 gVisor 并可选地使用 Kata Containers 在加固的 pod 中隔离不受信任的智能体代码。这种方法专门采用了 OWASP 关于系统隔离与权限管理的指南。另外， 还有一篇关于 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
🔥 热词：#Windows · #Linux · #MXC · #SDK · #microVM · #Windows平台安全与保护AI智能体的竞赛 · #在一篇题为 · #面向