上周，微软在 Build 2026 上发布了 Microsoft Execution Containers，简称 MXC。

在 MXC 的设计上，微软没有把 Agent 安全继续停留在"模型对齐""提示词防护"或"内容审核"层面，而是把问题推进到了操作系统和运行时环境。

按照微软官方说法，MXC 目前处于预览阶段，目标是让开发者和 IT 管理员能够创建企业级 Agent 沙箱，并由操作系统自身执行隔离和约束。

换句话说，Agent 安全正在从"让模型更听话"，走向"让 Agent 即使不听话，也不能乱来"。这正是企业级 Agent 落地必须面对的问题。

Agent 危险的地方，是会行动

过去一年，企业对 Agent 的想象快速变化。最早，Agent 更像是增强版对话机器人：回答问题、总结文档、生成代码、辅助检索。这个阶段的主要风险，是内容错误、幻觉、敏感信息输出不当。

但当 Agent 开始连接工具、调用 API、访问文件、操作浏览器、执行脚本、读写数据库时，风险性质就变了。

它不再只是"说错话"，而是可能"做错事"。一个被 Prompt 注入影响的 Agent，可能会：

  • 读取本不该读取的文件；
  • 调用本不该调用的内部系统；
  • 使用合法凭证访问高敏数据；
  • 把敏感信息发送到外部地址；
  • 删除、覆盖或篡改关键资产；
  • 在企业内网中执行超出原任务范围的操作。

这类风险最棘手的地方在于：从传统安全视角看，它往往是"合法"的。

Agent 使用的是合法账号，走的是合法协议，调用的是合法 API，甚至携带的是合法 Key。传统网关、防火墙、系统很难判断：这一次访问到底是用户真实意图，还是 Agent 被外部内容诱导后的越权动作。

所以 Agent 时代的核心安全命题变成了：合法身份，不代表合法意图。

安全已经成为 Agent 基础设施

根据官方信息，MXC 是面向 Agent 的策略驱动执行层，可以让开发者定义 Agent 对文件、网络、系统资源等能力的访问边界，并依赖操作系统原生机制进行执行。微软还强调，Windows 会为容器中的 Agent 分配身份，并将活动归因到对应身份，从而区分人类用户和 Agent 行为。

这背后的判断非常清楚：企业不会允许 Agent 以"登录员工本人"的完整权限在系统里自由行动。

因为 Agent 和传统软件不同。传统软件的行为相对确定，代码路径、权限边界、输入输出都更容易预测。而 Agent 的行为由模型推理、上下文、工具返回、外部网页、用户指令共同驱动，具备更强的不确定性。它可能在一次任务中临时决定调用工具、组合步骤、访问资源，并根据中间结果继续行动。

这意味着，企业不能只在"入口"做身份认证，还必须在"执行过程中"持续约束 Agent。MXC 的出现，本质上是在回答一个问题：当 Agent 可以代表用户行动时，它必须运行在一个可隔离、可限制、可审计的环境里。

沙箱仅回答"能不能碰"，没回答"为什么要碰"

MXC 的重点是运行时隔离。它解决的是 Agent 执行边界问题：哪些文件能访问，哪些网络能连接，哪些资源能使用，哪些系统能力要被限制。

这非常重要，但还不够。因为企业面临的真实风险，往往不是简单的"允许或禁止访问某个资源"，而是"同一个资源，在不同任务意图下，是否应该被访问"。

举三个典型场景：

  • 一个销售 Agent 访问 CRM 系统，可能是正常业务动作；但如果它在总结外部邮件时，被邮件内容诱导去批量导出客户名单，这个动作就应该被拦截。
  • 一个研发 Agent 读取代码仓库，可能是正常任务；但如果它在处理网页资料时，被隐藏指令诱导去读取本地、环境变量或内部配置文件，就不是正常行为。
  • 一个运维 Agent 调用内部 API，可能是授权操作；但如果它在未确认的情况下修改配置、重启服务、删除数据，就需要人工二次确认。

这些场景中，风险不只来自资源本身，也来自上下文、任务目标、调用链和语义意图。

所以 Agent 安全不能只问：这个 Agent 有没有权限？还要问：这个 Agent 此刻为什么要这么做？这个动作是否符合当前任务意图？是否触碰了高敏资产？是否需要人确认？这就是"语义安全"和传统安全的分界线。

完整 Agent 安全：需要四层防线

对企业来说，真正可落地的 Agent 安全体系，应该至少包括四层能力。

第一层是"理"：理清 Agent 的资产边界。

企业首先要知道，一个 Agent 到底可能接触哪些东西。它声明了哪些工具，调用了哪些 API，读取了哪些环境变量，访问了哪些域名、内网地址、文件路径和业务系统。

没有资产画像，就谈不上有效防护。尤其在企业内部，Agent 可能横跨文档、代码、工单、客户系统、数据库、知识库、消息系统等多个场景。它的资产边界不是静态写在权限表里的，而是在运行过程中不断显现的。

第二层是"控"：控制 Agent 的行为意图。

当 Agent 发起高风险动作时，系统不能只检查协议和身份，而要判断它的语义意图。

低风险动作可以自动放行；涉及敏感资产、未预授权动作、跨域调用、异常链路时，应触发 Human-in-the-Loop 二次确认。对于密钥类能力，也应采用 JIT 凭证注入：Agent 本身不持有真实 Key，只有在网关确认通过后，才由安全侧瞬时注入。这样可以避免 Agent 被 Prompt 注入后直接泄露凭证。

第三层是"隔"：把 Agent 放进安全沙箱。

这也是 MXC 所代表的方向。通过虚拟文件系统、资源配额、网络隔离等方式，把 Agent 的活动范围限制在可控空间内。即使 Agent 被诱导执行危险动作，也只能碰到沙箱里的逻辑目录和授权资源，无法直接影响宿主机和高敏资产。

第四层是"断"：对绕过行为做底层熔断。

沙箱和网关解决的是大多数正常路径上的控制。但安全体系还需要最后兜底：当 Agent 试图绕过网关、绕过沙箱，直接对高敏文件、网络连接或系统调用发起危险操作时，需要在更底层识别并中断。

例如通过 eBPF 监控关键系统调用，在发现非授权写入、异常连接或高危执行时，直接熔断进程。这也是 Agent 安全从"软约束"走向"硬边界"的关键。

MXC 让行业看到：Agent 需要边界。而企业真正需要的是：Agent 的每一次行动，都可理解、可控制、可隔离、可熔断。这也是 Agent 从试验走向生产之前，必须补上的安全基础设施。