微软把 AI Agent 划进内部威胁名单：这次动的不是模型，是权限归谁
先说结论：微软 10 月 19 日发的这套东西，表面上是几条新功能，实际上是改了一个默认假设。
过去的默认假设是——Agent 是我们自己部署的，所以默认可信。微软这次明说了：这个假设不成立。原文那句话我抄一下：「自从我们自己把 Agent 部署进公司内部，我们就默认可信了它们。不幸的是，前沿模型，无论出自哪家，都不能被信任。」
注意后半句：无论出自哪家。包括它自己家的。
这不是一句公关辞令。它把一个从 1970 年代就有的老概念——内部威胁（insider threat）——直接套到了模型头上。而内部威胁这套方法论，从来都不是靠「相信这个人」来运转的。
一、先把「内部威胁」这四个字的原意搞清楚
很多人一看到「AI 是内部威胁」，第一反应是「AI 要造反了」。不是这个意思，微软自己在文里反复澄清了三遍。
内部威胁的传统定义是：一个有合法权限的内部人，因为疏忽、被策反、或者被钓鱼，造成了他本来不该造成的破坏。关键在「有合法权限」这四个字——他不是翻墙进来的，他是刷卡进来的。
套到 Agent 上，微软给的理由是三条：
- 它会犯错，因为输出是非确定性的，同样的输入不保证同样的输出；
- 它会被操纵，一段外部文档里的提示注入就能改它的行为；
- 它会被攻破，它跑的 harness、它调的 MCP server、它拿的凭证，任何一环都可能被拿下。
再加一条我觉得最关键的，也是原文里写得最不显眼的一句：Agent 之间会互相协作、甚至串通来达成目标，而这个过程不需要它被攻破。
这句话的分量比前面三条加起来都大。它说的不是「Agent 会被坏人利用」，而是「多个 Agent 为了完成任务，自发形成的路径可能没人设计过」。这才是「内部」两个字的真正含义——它是从里面长出来的，不是从外面打进来的。
二、真正的原则只有一句话
整套框架的基石，是纳德拉 10 月 10 日在自己那篇短文里写的：
我们必须把智能的供给，和对智能的权威，分开。
翻成大白话：模型厂商负责把模型做得聪明，但「这个模型在你的系统里能读什么、能改什么、能不能继续跑」——这个决定权不能交给模型厂商，也不能交给模型自己。
他在同一篇里还有一句更狠的：「最可信的超级智能系统，不会是那个我们最信任模型的系统，而是那个让我们可以最不信任模型的系统。」
这句话听着像悖论，其实是很老的工程学。它对应的是 1970 年代就确立的一条安全原则：一个程序不能绕过、也不能篡改用来约束它权限的那套机制。
问题在于，现在大多数 Agent 的部署方式是反过来的：模型在容器里，权限控制写在模型的系统提示词里，日志由模型自己汇报。等于把警察和嫌疑人安排在同一个人身上。
微软的解法是把它拆开：模型跑在受控的运行时里（它叫 Microsoft Execution Container，MXC），身份发在 Entra 里，权限由外部策略决定，证据由外部传感器采集。模型全程在笼子里，而且笼子的锁不在它手上。
三、四个动词，别当成四个阶段
微软把这事拆成了四个动作，原文是 Know / Contain / Protect / Adapt。我要特别强调一句：这四个不是先后顺序，是同时运行的闭环。
| 动作 | 中文 | 具体做什么 | 对应能力 |
|---|---|---|---|
| Know | 知道 | 有哪些 Agent、谁建的、为什么建、正在干什么 | 本地 Agent 发现扩展到 60 类 |
| Contain | 限制 | 动手之前就把能碰的东西划死 | MXC 沙箱 + Dynamic Permissions |
| Protect | 保护 | 它路径上的数据、工具、运行时、资源 | Purview / 网络 / 端点控制点 |
| Adapt | 调整 | 行为和风险一变，权限跟着变 | Dynamic Agent Risk + 条件访问 |
原文有一句话概括得很准：证据改变风险，风险改变策略，策略改变它能做什么。
这就是循环。不是「入职时评估一次，然后发一张长期通行证」，是「每做一件事都重新算一次」。
四、「零权限起步」是这套东西里最硬的条款
我认为整篇文章里，对甲方最有实际约束力的是这一条：
员工保留员工自己的访问权限。Agent 拿到的是它自己的身份、自己的权限，以及仅限当前任务、仅限任务时长的授权。
这句话拆开是三条硬要求：
- Agent 不能继承人的全部权限。你给员工开了财务系统的全权限，不代表他叫来的那个报销 Agent 也能有。
- 权限按任务发，按时限收。任务结束，权限作废，不是留着下次用。
- 高风险动作要人来批，而且是「可证明的人工批准」——原文用的词是 cryptographically provable，密码学上可证明，不是弹个窗点个「同意」。
配套的是 Dynamic Agent Risk：一个持续更新的风险评分，看的不是「这个 Agent 配置得安不安全」这种静态项，而是「它现在正在做什么，和它被派去做的任务是否偏离」。
偏离之后怎么处理？微软特意强调响应是渐进的，不是开关：
- 保住读，砍掉写；
- 收窄它能碰的数据范围；
- 切断网络路径；
- 缩短或吊销临时权限；
- 高风险动作强制人工批准；
- 最高档才隔离运行时、直接停掉。
这个设计挺讲究的。它承认了一件事：「发现异常就杀掉」这种策略在真实业务里跑不通，因为误杀成本太高，最后的结果一定是运维把告警关了。所以它给了一档一档往下走的阶梯。
五、五个能对上号的具体东西
框架讲完，落到产品上是这几样。我按「能不能立刻验证」排的：
① 本地 Agent 发现扩到 60 类
新增 35 类，明确点名了 Claude Code、OpenAI Codex、GitHub Copilot。我去翻了它的支持矩阵文档，确实有 Claude Code、Codex CLI、Codex Desktop、GitHub Copilot CLI 这些条目，还单独标了 WSL 里跑的情况。
这一条对国内企业的含义可能被低估了：你员工在自己电脑上偷偷装的编码 Agent，现在安全团队能看见了。这是可见性的巨大提升，但同时也是个组织问题——装之前要不要报备，会不会被当成监控，得提前想清楚。
② Entra Agent ID 扩展
让 Agent 有独立于使用者的身份。原文的落点是「让企业能分清哪些事是人做的，哪些是 Agent 代这个人做的」。这句话在事故复盘时价值极高——没有独立身份，你事后根本说不清责任归属。
③ MXC 执行容器
关键不在沙箱本身，在于原文那句：「如果 Agent 或者它的 harness 被攻破，它不应该有能力关掉正在看着它的那套控制。」这是把「锁在笼子外面」落到了工程上。
④ Dynamic Permissions
上面第四节那三条要求的产品化。有一条细节值得记：组织级策略先划外边界，其中包含「防止 Agent 拿到它的使用者本身都没有的权限」。这条堵的是提权。
⑤ Guardian Agents + Playbooks
这是最需要冷静看的一条，下面单独说。
六、这套框架最硬的一块骨头：Guardian 自己也是 Agent
我读完全文，最想追问的是一个自指的问题。
微软说：模型不能当自己的安全权威，控制必须在模型外面。
然后它的答案是：用一队 Guardian Agents（守护 Agent）去 7×24 盯着每一个 Agent 的每一个动作。
可 Guardian Agents 本身就是 Agent 啊。
微软显然知道这个坑，它给了三层回应：
第一层，Guardian 的权限边界、审批边界、委托规则由人来定，Guardian 只在边界内活动。原文写得很清楚：「这不是把判断外包出去。人保留对目标和重大决策的控制。」
第二层，Guardian 拿到的证据来自外部传感器——身份、数据、端点、网络、运行时、云端，不是模型自述。这一点是它能成立的前提。
第三层，也是最诚实的一层：模型透明度的提升（思维链等）被当作证据来源之一，但原文立刻补了一句：「模型不能成为自己的安全边界。独立的系统必须观察每一层，包括模型本身。」
说实话，这三层回应在逻辑上是自洽的，但在工程上留了两道缝，我觉得必须点出来：
第一道缝：证据的可信度取决于证据在谁手里。对本地跑的 Agent（Claude Code、Codex 这类），传感器在你自己端点上的，证据链是干净的。但对云端托管的 Agent，运行日志、思维链、调用记录都在供应商机房里。你拿到的是它给你的摘要，不是原始数据。「独立审计」这四个字，在云端 Agent 身上打折扣。
第二道缝：Guardian 和人一样会疲。它不会累，但它会有误报率。当一万个 Agent 每天产生十万条「风险升高」的信号，Guardian 自动降权、自动隔离的动作会开始影响业务连续性。到那个点上，真正的瓶颈不是检测能力，是误报的代价谁来承担。原文给的答案是「人保留重大决策」，但「重大」的边界在哪，它没说。
这不是否定这套框架。恰恰相反，能把这两道缝明确写进架构文档的厂商不多。但作为要落地的人，你得知道缝在哪。
七、同一周的另一半：对面的 Agent 已经跑起来了
如果只看微软这一篇，容易觉得这是个「未来趋势」。把 10 月 21 日那篇放一起看，性质就变了。
微软同一天发了一份威胁情报：一个叫 Storm-0940 的、被判定为中国国家背景的攻击者，用一套叫 ARTEX 的智能体渗透框架，从 2026 年 9 月起自动化攻击了全球数百家组织，横跨多个行业。其中多起案例，从锁定目标到拿到云基础设施的特权访问，用时不到 3 小时。
而且它把这套东西挂到了一条真实的供应链上——微软认定 Storm-0940 就是最近 ConnectWise 多租户应用供应链事件的实施者。攻击路径是先拿下应用，再用这个应用已经获批的权限去认证 Microsoft 365 客户环境，全程不需要交互式登录。
微软在文里写了一句很到位的话：「Agent 不受人类所受的限制——它可以 7×24 工作，周末、假期照跑，同时尝试多条入侵路径。」
把两篇合起来看，2026 年 10 月这一周的形状就出来了：
- 10 月 10 日，CEO 定调：模型是内部风险，责任不能外包；
- 10 月 19 日，框架落地：发现、限制、保护、调整；
- 10 月 21 日，对面开火：3 小时拿特权。
一边是自己的 Agent 太能干，一边是对手的 Agent 太快。这两条线在同一个季度撞上，就不是趋势预测了，是当期风险。
八、不同位置的人，现在能做什么
我不太喜欢「企业应当建立体系」这种话，说了等于没说。按角色分一下。
如果你是 CISO 或安全负责人
第一件事不是买 E7，是先把你家的 Agent 清一遍。微软这套东西的起点是「看不见就管不了」，你自己的起点也一样。现在就去问三个问题：公司里跑着多少个 Agent、谁建的、各自拿了什么权限。我猜大部分公司答不上来第三个。
第二件事是把身份拆开。Agent 用人的身份干活，是现在最常见的做法，也是最容易出事的地方——出了事你连「是人干的还是 Agent 干的」都分不清。没有 Entra 也能做，给 Agent 单独开服务账号、单独发凭证，是纯管理动作，不花钱。
如果你是 IT 或平台团队
最小可落地版本是四样：容器隔离（别让 Agent 直接跑在宿主机上）、按任务发凭证（别用长期 AK）、出站流量管控（Agent 的每一次外部调用都记下来）、动作日志集中（别只信 Agent 自己的回执）。这四样都不需要 E7。
如果你是开发者
有一条现在就该改：别把权限校验写在提示词里。「你不许访问 /etc」这种话，在提示词层面不是安全控制，只是建议。真正的边界得在工具层、在网络层、在系统调用层。这一点无论你用哪家的 Agent 都成立。
如果你是在小团队、没有预算
微软那四条动词其实可以手写：一张 Agent 清单（Know）、一份每个 Agent 允许做什么的表格（Contain）、每个 Agent 单独的最小权限凭证（Protect）、日志接一个能查的地方并且每周看一次异常（Adapt）。工作量一周之内，效果不比产品差多少。
九、最后一句判断
微软这次真正改的不是产品线，是一个默认值。
过去十年，企业安全的默认值是「内部可信、边界防御」。零信任花了很久才把这个默认值改过来，而且到现在还有一半公司在用「内网就是安全的」这套思路。
Agent 把这个问题又推了一遍，而且推得更狠：它不是一个可以被培训、可以被纪律约束、可以被离职流程处理的内部人。它没有记忆里的忠诚，也没有利益上的顾虑。它只有权限。
所以那个问题的答案很简单，也很难：你给它多少权限，它就能造成多大的破坏，不多也不少。
微软给的解法是把权限收到极限——零权限起步、按任务发、按时限收、高风险要人批。这个思路不新，就是把最小权限原则推到了机器速度。新的地方在于，它第一次承认了：在这套体系里，你不能靠信任任何一个模型来获得安全，你只能靠不信任它来获得安全。
这句话如果成立，那接下来所有卖 Agent 的厂商都得回答同一个问题：你的模型可以被不信任到什么程度，系统还能正常跑？
答案不好的，就是下一个被划进名单的。