微软的新公告，先读清两种交付状态
微软在11月5日安全更新中介绍 Microsoft Execution Containers（MXC），并标注该能力已正式可用。公告将其描述为由操作系统实施的本地 AI 智能体隔离层，控制涉及文件、网络、进程与用户交互。对正在把本地智能体接入办公电脑的企业，这意味着选型时可以进一步询问执行边界怎样落实。
同一公告把与 Intune、Entra 和 Agent 365 的集成写成后续计划。因此，不能把隔离能力的正式可用状态扩展为所有管理集成都已交付。具体设备、授权、部署步骤和支持范围仍需核对供应商当前资料。本文是公告解读与验收建议，不是产品实测，也不把11月5日公告包装成今日新发布。
把“允许做什么”写成可测试的任务
假设员工希望让本地智能体读取采购报价目录，整理比较表，并保存到指定输出文件夹。业务方应先列明这条任务必需的输入位置、输出位置、外部站点和辅助程序。与任务无关的个人目录、共享盘和其他应用是否允许访问，需要单独决定，不能用一句“按最小权限运行”代替具体清单。
验收清单应同时有正向和反向动作。正向测试验证报价文件可读、比较表能保存；反向测试验证无关目录无法读取、未经允许的目的地无法连接。两组测试使用相同设备和策略版本，结果才可以解释。这里的场景是假设，不代表任何客户已经部署，也不说明 MXC 默认采用了这些策略。
文件能隔离，网络和子进程仍要逐项检查
企业容易只看演示中某个文件夹被拒绝访问，便把整个执行环境标为通过。但智能体完成任务可能还会调用浏览器、脚本或其他程序。验收人员应记录任务实际启动了哪些程序、访问哪些地址，以及这些动作分别受什么控制。具体控制方法应由当前产品文档和测试结果确认，不能从一个界面名称推断。
例如，若任务只需处理本地报价，却出现向外部地址上传内容的请求，应先查清业务必要性与审批依据，再决定放行。测试可以使用无敏感信息的样例文件与受控地址，检查允许和拒绝是否符合约定。不要把未观察到外发等同于永远不会外发，也不要把日志缺失写成已证明数据没有离开设备。
提示词、账号权限与执行策略分别留证
给智能体写入“不要访问其他文件”是任务指令；业务账号具有什么权限是身份配置；执行环境实际阻止哪些操作是运行控制。企业应分别保存这三类材料。这样，当任务失败或越界时，才知道应修改任务说明、调整账号还是检查执行策略，避免把所有问题归结为模型不听话。
建议由业务负责人确认任务必需范围，由信息技术人员确认设备和策略，由安全人员确认反向测试。对于高影响动作，是否需要额外人工审批，应明确写入本企业流程。本文不据公告推断 MXC 能代替业务系统审批，也不承诺任何隔离层可以消除全部风险。
先调试策略，再决定扩大使用
微软公告提到，组织可以在广泛强制执行前调整和验证策略。企业可以把这个顺序落实为小范围试点：选一条重复且边界清楚的任务，使用样例资料，记录完成情况、拒绝动作及人工处理原因。试点目标不是证明所有智能体都能运行，而是验证这一条任务在约定边界内是否可交付。
遇到阻断时，不宜直接取消整组限制。先判断阻断是否涉及真正必需的资源，再缩小调整范围，重新运行正反向测试。每次调整应留有策略版本、变更理由和复测结果。如果不得不授予远超任务所需的权限才能跑通，应回到流程设计，考虑拆分任务或由人工执行相应步骤。
验收结果要能回答下一次变化
一份可复查的验收记录应包含设备与软件版本、当前授权说明、任务输入输出、允许与拒绝的操作、策略版本，以及发现问题后的负责人。产品更新、智能体替换或新增连接器后，应判断原来的测试是否仍覆盖变化部分。不能把一次通过的截图长期用作所有后续任务的放行依据。
对已有统一终端管理的企业，下一步是确认现有工具与 MXC 的实际配合条件；对尚未盘清本地智能体的团队，先确认谁在何种设备上执行什么任务。最终的通过条件是业务任务能完成、约定越界动作被阻止、证据可追溯且异常有人处理。公告提供了跟进方向，企业仍需通过自己的环境得到结论。
要点总结
- 不能。公告把与 Intune、Entra 和 Agent 365 的集成列为后续计划，具体环境和授权仍需确认。
- 还应验证约定禁止的访问，逐项检查网络、进程和交互边界，并保存策略版本和结果。
- 没有。本文依据官方公告提出验收方法，没有进行产品实测，也没有提供客户效果结论。
参考来源说明
本文为近期官方公告的原创实用解读。建议和假设场景不代表客户案例或产品实测；支持范围和授权条件待验证。