📰 AI 资讯

Windows平台安全与保护AI智能体的竞赛

2026-07-06 11:21

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