本次变化速览
微软 10 月 7 日官方公告 将 Microsoft Execution Containers(MXC)标为正式可用,同时列出实验性的 MicroVM 与后续身份、管理能力。它需要应用或开发者集成;不能据此推断所有 Windows 智能体都已经启用相同隔离。先查实际应用、系统和后端,再用可丢弃样本验证权限。
公告确认了什么,仍需另外核实什么
官方描述的核心是让开发者或组织定义资源政策,由执行环境约束智能体工作负载。本文关注“谁定义权限”和“哪些动作可以发生”,不把模型回答变聪明与执行权限变安全视为同一件事。
应用支持、所选后端和系统要求需要逐一核对。官方列出的正式能力、实验后端和后续管理功能不能合并成“所有用户今天都能用”的结论。不同账号、组织策略与应用版本也不能仅靠一个新闻标题判断。
日期和状态分开读
- 2026-10-07
官方发布日期
微软发布 MXC 公告,核心执行层标为正式可用。
- 公告中的实验项
MicroVM
公告把 MicroVM 标为 experimental,不能当作所有设备的默认功能。
- 后续功能
身份与组织管理
公告使用 soon 描述部分 Entra 和 Intune 能力;使用前需重新确认状态。
编辑建议:把“生成报告”拆成可检查的资源范围
下面是本站设计的讨论样例,不是官方配置文件,也不是实际安全测试。任务是读取三份虚构销售记录,生成一个 HTML 汇总。只读输入目录、独立输出目录、是否允许联网,以及需要执行的程序都应由任务负责人定义。
先对这个任务写明“哪些产物算完成”,再定资源范围。需要联网获取公开资料时说明目标站点;完全使用样本文件时,不因模型想搜索就自动开放网络。若任务失败,记录缺少的资源,让负责的人判断是否必要。
| 资源 | 建议范围 | 验收动作 |
|---|---|---|
| 三份输入记录 | 只读 | 报告生成后原文件内容相同 |
| 报告输出目录 | 允许写入 | 产物只出现在指定位置 |
| 无关个人目录 | 不授权 | 用无敏感内容的试样确认访问被拒绝 |
| 网络与工具 | 按任务明确列出 | 核对实际连接与执行记录 |
采用前验证边界,不只阅读配置说明
- 记录实际应用、版本、系统、执行后端与集成说明,确认功能在当前环境可用。
- 使用不含个人或生产数据的可丢弃副本,先完成正常报告生成。确认权限足够完成任务,且输入未改变。
- 由开发者准备无害的越界验证:尝试访问未授权的样本文件或写到样本范围外,检查是否按预期被拒绝。
- 记录拒绝动作、原因和报告位置。新增权限后重跑正常与越界案例,保留差异。
这些步骤是编辑提出的验收思路,不能替代组织的安全评估,也不证明某个后端适合所有敏感任务。
先判断任务需不需要桌面,再讨论容器名称
公告中的后端并非四个可以随意互换的安全等级按钮。Process container 在 Windows 11、macOS 与 Linux 有对应平台沙箱;独立的 Session container 仅在 Windows 11 提供,隔离桌面、剪贴板、UI 和输入。MicroVM 标为 Windows 11 与 Linux 上的实验后端。选择时要先问应用需要哪些能力,再查该后端在当前系统上支持什么,不能只从名称判断强弱。
自编任务 A 从获准 CSV 生成静态 HTML,不需要点击用户桌面;任务 B 还要操作一个桌面演示程序。A 不应仅为“可能用到”获得个人桌面或剪贴板权限。B 则需要开发者解释如何隔离它的桌面操作,不能拿 A 在进程边界里成功生成文件的结果,替 B 的交互范围验收。若应用只支持某个后端,需求不匹配时应缩小任务或换实现,不把“MXC 可用”理解成应用自动获得全部能力。
这个选择同样不能回答推理请求流向哪里。容器中运行的本地工具,与模型是否通过云端推理,是两条不同数据路径。开发者应分别说明输入文件、生成输出和模型请求如何流动;不需要联网的任务若出现未说明的外部连接,应暂停调查,而不是靠“本地执行”几个字判断数据没有离开设备。
正确的报告,与被拒绝的越界动作,要同时成立
另取一个更小的自编样本:输入只有两笔同币种金额 40、60,允许在 output 目录生成合计为 100 的报告;另备一个无敏感内容、明确不在授权范围内的 sample-outside 文件。由开发者在受控环境设计无害边界用例,正常输出与越界结果必须分开记录。这里不提供可直接用于真实系统的探测指令。
还要先确认运行模式。官方说明 Windows 的 MXC process container 可在 Learning 模式阻止并记录未授权动作;Permissive 模式则允许并记录,而 Enforcement 阻止但不生成这种活动报告。因此日志里出现某个访问请求,并不能单独证明它已被拒绝。政策编写时的观察模式,与验收时要求实际阻止动作,是不同条件;对其他系统或后端也不能照搬这套报告能力。
第一种情况,报告显示 100,但越界样本也被改写:内容通过,授权边界失败,不能交付。第二种情况,越界被拒绝,但报告因缺少工作目录写权限而无法生成:隔离检查的一项通过,正常功能仍失败。修复应只补充业务必需的输出位置,再重跑两种情况,而不是临时开放整个用户目录。
只有输出可用、原输入未变、获准范围之外的无害用例按预期被阻止,并且开发者能说明生效的应用配置与后端,才构成本案例的有限验收。若读不到足够运行记录,就把对应项目留为未确认。即使这一组通过,也仍需检查来源文字是否改变任务及合计是否正确;权限边界不会替报告作事实审稿。
权限边界与内容核查仍是两份工作
即使文件访问受限,报告也可能算错、遗漏或受到输入文字影响。资料中的指令与任务指令要分开判断,见 识别文档指令与提示注入。执行成功后仍应核对输出内容。
本地执行、使用本地模型与禁止联网也不是同一状态。连接服务的权限还涉及外部系统,见 AI 连接应用的权限与结果检查。具体配置要以应用的有效政策为准,不根据界面上的“本地”标签推断数据流向。
如果现有应用没有明确说明集成或有效策略,先向维护者确认再采用。本文没有在用户设备安装 MXC、变更系统权限或进行渗透测试;封面是原创任务示意图,不是微软软件截图。
用于一次小规模评估的交付清单
- 官方日期和实际可用状态分开记录
- 应用、系统和后端已确认
- 正常任务与无害越界案例都有结果
- 输入文件与实际产物检查通过
- 内容准确性和执行权限分别审核
常见问题
MXC 正式可用是否代表我的应用已经启用?
不能这样推断。它是供集成使用的执行层,需要核对应用说明、版本和当前有效设置。
沙盒能保证报告内容正确吗?
不能。权限限制与事实、计算、引用核查是不同工作,结果仍须检查。
看到实验后端可以立即用于所有任务吗?
应根据该后端的状态、系统要求和组织评估决定,不能将实验功能描述为统一的生产默认。


