微软推出守护智能体，专盯 AI 员工

微软正在把企业内部的 AI Agent，从需要保护的生产力工具，重新定义为需要持续监控的潜在内部威胁。

当地时间 10 月 19 日，微软推出 Guardian Agents，中文可译为“守护智能体”。Guardian Agents 是一套用于监控企业内部 AI Agent 行为的安全能力，隶属于微软今年 6 月发布的 Project Perception。微软安全业务负责人 Hayete Gallot 对此给出了相当直接的判断：无论来自哪家供应商，前沿模型都无法被完全信任。

这不是一次常规的内容审核功能更新，而是企业 AI 安全思路的一次转向。过去，企业主要防止外部攻击者利用提示词注入、模型漏洞或者恶意文件攻破 Agent；现在，微软要求企业进一步假设：已经通过采购、部署和身份认证的 Agent，本身也可能像失控员工一样做出危险操作。

Guardian Agents 是什么

Guardian Agents 是微软面向企业 AI Agent 推出的独立监控型智能体，核心任务是观察其他 Agent 的行为，并识别其中可能违反组织规则或偏离预期目标的操作。

按照微软目前披露的信息，Guardian Agents 属于 Project Perception 的新增角色。Project Perception 是微软构建的一套智能体安全体系，最初包含红队、蓝队和绿队三类 Agent，分别负责模拟攻击、检测风险和修复漏洞。

Guardian Agents 把 Project Perception 的防护边界从“外部攻击如何进入系统”，扩展到了“内部 Agent 正在系统里做什么”。这种变化很关键，因为能够自主执行任务的 Agent 已经不只是生成文字，它还可能读取邮件、查询客户数据库、调用内部工具、修改代码、创建工单，甚至发起影响真实业务的操作。

| Agent 类型 | 核心职责 | 主要观察对象 | 典型输出 | |---|---|---|---| | 红队智能体 | 模拟攻击并寻找突破口 | 应用、模型与工具链 | 攻击路径、漏洞证据 | | 蓝队智能体 | 发现攻击并评估风险 | 红队行为与系统事件 | 告警、风险评级 | | 绿队智能体 | 修复已识别的问题 | 漏洞与错误配置 | 补丁、配置调整建议 | | Guardian Agents | 监控企业内部 Agent | Agent 的任务、权限和实际行为 | 异常识别与治理信号 |

Guardian Agents 与传统安全产品的最大区别，在于它监控的不是一个静态程序，而是一个会根据上下文临时规划行动的概率系统。传统应用在输入相同、状态相同的情况下，行为通常比较确定；大模型 Agent 则可能因为提示词、记忆内容、工具返回结果甚至任务拆分顺序的变化，选择不同的执行路径。

微软为什么突然把 Agent 当作内部威胁

“内部威胁”是指已经获得组织合法访问权限的人员或系统，因为恶意、失误或行为失控，对数据和业务造成损害的安全风险。

微软首席执行官萨提亚·纳德拉本月早些时候提出，企业不能把 Agent 的行为责任外包给 OpenAI、Anthropic 或其他模型供应商。即使供应商承诺模型经过安全训练，企业仍然需要建立一套不受模型实验室直接控制的监督系统，把智能能力的供应方和管控方分开。

这个判断并非意味着模型本身具有恶意，而是模型的训练目标与企业治理目标并不完全一致。模型擅长的是完成任务，但企业真正关心的是：任务是否应该完成、能否使用这些数据、是否需要人工批准、操作是否违反审计要求，以及失败后能否追责。

一个销售 Agent 接到“整理高价值客户名单”的任务时，最有效率的做法可能是读取 CRM、邮件和会议记录，再把结果写入共享文档。但从企业安全角度看，它至少涉及三个问题：Agent 是否应该访问全部客户数据、共享文档的权限是否覆盖外部人员，以及模型有没有把敏感信息发送给不应接收的人。

一个代码 Agent 的风险会更加直接。它可能为了修复故障而修改生产配置，也可能因为仓库文档中的恶意指令调用高权限工具。即使模型没有被攻破，只要它错误理解目标、过度执行任务或继承了过高权限，结果就可能接近一次真实的内部安全事件。

Agent 安全已经不只是过滤输入输出

传统 Guardrails 是围绕模型输入和输出设置的规则层，主要负责拦截敏感内容、越狱提示和不合规回答。

Guardian Agents 面向的则是执行层风险。一个 Agent 完全可能生成合规文本，却在后台调用了错误工具；也可能每一步操作单独看都合理，但连续组合后形成数据泄露、权限扩张或业务破坏。这也是仅靠关键词过滤和内容审核难以解决的问题。

