什么是MXC？为AI智能体划定新的安全边界
Microsoft推出MXC以限制AI智能体的访问范围。本文分析其执行模型、企业用途与实际评估方法。
略观: 人工智能代理人需要工具来做有益的工作,但获得这些工具的机会应当有限度。 MXC为检查权限,活动记录和执行隔离提供了一个起点.
公告上怎么说?
打开 2026年10月7日,微软宣布普遍提供微软执行容器,或MXC. 在公司的描述中,开发商宣布资源是任务需要,而执行层则独立于代理商的决定执行限制. 这些资源可以包括文件,网络目的地和执行能力. 该公告涉及一个执行边界;它不能保证每个模型响应正确. Microsoft’s official report
以下各节对这种方法进行了实际分析。 它们不是每个组织的现成配置。 政策需要反映所涉的实际数据、工具和后果。
为什么好指示还不够?
如果一个助手被要求调查申请错误。 读取应用程序的日志目录可能足够了 。 如果同一个助手也可以编辑制作文件,联系每个服务并使用管理员账户,一个错误的工具选择可能产生远远超出原任务的后果.
“不要碰其他文件”等指令可能有用,但不能取代强制限制。 可靠的政策必须存在于代理人决策过程之外。 IT团队的实际问题是:如果代理商出乎意料地行事,系统哪一部分实际上阻止了动作?
它还有助于区分错误的答案和错误的行动。 可通过审查纠正不准确的解释。 意外生产配置的改变可以中断服务. 权力范围应反映行动的后果。
从广泛权威到具体授权
对于初步的实验,将代理商的权威破解为较小的问题. 下表为拟议评价框架,而不是产品规格。
| 区域 | 处决前的问题 | 适当边界实例 |
|---|---|---|
| 文件 | 必须读什么? | 只有应用程序的日志目录 |
| 变动 | 哪些可以修改? | 测试副本,而不是生产设置 |
| 网络 | 需要哪个目的地? | 有文件记载的具体服务 |
| 身份 | 活动记录里有谁的身份? | 可区分的账户或工作量 |
| 恢复 | 如何扭转变化? | 备份和界定的审查程序 |
这使“使代理人安全”变成可以检验的决定。 每项许可都应有目的、所有者和明确的有效期。
假设的基础设施团队设想
想象一下一家公司要求一位助手分析网页服务器错误. 一个明智的起点是在试验环境中对原木进行消毒。 最初,助手对错误进行分类并推荐动作;操作员保留执行更改的责任.
经过几次评价后,小组可能允许在试验环境中采取一些低影响的行动。 不应仅以完成的任务数量来衡量进展情况。 当请求无关、数据不在允许的范围之内或访问尝试失败时,小组还应审查行为。
例如,日志中的文本可能类似于指令。 它的存在不应赋予代理人更多的权力。 输入数据描述了问题;这不是允许的来源。
关键点: 一次成功的试验表明,授权工作已经完成,可观察到防止未经授权的行动。
拟议评价顺序
- 选择一个有界限、可重复、低风险的任务。
- 向服务所有人列出所需资源。
- 从建议开始,将更改执行分开。
- 测试在测试环境中的超范围访问尝试.
- 记录失败和访问原因被拒绝。
- 仅添加复核证明合理的权限 。
维持政策也有费用。 文件路径、工具和服务都发生了变化。 旧的许可定义可能最终停止匹配环境. 其所有人应当知道何时审查,以及审查哪些证据。
限制和常见问题
封装是否使输出正确?
没有 约束权威和确保答案准确性是不同的问题. 技术产出仍然需要测试、审查和接受标准。
一项政策能否涵盖每一项任务?
在这一分析中,这是一个糟糕的起点。 阅读日志、修改代码和管理基础设施会产生不同的后果,应当单独考虑许可范围。
关于数据控制和业务依赖性的相关观点,见 中的数据主权.
资料来源和编辑说明
资料核查日期： 2026年11月1日. .. 设想和评价顺序是原始分析,而不是关于实际部署或独立产品测试的报告。 本条解释公告,支持技术评审.
