当Windows成为Agent的监狱-操作系统级Agent安全架构深度解读

当Windows成为Agent的"监狱"：操作系统级Agent安全架构深度解读

Build 2026最值得安全工程师关注的，不是哪个模型又刷了分，而是微软一口气把三个安全基础设施推到了台前：ACS定义行为边界、MXC构建执行隔离、ASSERT验证合规效果。三者组合，意味着Agent安全正式从"模型安全"迈入"运行时安全"阶段。

---

一、一个删库Demo，炸出了什么？

Build 2026现场，OpenClaw创始人Peter Steinberger亲自登台，工程师给Agent下了一个指令：

"删光用户桌面上所有文件。"

94张图片就在桌面上。Agent开始执行删除操作------

一张也没删掉。

MXC沙箱在操作系统层面把桌面设为只读，Agent的所有删除请求被内核直接拦截，连报错日志都写得清清楚楚。

Steinberger在演示结束后说了一句话：

"看着一只Claw想删光你的桌面却失败了，我真的太开心了。因为六个月前，这绝对能成功。"

六个月前能成功，现在不行了。 这就是操作系统级Agent安全架构的真正含义------不是在应用层加个过滤器，不是在提示词里写"请不要删除文件"，而是在内核层面，让Agent根本不具备删除的能力。

---

二、为什么Agent安全需要操作系统级方案？

2.1 当前Agent安全的四种"土办法"

在ACS和MXC出现之前，开发者控制Agent行为的方式基本是这四种：

方式	原理	致命缺陷
系统提示词	在System Prompt中写"你不能做X"	与用户输入在同一流中，不可强制执行，提示词注入一攻即破
应用代码里的自定义检查	在代码中if-else判断	嵌入业务逻辑，难以审计，每个Agent重写一遍
输入/输出分类器	对文本做敏感词/分类检测	只能看到孤立文本，缺乏Agent循环上下文
框架自带护栏	框架提供的guardrail	每个框架一套，无法跨框架复用

这四种方式有一个共同特点：都运行在应用层，Agent如果想绕过，技术上完全可行。

2025年以来OWASP记录的Agent威胁中，工具误用（tool misuse）和提示注入（prompt injection）已经成为最高频的攻击向量。当你靠提示词来约束一个能执行任意Shell命令的Agent时，本质上是在用"君子协定"替代"权限控制"。

2.2 核心矛盾：自主性与安全性的零和博弈

Agent越自主，越有用。但Agent越自主，也越危险。

一个能读取文件、调用API、执行代码、修改环境的Agent，它与人类、工具、应用、模型、其他Agent的每一次交互，都在暴露新的攻击面。当这些系统在真实数据上大规模自主运行时，一个被注入的指令就可能导致级联失败。

应用层安全解决不了这个问题，就像你不能靠贴一张"禁止入内"的纸条来替代门锁。你需要的是物理层面的隔离------操作系统级别的隔离。

---

三、ACS：Agent行为的"法律条文"

3.1 什么是ACS？

Agent Control Specification（ACS）是微软发布的开放、供应商中立的开源标准 ，定义了AI Agent运行时治理的规范。它不编排Agent循环、不选择工具、不管理内存------它是一个控制层，插入到Agent框架已暴露的审核点中。

开源地址：github.com/microsoft/agent-governance-toolkit（MIT License）

3.2 八个拦截点：Agent全生命周期管控

ACS定义了8个标准拦截点，覆盖Agent从启动到关闭的完整生命周期：

agent_startup → input → pre_model_call → post_model_call → pre_tool_call → post_tool_call → output → agent_shutdown

拦截点	触发时机	安全意义
agent_startup	Agent启动前	评估配置和环境，防止恶意初始化
input	用户输入到达模型前	检测提示注入、越权指令
pre_model_call	发送给模型前	检查完整上下文，防止上下文污染
post_model_call	模型响应后	审查模型输出是否偏离预期
pre_tool_call	工具执行前	关键防线------检查工具名称和参数
post_tool_call	工具输出返回前	检查工具输出是否携带恶意内容
output	最终响应离开Agent前	最后一道关卡，防止敏感信息泄露
agent_shutdown	会话结束	审计日志、评估会话结束条件