| 安全机制 | 主要解决的问题 | 能否覆盖工具调用 | 能否观察跨步骤行为 | 典型局限 | |---|---|---:|---:|---| | 内容 Guardrails | 有害内容、越狱、敏感输出 | 部分 | 较弱 | 容易忽略实际执行结果 | | DLP 数据防泄漏 | 敏感数据外传 | 是 | 部分 | 通常不理解 Agent 的任务意图 | | IAM 权限控制 | 谁能访问什么资源 | 是 | 否 | 合法权限仍可能被错误使用 | | SIEM 安全分析 | 汇总日志并检测异常 | 是 | 是 | 需要针对 Agent 设计事件语义 | | Guardian Agents | 识别 Agent 行为偏差 | 目标上是 | 目标上是 | 具体覆盖范围尚待微软披露 |

真正棘手的地方是“有权限”和“应该执行”并不是一回事。数据库账号可能允许 Agent 导出 10 万条记录，但用户的一次自然语言请求未必构成导出全部数据的正当理由；代码 Agent 可能拥有合并权限，但这不代表它可以跳过测试直接更新生产分支。

因此，Guardian Agents 的价值不应该只是给 Agent 再套一层内容过滤，而是尝试建立面向 AI 行为的策略判断层。这个判断层需要理解任务来源、身份、上下文、工具调用、数据流向和最终结果，并对一整条执行链进行关联分析。

守护智能体至少要看懂四类风险

工具滥用是 Agent 在拥有合法工具权限的情况下，因为提示词注入、目标误判或规划错误而执行非预期操作。

第一类风险来自工具调用。企业需要知道 Agent 调用了什么工具、使用了哪些参数、读取了哪些对象，以及调用结果是否又被发送到了其他系统。只记录模型最终回答，无法还原真实影响。

记忆投毒是攻击者把恶意或错误信息写入 Agent 的短期上下文或长期记忆，使其在未来任务中持续做出错误判断。

第二类风险来自记忆系统。与一次性聊天不同，企业 Agent 会保存客户偏好、任务状态和历史结论。恶意内容一旦进入长期记忆，可能在数天甚至数周后被重新调用，形成延迟触发的攻击。

权限滥用是 Agent 利用继承权限、服务账号或配置缺陷，执行超出当前任务合理范围的操作。

第三类风险来自身份与权限。企业不能只检查 Agent 是否“有权”调用工具，还需要判断当前用户、当前任务和当前数据是否构成充分授权。否则，一个权限配置正确的 Agent，仍可能做出业务上错误的决定。

多智能体委托风险是上游 Agent 把任务转交给其他 Agent 后，权限、上下文和责任边界在传递过程中发生变化。

第四类风险来自 Agent 之间的协作。一个前台助手可能没有数据库权限，却可以把任务委托给数据分析 Agent；数据分析 Agent 又可能调用拥有导出能力的后台工具。每一次委托单独看都符合规则，但最终形成了一条绕过原始权限限制的链路。

Guardian Agents 真正有用的前提是独立

独立监督平面是指负责审计和约束 Agent 的系统，与提供基础模型和执行能力的系统保持权限、日志和策略上的分离。

纳德拉强调的“能力供应与管控权限分离”，实际上是在把零信任原则移植到 Agent 时代。企业不能因为某个 Agent 使用了知名模型，就默认其输出可靠；也不能因为它由内部员工启动，就默认整个工具调用链符合组织政策。

这种独立性至少应包含三个层面：

1. 日志独立：被监控的 Agent 不能自行删除或改写关键审计记录。
2. 策略独立：行为规则不能完全由同一个基础模型解释和执行，否则判断错误可能同时影响执行者与监督者。
3. 权限独立：Guardian 应具备暂停、降权或请求人工审批的能力，但不应默认继承业务 Agent 的全部数据权限。

微软提出这个方向有现实意义，但“用 AI 监督 AI”并不会自动解决可信问题。如果 Guardian 与被监控 Agent 依赖相同模型、相同上下文和相同策略，它们可能出现相关性失败：执行者误判任务，监督者也以相似方式误判，最终只是在错误操作之外增加一层形式化确认。

更合理的设计是把确定性规则和模型判断组合使用。金额阈值、数据分类、目标域名、身份范围等可以由明确策略强制执行；只有难以用固定规则表达的任务意图、上下文偏差和复杂行为链，才交给守护模型辅助判断。

微软没有讲清楚的部分仍然很多

Guardian Agents 当前更像一套重要的安全方向，而不是已经得到充分验证的完整答案。

