2026 年 8 月 26 日,Microsoft Learn 文档站上线了一份名为"AI Agent Shared Responsibility Model"的官方文档,这是第一家头部云厂商把云时代延续了十余年的 Shared Responsibility(共享责任)模型,系统性地平移到 AI Agent 部署语境上。文档首次给出了一张可对照的 IaaS/PaaS/SaaS 三列责任矩阵,明确列
2026 年 8 月 26 日,Microsoft Learn 文档站上线了一份名为"AI Agent Shared Responsibility Model"的官方文档,这是第一家头部云厂商把云时代延续了十余年的 Shared Responsibility(共享责任)模型,系统性地平移到 AI Agent 部署语境上。文档首次给出了一张可对照的 IaaS/PaaS/SaaS 三列责任矩阵,明确列出 13 项 Agent 特有的责任项,每项用 C(客户)/M(微软)/S(共享)三种归属打标;同时把 AI Agent 系统拆成 6 层——基础模型、Agent 编排与指令层、工具与动作层、Agent 记忆与状态层、AI 应用层、AI 使用层——并对每一层分别给出安全注意事项。这份文档的工程含义远超过微软自家的产品边界,它事实上给整个企业级 AI Agent 落地定下了一条责任划分的"基线坐标":在 Agent 自动执行动作已经成为现实之前,所有人都在含糊地谈论"AI 责任归属";在 Agent 真正开始写邮件、改代码、跑支付之后,这种含糊不能再持续。微软这份文档,加上 2025 年 12 月发布的 OWASP Top 10 for Agentic Applications(ASI01-ASI10)与 OWASP MCP Top 10,共同构成了 2026 年下半年企业部署 AI Agent 时必须同时看两份坐标系的合规参考。
一、从 Shared Responsibility 到 Agent Shared Responsibility:一次系统性平移
云时代 Shared Responsibility 模型的核心思想非常简洁:云厂商负责"云本身"(物理基础设施、虚拟化层、存储、网络、计算硬件),客户负责"云里的东西"(数据、访问控制、应用代码、操作系统补丁、用户行为)。在 IaaS 部署里,客户还要额外承担运行时、容器、操作系统、数据库的配置责任;在 PaaS 里这些下沉到云厂商;在 SaaS 里客户几乎只负责数据与访问权限。这一模型在过去十几年里运转良好,因为云的每一层都有清晰的物理边界。
AI Agent 把这套模型打碎了——或者说把它推到了一个必须被重新分层的复杂度。Agent 的核心特征是动作(action)。Chatbot 给一个答案就完事;Agent 接一个目标,然后自主决定要调用哪些工具、改哪些状态、发哪些消息。这种"动作"维度引入了几类全新的风险:工具被恶意 prompt 诱导(ASI01 Goal Hijack)、Agent 滥用合法工具(ASI02 Tool Misuse)、Agent 自身身份与权限在跨任务中被滥用(ASI03 Identity & Privilege Abuse)、Agent 通过供应链上的 MCP server / plugin 引入漏洞(ASI04 Agentic Supply Chain)、Agent 自动生成的代码在没有沙箱的情况下被执行(ASI05 RCE)、Agent 长期记忆被注入内容污染并在后续任务中复现(ASI06 Memory Poisoning)、多 Agent 之间的消息互信失败(ASI07 Inter-Agent Communication)、一个 Agent 失败导致整个系统级联崩溃(ASI08 Cascading)、过度信任 Agent 输出导致人类被社会工程(ASI09)、Agent 自主越界做事(ASI10 Rogue Agents)。
微软文档把这十类威胁压成了一条非常具体的责任归属原则:"The more autonomy and the broader the tool and permission set that you grant an agent, the more of the responsibility matrix shifts to you, regardless of deployment model. Autonomy never reduces accountability"。换句话说,自主性越高、责任越向客户倾斜,这条原则不因部署模式而改变。这意味着,即使你买的是 SaaS 版 Copilot,只要你给它授权了"可以发邮件"、"可以改文档"、"可以调用支付 API"这些动作,你就已经在把责任从微软手里接过来。
二、6 层架构 + 13 项 Agent 特有责任:一份可对照的工程坐标系
微软文档把 AI Agent 系统拆成 6 层,每一层都对应一组安全考虑,这套拆解方式是工程上第一次出现的可对照模型。
L0 基础模型层。模型托管、权重安全、推理基础设施。在 SaaS 部署下完全是 M(微软负责);在 IaaS 自托管场景下完全由客户负责;在 IaaS 但使用托管模型 API 时由微软负责模型侧、客户负责集成侧。
L1 Agent 编排与指令层。包括 Agent 自身的 system prompt、任务规划循环、ReAct / Plan-and-Execute 等编排逻辑。这是 Agent 与传统 LLM 应用最大的差异——多步迭代、循环检测、step limit、iteration limit、cost ceiling 等编排护栏都属于这一层。OWASP 与微软都强调:指令和数据必须严格隔离(treat all retrieved content as untrusted input),这一步是把 prompt injection 隔离在 action 之外的关键防线。
L2 工具与动作层。包括 connector、plugin、function、MCP server、Agent 能调用的所有 API。这是 LLM 模型没有的全新一层,也是最大的一块 Agent 特有责任。文档给出的四条核心要求是:最小权限 per tool(不要给 Agent 一个 broad standing identity)、每次 action 都重新做授权检查(不能只在 session 开始时授权一次)、高影响/不可逆动作必须 human-in-the-loop(写、删、付款、生产变更、外部发送)、完整的 action audit logging(输入、输出、使用的身份、决策依据)。
L3 Agent 记忆与状态层。短期对话上下文 + 长期记忆 + 向量库 + scratchpad。文档明确警告:记忆必须按用户/租户隔离,防止 cross-user / cross-session memory bleed;记忆内容必须做来源追踪(防止 memory poisoning);记忆必须按数据分级、保留期、删除权管理;记忆存储必须加密 + 强制访问控制(把记忆当敏感数据对待)。这一层如果设计不当,Agent 会在数月之后被一条三年前注入的恶意记忆触发异常行为,而所有这段时间内的任务执行记录都会被污染。
L4 AI 应用层(从原 AI 共享责任模型继承)+ L5 AI 使用层(从原模型继承并扩展)。这两层是 LLM 时代就有的责任,但在 Agent 时代各自多了一层含义:应用层要承担 grounding、插件、应用安全系统的责任;使用层则新增了"谁对 Agent 在用户名义下做的动作负责"这一条——这条直接对应 OWASP ASI09 Human-Agent Trust Exploitation。
把 13 项 Agent 特有责任按 C/M/S 打标形成的矩阵,关键的几行值得专门看。"Agent 指令、system prompt、scope" 在 IaaS/PaaS 是 C(完全客户负责),在 SaaS 是 S(共享——Copilot 提供 system prompt,客户可以再覆盖一层 scope);"per-tool permissions(最小权限)" 在 IaaS/PaaS 是 C,在 SaaS 是 S;"Human-in-the-loop approval for high-impact actions" 在三种部署下都是 C——这条特别值得注意:任何影响生产的高风险动作的最终审批责任,无论部署模式,都必须是客户的。云厂商不会替你按"同意"按钮。
三、OWASP Agentic Top 10 与 MS 责任矩阵的对应关系
把 OWASP 2025-12 发布的 Agentic AI Top 10 与微软的责任矩阵叠在一起看,会发现责任矩阵里的每一行,几乎都对应着 OWASP 的一条威胁。
ASI01 Goal Hijack(prompt injection 劫持 Agent 目标)对应矩阵里"Agent 指令、system prompt、scope"和"multi-agent trust-boundary controls"两项,要求客户在 L1、L2 层做输入安全检查与多 Agent 信任边界控制。OWASP 同时在博客中给出真实 CVE 案例:EchoLeak CVE-2025-32711(2025 年披露的 Microsoft 365 Copilot 0-click prompt injection,无需用户交互就能窃取机密邮件)就是 ASI01 的活样本。
ASI02 Tool Misuse & Exploitation 对应矩阵里的 "per-tool permissions" 和 "tool and action sandboxing and egress control"。这条责任在 SaaS 模式下与微软共享,在 IaaS/PaaS 模式下完全由客户负责——客户必须保证每个工具的最小权限、沙箱隔离、出向网络代理。
ASI03 Identity & Privilege Abuse 对应矩阵里 "Agent identity and delegated token management" 与 "Per-action authorization checks"。这条对应到 Agent 在拿到 OAuth token、跨服务调用时,很容易出现"用特权身份做用户本来不能做的操作"——confused deputy 与 over-broad delegation 是 Agent 时代特有的一类漏洞。OWASP 给出的真实案例是 AutoJack(AutoGen Studio 的 RCE)与 ChatGPT Memory Poisoning——后者是 Agent 在长期记忆中保留了被注入的"指令",后续任务里被该指令激活,执行了用户本来不会授权的动作。
ASI05 Unexpected Code Execution 对应矩阵里 "Tool and action sandboxing and egress control"。这是 L2 层的责任,要求客户为所有"代码执行"类工具(shell、Python REPL、code interpreter)强制加沙箱;为所有"浏览器类"工具强制出向网络代理。OWASP 给出的对应案例是 CVE-2025-55319(VS Code Agentic AI 命令注入,无需用户交互)与 JADEPUFFER(基于 Langflow CVE-2025-3248 的全自主 AI 勒索软件攻击)。
ASI06 Memory & Context Poisoning 对应矩阵里 "Memory design, isolation, and poisoning defense"。这条完全对应 L3 层责任,客户必须自己设计记忆隔离、来源追踪、保留与删除规则——云厂商不会替客户决定哪些记忆可以保留多久。
ASI07 Insecure Inter-Agent Communication 对应矩阵里 "Multi-agent trust-boundary controls"。这条在 IaaS 下完全由客户负责,在 PaaS/SaaS 下与微软共享——本质上是"每一次 Agent 之间的消息传递,都要重新做输入安全检查"。
ASI10 Rogue Agents 对应矩阵里 "Agent runtime and orchestrator platform" 与 "Action audit logging and monitoring"。这条责任在 SaaS 模式下完全在微软(PaaS 下与微软共享,IaaS 下完全在客户),微软负责 runtime 与 orchestrator 的安全,客户负责监控与审计。
四、Configure before you customize:三种部署模式的渐进选择
微软文档给出了一条非常具体的渐进建议:先 SaaS,再 PaaS,最后才 IaaS。这条建议的工程逻辑非常硬——它不是营销话术,而是基于责任矩阵的实际分布。
起点:SaaS Agent。Microsoft Copilot、Microsoft Security Copilot、Microsoft Copilot Studio 上发布的 Agent。在 SaaS 模式下,微软负责 orchestration、模型安全、大部分工具安全;客户只需要配置数据范围(scope)、身份(RBAC、MFA、Conditional Access)、可用的工具列表、可调用的数据集。SaaS Agent 适合"业务方想试试 AI 自动化,但不想从零搭基础设施"的场景。
进阶:PaaS Agent。当 SaaS 不能满足需求(例如要接企业内部系统、要定制工具链、要持久化记忆),迁移到 PaaS——Microsoft Foundry Agent Service、Azure SRE Agent、自定义 Copilot Studio Agent、Microsoft Agent Framework on managed runtime。在这个层级上,客户开始接手 Agent 的业务逻辑、工具清单、权限模型、记忆设计、身份系统。微软保留 platform runtime 与 orchestration 框架,客户接手业务面。
专业:IaaS Agent。只在客户拥有深厚的 AI 安全、身份、自主系统风险专业能力时,才在 IaaS 上自建 Agent runtime。在 IaaS 模式下,客户几乎承担整个 stack 的责任——模型托管、编排、工具链、记忆、身份、审计、emergency shutdown。IaaS Agent 适合金融、医疗、国防等高度敏感场景,客户必须有专门的安全团队运营。
这条渐进路径的工程意义在于:每向下一层,客户就要多承担一组责任——不是"我选了 PaaS 就省事了",而是"我选了 PaaS 就要自己管工具、记忆、身份这三块"。在云时代,这种"上层更省事、下层更灵活"的渐进式选择是常识;但 Agent 时代这条路径变得更加陡峭,因为Agent 的每一层都比云对应层多一层"动作安全"。
五、对企业级 AI Agent 落地的具体工程启示
把微软责任矩阵 + OWASP Agentic Top 10 + 渐进选择路径这三件事放在一起,可以给正在做 Agent 落地的企业提出六条非常具体的工程启示。
第一,采购 Agent 服务前必须先把责任矩阵翻译成自己内部的 RACI。把微软文档里 13 项 Agent 特有责任一项项认领给企业内部具体角色——业务方、IT、安全、法务、运维、采购——并写入合同条款。不要等到第一次 Agent 事故发生时才讨论"这事谁负责"。
第二,在 IaaS/PaaS 自建 Agent 时,必须把工具与动作层(L2)作为头号安全工程对象。这块是 Agent 特有责任,客户必须从设计阶段就强制实施最小权限 per tool、每次 action 重新授权、human-in-the-loop、action audit logging 四件套。OWASP 给出的真实 CVE(EchoLeak、AutoJack、JADEPUFFER、CVE-2025-55319)每一例都涉及 L2 层失控。
第三,记忆层(L3)必须有独立的治理模型。记忆不能等同于日志——它会持续影响未来行为,被注入内容会跨任务复现。客户必须设计:记忆按用户/租户隔离、记忆内容做来源追踪、记忆保留期与删除权严格落地、记忆存储加密且独立审计。
第四,多 Agent 通信必须做"信任边界 + 输入安全重做"。每一条 Agent-to-Agent 消息都要被当作"来自另一个主体的输入"重新做输入安全检查,无论发送方 Agent 在你的组织内看起来多可信。OWASP ASI07 与微软矩阵的"Multi-agent trust-boundary controls" 都强调这条。
第五,human-in-the-loop 必须是"高风险动作 + 不可逆"的硬门禁。任何写、删、付款、生产变更、外部发送,都必须经过人类审批。微软文档明确把这一项责任标记为三种部署模式下都是 C——客户必须自己设计审批工作流,云厂商不会替你按"同意"。
第六,渐进选择不是营销话术,是工程策略。90% 的企业 Agent 落地场景在 SaaS 层就能满足需求;PaaS 是给"需要接企业内部系统"的;IaaS 是给"高度敏感、自主可控"的。每向下一层,客户都要多承担一组责任;在没有专门安全团队的情况下选择 IaaS,几乎必然会在 OWASP Top 10 上撞到问题。
六、自主性越高,责任越向客户倾斜
回到微软文档最后那句总结:"Autonomy never reduces accountability"——自主性不会减少责任。这条原则把 AI Agent 时代的安全责任划分从云时代的"按部署模式划分"推进到了"按自主性划分"。在云时代,责任是按"我在哪一层"切;在 Agent 时代,责任是按"我让 Agent 能做什么"切。一家购买了 SaaS Copilot 的企业,如果只让它生成摘要,基本不需要担心责任;同一家企业如果让它能改文档、能发邮件、能调支付 API,责任就立刻从微软手里流到了自己手里,而且这种责任的流入不是合同里某一条款规定的,是 Agent 实际拥有的能力决定的。
OWASP Agentic Top 10 与微软责任矩阵的同步出现,说明 2026 年下半年的企业 AI Agent 落地已经进入"基础设施成型期"——之前大家在讨论"该不该用 Agent",现在大家在讨论"用了之后责任怎么分"。这次系统性平移的工程意义,在于它把过去十余年云时代积累的 Shared Responsibility 模型,正式扩展到了"能动的 AI"这个新维度。这个扩展并不优雅——它比传统云模型复杂得多,涉及 6 层架构、13 项 Agent 特有责任、3 种部署模式、10 类威胁——但它比继续含糊地谈论"AI 责任"要工程化得多。任何想在 2026 年下半年认真落地 AI Agent 的企业,都应当把微软这份文档与 OWASP Agentic Top 10 同时摆在案头:前者告诉你责任怎么分,后者告诉你风险怎么列。两者一起读,才能避免在 Agent 真正开始替你做事的那一天,被一个意外的责任事故打个措手不及。