关键洞察 ：8个拦截点中最重要的是pre_tool_call。这是Agent从"想做什么"变成"实际做了什么"的分界线。一个Agent可以生成任何文本，但只有当它调用工具时，才会对真实世界产生实际影响。在这个拦截点上进行策略检查，等同于在"动刀"之前做最终确认。

3.3 规范策略输入：统一的安全上下文

ACS将Agent上下文转化为标准的策略输入结构：

{
  "intervention_point": "pre_tool_call",
  "policy_target": {
    "kind": "tool_args",
    "path": "...",
    "value": { ... }
  },
  "snapshot": { "完整宿主上下文" },
  "annotations": { "分类器、LLM裁判等的结果" },
  "tool": {
    "name": "send_email",
    "clearance": ["internal"],
    "security_labels": ["confidential"]
  }
}

注意tool字段中的clearance和security_labels------这意味着每个工具都有安全标签，策略引擎可以基于"工具许可级别+数据敏感度"做二元判断，而不是靠文本匹配。

3.4 策略引擎：用Rego写安全规则

ACS使用OPA/Rego作为策略语言，这是云原生领域已经广泛验证的声明式策略引擎（Kubernetes的准入控制也用Rego）。

策略通过YAML清单声明：

agent_control_specification_version: "0.3.1-beta"
metadata:
  name: "email-agent"
policies:
  email_policy:
    type: rego
    bundle: ./policy
    query: data.email_agent.verdict
    intervention_points:
      pre_tool_call:
        policy_target: "$.tool_call.args"
        policy_target_kind: tool_args
        tool_name_from: "$.tool_call.name"
tools:
  send_email:
    type: Tool
    id: send_email
    clearance: internal

每个策略返回四种裁决之一：

裁决	含义	典型场景
allow	放行	发送内部邮件给白名单收件人
warn	警告但放行	发送邮件给未分类的外部域名
deny	拒绝	尝试发送含PII数据的邮件到外部
escalate	升级到人工审批	大额转账、敏感数据导出

安全工程视角 ：deny和escalate的区别极其重要。deny是确定性阻断，escalate是引入人工判断。在企业场景中，很多操作不能简单deny（可能阻断正常业务），但也不能简单allow（风险不可控），escalate给了第三种选择。

3.5 跨框架移植：一次编写，到处执行

ACS提供Python、Node.js、.NET、Rust四种SDK，共享同一原生核心。已支持的框架包括：

• LangChain
• OpenAI Agents SDK
• Anthropic Agents SDK
• AutoGen
• CrewAI
• Semantic Kernel
• Microsoft.Extensions.AI
• MCP工具

同一份策略清单可以在不同框架和语言间移植，无需重写策略。安全团队获得统一的编写、版本化和审计控制点。

这解决了当前Agent治理的最大痛点------每个框架各搞一套护栏，安全团队要维护N份不同语言不同逻辑的策略代码。ACS把策略从代码中抽离出来，变成可移植的声明式清单。

---

四、MXC：Agent的"监狱围墙"

4.1 如果ACS是法律，MXC就是监狱

ACS定义了"Agent不能做什么"，但它只是个规范层------策略说"不能删文件"，但谁来确保真的删不了？

MXC（Microsoft Execution Containers）就是那个确保删不了的执行层。

MXC是内置于Windows操作系统的、策略驱动的系统级安全执行层。它不是一个应用，不是中间件，而是操作系统内核提供的能力。

开源地址：github.com/microsoft/mxc

4.2 隔离光谱：从轻量到硬隔离

MXC的核心设计理念是"可组合沙箱"------同一套策略模型和SDK，可以映射到不同的隔离构造，从轻量到硬隔离形成完整光谱：

┌──────────────────────────────────────────────────────────┐
│              MXC SDK（统一策略模型 + SDK）                   │
│                                                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐  │
│  │ 进程隔离  │  │ 会话隔离  │  │ Micro-VM │  │Linux容器│  │
│  │(已发布)   │  │(已发布)   │  │(路线图)   │  │(路线图)  │  │
│  └──────────┘  └──────────┘  └──────────┘  └─────────┘  │
│       ↑             ↑             ↑             ↑        │
│       └─────────────┴─────────────┴─────────────┘        │
│                    隔离光谱                                │
│         (轻量级 ←────────────────────→ 强隔离)             │
└──────────────────────────────────────────────────────────┘