截至 2026 年 10 月 20 日，公开信息尚未给出 Guardian Agents 的价格、正式可用范围、支持的第三方 Agent 框架、部署方式、检测延迟和误报率。微软也没有公开其对提示词注入、记忆投毒或越权调用的量化测试结果。

| 关键信息 | 当前公开状态 | 企业采购时应追问的问题 | |---|---|---| | 定价 | 未披露 | 按 Agent、事件量、用户数还是算力计费 | | 上线范围 | 未完整披露 | 是预览、定向开放还是普遍可用 | | 第三方模型支持 | 未明确 | 能否监控 OpenAI、Anthropic 及自托管模型 | | 第三方框架支持 | 未明确 | 是否兼容主流 Agent 编排与可观测系统 | | 阻断能力 | 未明确 | 只能告警，还是可以暂停工具调用 | | 检测效果 | 无公开基准 | 误报率、漏报率和检测延迟分别是多少 | | 数据边界 | 未明确 | 提示词、记忆和工具结果会被保存在哪里 |

缺少这些数据，会直接影响 Guardian Agents 的实际价值。如果系统只能在事后生成告警，它更接近面向 Agent 的日志分析工具；如果它能在高风险工具调用发生前完成判断、触发人工审批并保留可审计证据，才更接近真正的运行时防护层。

性能开销同样不能忽略。一个 Guardian 若需要检查每次模型推理和工具调用，就会增加延迟与推理成本；若采用抽样监控，又可能漏掉低频但高风险的操作。微软必须在覆盖率、响应速度和成本之间给出可量化的答案，而不是只强调“持续监控”。

这也是微软的一笔平台生意

微软把前沿模型描述为不可完全信任，既是安全判断，也是明确的商业定位。

微软一方面与 OpenAI 保持深度合作，并通过 Azure 提供模型与 Agent 基础设施；另一方面又希望企业使用微软的身份、安全、云和合规产品监督这些 Agent。模型越强、权限越高、使用范围越广，独立治理层的需求就越大。

这种角色并不矛盾，却要求微软证明 Guardian Agents 不只是绑定自家生态的附加模块。企业内部往往同时存在微软 Copilot、OpenAI 模型、Anthropic 模型、自托管开源模型和部门自行采购的 SaaS Agent。如果 Guardian 只能完整观察微软体系内的工作负载，它很难成为真正统一的 Agent 安全控制面。

微软的优势在于其已经占据企业身份、终端、云平台和安全运营等关键位置。相比只提供模型的厂商，微软更容易把 Agent 的用户身份、设备状态、数据权限和工具调用记录关联起来；但这也意味着客户需要评估新的平台依赖，以及监控数据是否会形成更集中的敏感信息资产。

企业现在不该等 Guardian 来兜底

企业部署 Agent 时最重要的原则，仍然是最小权限、完整审计和高风险操作人工确认。

Guardian Agents 可以成为额外的观察者，但不能替代基础安全工程。一个拥有全盘数据库权限、可以直接执行付款、又没有操作日志的 Agent，不会因为旁边多了一个监督 Agent 就突然变得安全。

企业当前至少应该完成以下工作：

• 为每个 Agent 分配独立身份，避免多人和多个 Agent 共用服务账号；
• 将读取、写入、删除、发布和付款等权限拆开，不给默认全权限；
• 记录模型输入、工具调用、参数、返回结果和最终动作之间的关联；
• 对批量导出、生产变更、资金操作设置确定性的审批门槛；
• 隔离外部网页、邮件附件与内部指令，降低间接提示词注入风险；
• 定期清理和验证长期记忆，避免错误信息持续影响后续任务；
• 为 Agent 设置调用次数、执行时间和资源消耗上限；
• 准备一键撤销身份、令牌和工具权限的应急机制。

微软这次最值得关注的并不是又发布了一个安全 Agent，而是公开承认“模型供应商的安全承诺不等于企业可以免责”。当 Agent 开始代表员工调用工具和改变现实系统时，它就不再只是一个聊天界面，而是一个拥有机器速度、动态决策能力和真实权限的新型内部主体。

Guardian Agents 的方向是对的，但产品是否有用，最终要看它能否跨模型工作、能否在执行前阻断风险，以及能否用可接受的延迟和误报率持续运行。在微软公开这些关键数据之前，企业可以认可它提出的问题，却不必急着接受它给出的答案。

参考来源

• IT之家：微软警示前沿 AI 模型不可信，推出 Guardian Agents 防护方案——介绍 Guardian Agents、Project Perception 及微软对 Agent 内部威胁的判断。
• Microsoft Agent Framework 官方 GitHub 仓库——用于了解微软智能体框架、工具调用和运行时组件的技术背景。