微软Project Perception：针对AI代理内部威胁的守护代理

微软10月19日的扩展将企业内部运行的每一个自主AI代理重新定义为潜在的内部威胁 ^[2]。其理由明确表达了对底层模型的不信任：执行副总裁Hayete Gallot表示，无论来源如何，前沿模型都无法被完全信任，并非因为它们具有恶意，而是因为它们具有不可预测性 ^[1]。首席执行官Satya Nadella进一步推进这一逻辑，认为安全架构必须将AI智能的‘供给’与‘行动授权’分开，将能够访问敏感数据的代理视为本质上具有风险的设计，而非基于其行为表现来判断风险 ^[1]。这对于一家销售此类模型的公司而言是一个显著的转变——微软实际上是在告诉客户，不应依赖任何模型自身的推理来保障安全，而应依赖围绕模型构建的外部隔离机制。

微软为实现这种不信任所构建的机制是守护代理——一个监督层，在另一个代理执行操作前评估其每一项意图 ^[3]。每个被监控的代理都携带一个持续更新的动态代理风险评分，该评分由身份、数据、终端、云、网络和运行时信号以及代理自身行为综合而成；当行为偏离代理的指定任务时，评分会上升 ^[3]。评分上升可触发任务范围内的动态权限或动态条件访问，限制代理可接触的内容，将操作路由给人类审批，或将其置入微软执行容器，从而为在Windows上运行的代理提供策略驱动、操作系统级别的隔离 ^[3][7]。这一切都不需要人类实时监控——一旦风险超过阈值，限制将自动生效 ^[2]。该架构细节之丰富，以至于独立的微软MVP和技术培训师纷纷自行制作技术解析视频，而非仅将公告视为新闻稿浏览，其中一份独立分析视频长达近30分钟，完整演示了整个系统。

Project Perception最初并非作为内部风险工具推出。微软于2026年7月27日将其作为防御外部AI驱动攻击的系统发布，核心是红队（Red teams）绘制攻击路径，蓝队（Blue teams）分类处理信号，绿队（Green teams）编写并发布修复方案 ^[4]。该版本依赖于微软首个自研安全模型MAI-Cyber-1-Flash，该模型承担了此前MDASH漏洞发现系统约95%的工作量，并在CyberGym‘任意崩溃’基准测试中得分96%，成本约为此前的一半 ^[4][5]。10月19日的扩展将相同的红/蓝/绿机制转向内部，将其应用于企业自身的代理集群，而不仅限于外部攻击者——这种基础设施的再利用表明，微软认为内部代理风险与外部攻击防御实为同一问题的两个方面。

除了守护代理外，微软还扩大了Microsoft Defender中的代理发现范围，覆盖员工设备上的60种本地代理类型，其中35种为新增——包括第三方编码代理如Claude Code和Codex，而不仅限于微软自家的GitHub Copilot ^[3]。这一细节比初看更为重要：这意味着‘代理型内部人员’的框架明确与供应商无关，且在此之前，安全团队对其终端上已运行但未经批准的AI编码代理仅有部分可见性。此举实际上使IT部门面临比此前认知更为严重的影子代理清点问题。

独立反应比微软自身的表述更为谨慎。Forrester分析师Allie Mellen称守护代理、红队、蓝队和绿队之间的协调是‘比微软早期MDASH工具更高层级的协调与评估’，但她警告目前的公开演示仅局限于Web应用加固，敦促企业在大规模信任该系统前，要求具备可观测性、最小权限访问和真实数据访问验证 ^[6]。一位技术评论员也划清了仅标记潜在问题的安全代理与能够复现问题并获得修复批准的代理之间的界限——这一区别直接对应守护代理和动态代理风险旨在实现的目标，但目前尚未在微软自身演示之外获得独立验证。