隔离级别	机制	安全强度	性能开销	适用场景
进程隔离	Windows进程边界+白名单	⭐⭐	极低	编码Agent（Copilot CLI已采用）
会话隔离	独立Windows会话+独立身份	⭐⭐⭐	低	长期运行的RPA Agent
Micro-VM	Hypervisor硬件级隔离	⭐⭐⭐⭐	中	运行不可信代码、处理敏感数据
Linux容器	WSL+OS级隔离	⭐⭐⭐	中	Linux ML工作负载
Windows 365	云端完整隔离实例	⭐⭐⭐⭐⭐	高	企业Agent集群

设计哲学：不同场景需要不同强度的隔离。编码Agent只需要进程级隔离（快），金融Agent可能需要Micro-VM（安全），但它们共享同一套策略模型。开发者定义策略，操作系统选择隔离级别。

4.3 进程隔离：GitHub Copilot CLI的实战

MXC进程隔离已被GitHub Copilot CLI采用。工作原理：

1. Copilot CLI动态生成代码后，MXC在专用进程边界内执行
2. 进程只能访问策略白名单中的文件和网络域
3. 白名单之外的任何访问请求，内核直接拒绝

从安全工程角度看：这是"最小权限原则"的操作系统级实现。不是"Copilot应该不会访问敏感文件"，而是"Copilot在内核层面就访问不了"。

4.4 会话隔离：人与Agent的物理分界

会话隔离做了三件关键的事：

隔离维度	实现方式	安全效果
桌面分离	Agent运行在独立Windows会话	缓解UI欺骗攻击
剪贴板隔离	与人类桌面剪贴板完全分离	防止跨会话数据泄露
身份绑定	分配独立本地ID或Entra云端身份	所有人类/Agent操作可区分、可审计

这是真正的突破。此前在Windows上，Agent以用户身份运行，它做的所有事都归到人头上。会话隔离后，Agent有自己的"身份证"------它删了文件，日志里写的是Agent身份，不是你的身份。

4.5 MXC的开源实现：跨平台Rust核心

MXC的GitHub仓库揭示了更多技术细节：

技术栈：Rust 71.2% + TypeScript 15.8% + PowerShell 10.0%

隔离后端矩阵：

后端	平台	状态	核心技术
processcontainer	Windows	稳定	Windows进程沙箱
bubblewrap	Linux	稳定	bwrap
lxc	Linux	稳定	Linux容器
windows_sandbox	Windows	实验性	Windows Sandbox
wslc	Windows	实验性	WSL容器
microvm (NanVix)	Win/Linux	实验性	微型虚拟机
hyperlight	Win/Linux	实验性	轻量级虚拟化
isolation_session	Windows	实验性	隔离会话（需Win11 26300+）
seatbelt	macOS	实验性	macOS沙箱

跨平台意味着什么？ MXC不只是Windows专属。macOS用seatbelt后端，Linux用bubblewrap/lxc，Windows用进程容器。同一套策略JSON配置，在不同平台上自动映射到对应的隔离后端。

SDK用法示例（TypeScript）：

import { spawnSandboxFromConfig, createConfigFromPolicy } from '@microsoft/mxc-sdk';

const config = createConfigFromPolicy({
  version: '0.6.0-alpha',
  filesystem: {
    readonlyPaths: ['/tools', '/libs'],
    readwritePaths: ['/tmp', '/workspace'],
  },
  network: { allowOutbound: false },
  timeoutMs: 30_000,
});

config.process!.commandLine = 'python -c "print(\'hello from sandbox\')"';

const child = spawnSandboxFromConfig(config, { usePty: false });

注意当前版本限制：MXC仍处于早期预览阶段，README明确标注"不应将任何MXC配置文件视为安全边界"。策略配置存在过于宽松的已知问题。但架构方向是对的，这是从0到1的突破。

---

五、ASSERT：Agent安全的"质检流水线"

5.1 评估与控制的闭环

ACS+MXC解决了"如何控制"的问题，但还有一个更上游的问题：你怎么知道你的Agent在哪些地方违反了策略？

ASSERT（Adaptive Spec-driven Scoring for Evaluation and Regression Testing）回答的就是这个问题。

开源地址：github.com/responsibleai/ASSERT

5.2 工作流程

YAML策略规范 → 系统化生成测试场景 → 对真实Agent执行测试 → Judge评判+度量 → 缺陷报告

1. 输入：开发者用YAML描述关注的行为规范（如"Agent不应向外部发送含PII的邮件"）
2. 生成：ASSERT系统化生成针对性评估场景（不是通用基准题，而是基于你的策略定制）
3. 执行：指向真实Agent运行测试
4. 输出：完整的可审计产物------Spec、测试用例、模型输出、Judge决策理由、度量指标

5.3 与ACS的闭环

┌─────────────────────────────────────────────┐
│  Step 1: ASSERT → 发现Agent违反策略的位置     │
│  Step 2: ACS   → 在对应拦截点放置控制措施     │
│  Step 3: ASSERT → 重新验证，前后对比度量       │
└─────────────────────────────────────────────┘

这个闭环是关键。没有ASSERT，你不知道该在ACS的哪个拦截点放什么策略。没有ACS，ASSERT发现的缺陷无法被运行时阻断。两者配合，形成了"发现→修复→验证"的安全工程闭环。

---

六、三层架构：Agent安全的完整图景

把ACS、MXC、ASSERT放在一起，我们看到的是一个完整的三层Agent安全架构：

┌──────────────────────────────────────────────────────────────┐
│                    治理层（Agent 365 + Entra + Intune）        │
│                    策略定义 · 身份管理 · 可观测性               │
├──────────────────────────────────────────────────────────────┤
│                    控制层（ACS）                               │
│                    行为边界定义 · 拦截点策略 · 裁决             │
├──────────────────────────────────────────────────────────────┤
│                    执行层（MXC）                               │
│                    进程隔离 · 会话隔离 · Micro-VM · 云端实例    │
├──────────────────────────────────────────────────────────────┤
│                    验证层（ASSERT）                            │
│                    策略驱动评测 · 缺陷发现 · 回归验证           │
├──────────────────────────────────────────────────────────────┤
│                    平台层（Windows OS）                        │
│                    内核隔离 · 安全基线 · 后量子密码              │
└──────────────────────────────────────────────────────────────┘

层级	职责	类比
治理层	谁能运行什么Agent、权限多大、如何审计	公司安全制度
控制层（ACS）	Agent可以做什么、不能做什么、哪些需要人工审批	岗位职责说明书
执行层（MXC）	物理上确保策略被执行、Agent跑不出沙箱	门禁+监控+保险柜
验证层（ASSERT）	测试策略是否有效、Agent是否遵守规则	安全审计+渗透测试
平台层	底层安全能力（Secure Boot、Defender、热补丁）	建筑基础设施

从模型安全到运行时安全的范式转移：

维度	旧范式（模型安全）	新范式（运行时安全）
安全对象	模型输出	Agent行为
安全边界	提示词/分类器	操作系统内核
策略执行	"建议不这样做"	"内核层面做不到"
审计能力	模型调用日志	Agent全生命周期拦截点日志
跨框架复用	无	ACS策略可移植
隔离方式	无/应用层	OS级进程/会话/VM隔离

---

七、合作伙伴生态：谁在用？

合作伙伴	集成方式	安全意义
GitHub Copilot CLI	MXC进程隔离	代码生成Agent的安全执行
OpenClaw	MXC沙箱+Windows原生运行	Agent网关的操作系统级防护
NVIDIA OpenShell	基于MXC构建	GPU生态Agent的隔离执行
OpenAI Codex	探索MXC执行环境	代码生成到安全执行的全链路
Manus	MXC策略驱动	自主Agent的企业级安全边界
CrewAI	ACS框架适配器	多Agent协作的安全治理

OpenAI和英伟达同时出现在MXC的合作伙伴名单里，这本身就是一个强烈信号：Agent安全的操作系统级方案不是微软一家的闭门造车，而是行业共识正在形成。

---

八、安全工程师的冷思考

8.1 乐观的部分

1. 从"君子协定"到"权限控制"：这是Agent安全领域最根本的进步。提示词约束Agent不删文件，和内核层面Agent删不了文件，是完全不同的安全等级。
2. 策略可移植：ACS的跨框架策略复用，解决了安全团队最大的运维痛点。
3. 开源+供应商中立：ACS采用MIT License，MXC在GitHub公开开发，不是微软私有协议。这意味着其他操作系统、其他云平台可以跟进实现。
4. 身份隔离：会话隔离给Agent独立身份，解决了Agent行为归因的核心问题。

8.2 需要警惕的部分

1. MXC仍在早期预览 ：README明确写了"不应将任何MXC配置文件视为安全边界"。策略配置过于宽松的已知问题尚未修复。现在就依赖MXC做生产安全防护是危险的。
2. 沙箱逃逸研究正在升温：arXiv上已有研究表明，LLM正在发展逃逸沙箱的能力。进程隔离对当前威胁够用，但面对更强的对抗攻击可能不够。Micro-VM的硬件级隔离更可靠，但还在路线图上。
3. ACS的故障关闭（fail-closed）处理：如果策略引擎本身出问题怎么办？ACS设计了fail-closed机制（故障时默认拒绝），但这是规范层面的设计，实际实现的效果还要验证。
4. 策略复杂度与可维护性：8个拦截点×多种策略×4种裁决×跨框架适配 = 策略矩阵的复杂度会急剧上升。安全团队如何管理这个复杂度，是落地后的核心挑战。
5. Windows绑定的隐忧：虽然MXC跨平台，但最完整的隔离能力（会话隔离、isolation_session）目前只在Windows Insider Preview上可用。Linux和macOS用户能获得的安全等级存在差距。

8.3 对行业的影响

短期（6个月）：

• 大型企业的Agent部署会加速，因为终于有了可审计、可管控的运行时安全方案
• ACS的策略可移植性会降低安全团队在多框架环境下的运维成本
• GitHub Copilot CLI的MXC进程隔离成为"安全Agent执行"的行业标杆

中期（1-2年）：

• ACS可能成为Agent治理的事实标准（类似OPA之于Kubernetes准入控制）
• Micro-VM和Linux容器后端上线后，MXC的隔离强度会显著提升
• 其他操作系统厂商（Apple、Google）可能推出类似的Agent隔离方案

长期（3年+）：

• Agent运行时安全可能成为操作系统的基础能力，就像今天的内存保护和访问控制一样
• ACS+MXC的组合可能催生"Agent安全审计师"这个新角色
• ASSERT式的策略驱动评测可能成为Agent发布前的强制安全流程

---

九、结语：安全工程师的工作变了

回到那个OpenClaw删库的Demo。六个月前，一个Agent可以轻松删光你的桌面。六个月后，操作系统说：不行。

这个变化意味着安全工程师的工作正在发生根本转变：

过去：你审查模型输出是否安全------检测有害内容、过滤敏感信息、防御提示注入。这是"模型安全"。

现在：你需要设计Agent在操作系统中的权限边界------它能看到什么文件、能调用什么API、能在什么隔离级别下运行、失败时如何安全关闭。这是"运行时安全"。

ACS定义了边界，MXC执行了边界，ASSERT验证了边界。三层架构，从规范到执行到评测，构成了一个完整的安全工程闭环。

Windows不再只是面向人类用户的操作系统。智能体成为了运行时、工具链和分发模型中的"一等公民"。但一等公民不等于不受约束的公民------当操作系统同时成为Agent的运行平台和监狱时，安全工程师终于有了真正的抓手。

这不是终点。MXC还在早期预览，Micro-VM还在路线图上，沙箱逃逸的研究正在加速。但方向已经明确：Agent安全的未来在操作系统内核，不在提示词里。

---

参考资源：

• ACS开源仓库：github.com/microsoft/agent-governance-toolkit
• MXC开源仓库：github.com/microsoft/mxc
• ASSERT开源仓库：github.com/responsibleai/ASSERT
• Windows平台AI智能体安全：blogs.windows.com
• ACS官方博客：commandline.microsoft.com
• Build 2026 Session BRK250：aka.ms/build26-BRK250

---

本文撰写于2026年6月4日，基于微软Build 2026大会公开发布的技术资料。MXC仍处于早期预览阶段，文中技术细节可能随版本更新而变化。