E01 微软 Agent Identity Perimeter 剖解 · 知识库

当 Agent 能自主调工具、花钱、spawn 子 agent，“它是谁、它能动什么、出事谁负责”就从一个抽象命题变成了一笔必须落到身份系统里的账。本节点解剖 2026 年最激进的一份答卷——微软把 Agent 当一等身份主体纳入 Entra 治理体系（Entra Agent ID + Agent 365 + “身份即边界”的安全架构）——看它做对了什么、赌错了什么、以及一个有滴滴风控背景的 PM 该从中读出哪些可迁移的教训。这是一篇得失剖解，不是产品介绍：判断主轴是「大厂把 agent 当一等身份主体治理，到底解决了什么、又制造了什么新问题」。

§0 为什么用”身份主体”这个框架，而不是”工具权限”框架

在解剖微软方案前，先挡掉一个默认错误框架。很多 PM 第一反应是把 agent 安全等同于「给工具加白名单」——这是 m208 - AI 基础设施与中间件选型时代的工具权限视角，本专题的 S 系列（架构剖面）也会处理。但微软选了一条更高抽象层的路：先回答”agent 是谁”，再回答”它能动什么”。

这两个框架的差别不是文字游戏。工具权限框架里，权限是绑在「调用方」身上的——谁持有 token，谁就有权限，token 本身不区分背后是人、是脚本还是 agent。身份主体框架则坚持：agent 必须拥有自己的、可被独立审计和吊销的身份，它的权限来自”这个 agent 被授予了什么”，而非”它现在手里攥着谁的凭证”。微软官方反复强调的一句话是 “Identity is the foundation of modern security… the first line of defense”（来源：Microsoft Security Blog，Secure agentic AI end-to-end，2026-03-20，WebFetch 核实）。这正是 0435 红队专题 S03 的核心命题”权限是最后防线”的镜像——红队从攻击面看权限是最后一道闸，微软从治理面看身份是第一道闸，两者夹住的，正是 agent 行为的全部责任空间。

[!note] 为什么这个框架升高了抽象层给人设计的传统 IAM（Identity and Access Management）默认身份的颗粒度是”一个自然人 = 一个账号 = 一套凭证 = 一条可问责的行为基线”。agent 把这套假设全部打碎：一个 agent 可以 spawn 出几十个子 agent，每个子 agent 寿命几秒，行为完全由运行时的自然语言指令决定。给人设计的 IAM 在此整体失效——不是某个控件不够用，而是”身份 = 人”这条公理本身不成立了。微软的赌注是：与其发明全新范式，不如把企业里已经验证了二十年的 Entra（前身 Azure AD）身份引擎，扩张去吞下 agent 这个新物种。

§1 微软方案的解剖：四个咬合的部件

微软不是出了一个产品，而是搭了一条从身份签发到运行时治理的链。把它拆成四块（均经 WebFetch / WebSearch 核实，版本与日期见下）：

部件	关键日期	它解决的问题	它是谁的延伸
Entra Agent ID	Public Preview 于 Ignite 2025 宣布；文档更新 2026-04-14	给每个 agent 一个企业级身份对象，可被清点、审计、吊销	Entra（Azure AD）身份目录
Agent identity blueprint（蓝图）	随 Agent ID 一同公开	作为父模板批量签发子 agent 身份，保证策略一致性	模板化身份供应
Microsoft Agent 365	GA：2026-05-01	agent 控制平面：可见性 + 治理 + 防护	M365 管理平面
”身份即边界”安全架构	Security Blog 2026-03-20 / 2026-05-14；Build 2026 公告 2026-06-02	把身份当现代安全边界，整合 Purview 合规 + Entra 身份 + Defender	零信任架构的 agent 延伸

技术内核有两点值得 PM 记住：

第一，无凭证身份模型（credential-less）。agent 不持有密码或长期密钥，而是通过**联邦身份凭证（Federated Identity Credential, FIC）**做身份验证，FIC 由 agent identity blueprint 签发（来源：Microsoft Learn，What is Microsoft Entra Agent ID，更新 2026-04-14）。这是直接对症下药——本专题反复出现的最高风险源就是「静态、长期有效、可重放的 API Key」（行业共识，多家安全厂商 2025–2026 研究）。微软用”agent 根本不碰长期密钥”绕开了这个雷区。

第二，blueprint 父子模型。一个蓝图批量产出子 agent 身份，对应了 0411 A06 Orchestrator 编排器与 A07 Multi-Agent Teams 描述的”orchestrator spawn 子 agent”场景——微软的回答是：子 agent 不该裸继承父 agent 的凭证（这正是 0435 红队专题里”子 agent 权限继承”与 confused deputy 攻击的温床），而该从蓝图各自签发独立身份。这一步在设计意图上是对的；但它有个边界，见 §4。

§2 “Agent Identity Perimeter”到底是不是一个产品

这里必须做一次事实校准，否则会踩进 hype 陷阱。

“Agent Identity Perimeter”并非微软官方命名的独立产品，而是一个安全架构理念的通俗称呼——即”身份是现代安全边界（identity is the new perimeter）“这一零信任老命题，向 agent 场景的延伸，落地载体是 Entra Agent ID（来源：综合 Microsoft Security Blog 2026-03-20 与 Learn 文档表述，WebFetch 核实）。把它当成一个可以”买来部署”的盒子，是媒体与分析师的二次叙事，不是微软的产品边界。

这个澄清对 PM 是有决策含义的：当你在选型会上听到”我们用了微软的 Agent Identity Perimeter”，正确的追问不是”这个产品多少钱”，而是”你接入了 Entra Agent ID 的哪几个能力面（身份签发 / blueprint / Agent 365 控制平面 / Purview 合规策略），还是只买了个名词”。边界即产品的叙事在身份安全领域格外容易膨胀，因为”边界”本身是隐喻——它把一组分散的控件包装成一道看得见的墙，但墙的强度取决于每块砖是否真的砌上了。

§3 判断主轴：把 agent 当一等身份主体，解决了什么、制造了什么

这是本节点的命门。微软方案的得与失必须分两栏看，每点带”症状 → 为什么 → 正确做法 → 反例”。

得（三项，有据）

得 1 · 可问责性回归。 agent 有独立身份对象后，审计日志能区分”是 agent A 干的”还是”是用户借 agent 干的”——Google Cloud 的同类方案直接做了”双身份日志”（agent 身份 + 用户身份同时记录，来源：Google Cloud Agent Identity 文档，更新 2026-06-05）。这直接回应了本专题”审计要回答 why、谁授权了决策链”的范式转变。反例边界：可问责性只在 agent 身份没有被冒用时成立——见失 2。

得 2 · 生命周期可控。 子 agent 寿命极短，传统”人的账号”管理（季度 review、年度认证）完全跟不上。无凭证 + blueprint 模型让身份随 agent 生灭而自动签发/失效，对齐了行业公认的”ephemeral identity”方向（对比 SPIFFE/SPIRE 的 X.509 证书 24 小时有效期、自动轮转，来源：多家安全厂商研究 2025–2026）。

得 3 · 复用成熟基建。 不发明新协议，扩展 OAuth 2.0、并支持 MCP、A2A（agent-to-agent）协议（来源：Microsoft Learn 文档）。这与 NIST NCCoE 概念文件的方向一致——后者明确提议扩展现有 OAuth 2.0 / SPIFFE / OpenID Connect 适配 agent，而非从头设计（来源：NCCoE 概念文件 Accelerating the Adoption of Software and AI Agent Identity and Authorization，2026-02，公开征求意见截止 2026-04-02）。微软押注”扩展派”而非”重造派”，是务实的工程选择。

失（三项，有据）

失 1 · 厂商锁定（vendor lock-in）。 症状：Entra Agent ID 需要 Microsoft 365 E5 或额外许可（Entra ID P1/P2）。为什么是问题：agent 身份治理一旦绑定 Entra，异构多云（AWS Bedrock、自建 LLM、第三方 SaaS agent）就被迫要么全进微软生态、要么靠 sidecar（Entra Auth SDK）和 Workload Identity Federation 打补丁桥接（来源：Microsoft Learn 文档确认支持 AWS Bedrock、n8n 等第三方接入）。正确做法：在选型时把”身份层是否可移植”作为一级判据——能不能用 SPIFFE 这类中立标准做身份底座，把微软当成众多签发方之一而非唯一权威。反例：一家只跑 Azure + M365 的企业，锁定成本极低，失 1 对它几乎不成立——这条结论在单云、纯微软栈场景下失效。

失 2 · 身份 ≠ 授权，身份解决不了”它该不该做这件事”。 这是最深的一刀。给 agent 一个身份护照，回答的是”它是谁”；但 agent 安全的真正难题是”它现在这个具体动作，在不在用户原始授权范围内”。安全研究者 Karl McGuinness 的立场（经 Resilient Cyber 引述）一针见血：agent 不需要”身份护照”，需要的是”授权授予（authorization grant）“——这是一次范式之争，而非控件之争。为什么微软的身份框架填不满这个洞：身份是静态的（你是 agent A），授权范围却是任务级、动态、随上下文漂移的。一个有合法身份的 agent，照样可能被 prompt injection 劫持去做授权外的事——身份系统对此无能为力，因为攻击没有伪造身份，只是滥用了一个真实身份的过宽权限。这正是 0435 红队专题反复警示的”权限漂移”。正确做法：身份层之上必须叠加任务级最小授权（OAuth scope 的 act claim 记录委托链、衰减令牌 attenuation），把”是谁”和”能做什么”解耦。

失 3 · 多跳委托在标准层无法强制执行。 agent A 委托 agent B、B 再代表用户 X 调工具 C——这条链上的授权能不能被强制收敛？答案是当前标准做不到。RFC 8693（Token Exchange，正式 RFC）明确写道：嵌套的 act claim”仅供参考，不得用于访问控制决策”（来源：IETF Datatracker，WebFetch 2026-06-07 核实）。而专门处理 agent 多跳委托的 IETF 草案 draft-oauth-ai-agents-on-behalf-of-user-02 至今仍是已过期的 Internet-Draft（发布 2025-08-26，过期 2026-02-27），不是正式标准。微软的 blueprint 父子模型在自家生态内能保证策略一致性，但一旦委托链跨出 Entra 边界（A2A 协议跨厂商），就掉进了这个标准空白里。这条得失的天花板不在微软，在整个行业。

§4 产品 PM 视角补盲：合规、商业模式与”看走眼”的三个点

跳出工程视角，补三个产品/商业/合规盲点：

合规驱动的采购，而非技术驱动。 EU AI Act Article 12 要求高风险 AI 系统全生命周期自动记录事件、日志保留至少 6 个月，执行截止 2026-08-02（来源：artificialintelligenceact.eu + FireTail 分析 2026-04）。微软把 Purview 合规策略与 Entra 身份边界、Defender 整合（Build 2026 公告 2026-06-02），卖的其实是”一站式合规叙事”——对 CISO 的吸引力首先是省掉合规举证的麻烦，技术先进性是第二位的。PM 若只比技术参数，会看走眼真正的购买动机。
“逐操作确认”已被证伪，治理必须上移到计划级。 Anthropic 的共享责任模型数据显示，开发者在 93% 的权限提示弹窗里未经有效审查即点击批准（来源：Backslash Security 解读 Anthropic 模型，2026-04-29）。这意味着把安全寄托在”每个动作弹窗让人确认”是幻觉——身份/治理平面的价值恰恰在于让策略在计划级、批量级生效，而非依赖疲劳的人工点击。微软 Agent 365 的”控制平面”定位踩中了这个真需求。
数据可信度边界要诚实。 行业广为流传的”约 2,000 个野外 MCP server 全部缺乏认证”（来源：arXiv AIP 论文 2603.24775，2026-03-25 引用）这个数字震撼，但具体数字需独立核实〔待核实〕；同样，多家鼓吹”Docker 不够、必须上 microVM/WASM”的来源本身在卖替代方案，存在利益冲突。PM 引用这类数据时必须标注来源与立场，否则就是在用别人的营销稿做自己的决策。

§5 对手框架回应：接受 + 边界

对手立场一 · “agent 是 NHI（Non-Human Identity）的子类，现有框架扩展即可”（传统 IAM 厂商立场）。接受：agent 确实大量复用了机器身份的治理逻辑（无密钥、自动轮转、机器:人身份比已达 45:1 到 100:1，来源：CSA 研究），微软的扩展派路线正建立在此之上，务实且能立刻落地。边界：但 agent 比传统 NHI 多了”自主决策 + 自然语言可被劫持”这一维度——一个 service account 不会被 prompt injection，agent 会。把 agent 完全等同于 NHI，会低估其授权范围的动态漂移风险（Strata、Aembit 等持此异议）。

对手立场二 · “agent 不需要身份护照，需要的是授权授予”（Karl McGuinness / 部分安全研究者，本专题主动引入的 Rick 未必熟悉的对手框架）。接受：这一刀切中要害——§3 失 2 已承认，身份解决不了”该不该做”。微软若止步于发身份证，确实是治标。边界：但身份是授权的前置——没有可靠的”它是谁”，“授予它什么”就无处落地。两者不是替代关系而是层叠关系。微软的真实问题不是”做了身份”，而是”身份层的叙事盖过了授权层的薄弱”。

对手立场三 · “NIST/NCCoE 自己都承认现有标准是否够用没有定论”。接受：这是诚实的——NCCoE 概念文件明确把”现有标准是否足够，还是需要全新标准”作为公开提问，未有结论（来源：NCCoE 概念文件 2026-02）。边界：但 PM 的决策无法等标准尘埃落定。在标准未决的窗口期，押注”扩展现有 OAuth/OIDC”的可逆成本，远低于押注某个尚未成形的新协议——微软的赌注在风险/收益比上是合理的，即便它可能在 2–3 年后被证明只是过渡方案。

§6 跨域呼应：韦伯的”科层制” vs agent 的”无主体行动”

调度一个 Rick 已有的社会学资源——韦伯（Max Weber）的科层制（bureaucracy）与合法性支配理论（入口 0117社会学）。

韦伯指出，现代科层制的合法性建立在职位与人身分离：权力属于”岗位”，而非占据岗位的个人，因此可问责、可继承、可审计。这套逻辑正是传统 IAM 的哲学底座——账号是”职位”，自然人是”占据者”。agent 击穿了这个分离：当一个 agent 可以 spawn 出无数寿命几秒的子 agent，每个都在做实质性决策，“岗位”的颗粒度细到无法用人的科层逻辑追责——这是阿伦特意义上”无人统治（rule by nobody）“在技术系统里的复现：人人都在执行，却找不到那个该负责的”谁”。

微软用 blueprint 父子身份模型试图重建科层链：蓝图是”岗位定义”，子 agent 身份是”被任命的占据者”，委托链是”授权层级”。这个类比让我们看清微软方案的雄心与软肋：它在重建一套 agent 版的科层合法性，但科层制的可问责性依赖”层级是稳定且可强制的”——而 §3 失 3 已证明，跨厂商的多跳委托链在标准层根本无法强制执行。**没有可强制的层级，科层制就退化成无主体行动。**这正是 0430 制度专题讨论”agent 作为准法律主体”时绕不开的前提：你不能给一个连授权链都焊不死的实体安上法律责任。

§7 PM 决策启示

面试怎么用：被问”如何给 agent 系统做身份治理”，答案不是背微软产品名，而是亮出框架——“先分离’它是谁（身份层，Entra Agent ID 这类）‘和’它能做什么（任务级授权层，OAuth scope/attenuation）‘；身份解决可问责，授权解决最小权限；二者层叠，缺一不可；当前多跳委托标准空白是行业天花板，不是某家产品的锅。“这套话术能把你和只会念产品 PPT 的候选人区分开。
选型怎么用：评估任何 agent 身份方案，问四件事——(1) 身份是否无凭证（不依赖长期密钥）？(2) 身份层是否可移植（绑死单一厂商还是基于 SPIFFE 等中立标准）？(3) 身份之上有没有任务级最小授权与衰减令牌？(4) 跨厂商委托链如何处理（诚实承认标准空白还是假装解决了）？
复现怎么用：小团队不必上 Entra 全家桶——可先用 SPIFFE/SPIRE 给 agent 发 ephemeral 身份（无密钥、24h 轮转），再在 Function Calling / MCP 工具层叠加任务级 scope 检查。微软方案的价值是给你一张”成熟形态的地图”，而非唯一实现路径。

§8 与已有节点的关系

对 A06 Orchestrator 编排器 / A07 Multi-Agent Teams：本节点是深化——0411 描述了 orchestrator spawn 子 agent 的架构机制，本节点补上”子 agent 的身份从哪来、凭证该不该继承”的安全治理维度，指出裸继承凭证正是 confused deputy 攻击的根因。
对 m208 - AI 基础设施与中间件选型：本节点是补缺——m208 §2.5 的中间件选型缺一条”身份与授权层”的评估维度，本节点 §7 的四问可直接补入其选型矩阵。不复述 m208 的中间件清单。
对 Function Calling：本节点是对话——Function Calling 把”调什么工具”讲清楚了，本节点回答”谁有权调、调用链怎么问责”，是其安全侧的对位补充。
对本专题同级节点（0436 staging，降级为文本引用）：与 S 系列”权限边界与最小权限设计”互补（身份层 vs 授权层），与”审计与问责”节点共享”双身份日志/可问责性回归”的论据，与”NIST AI Agent Standards”节点共享”扩展派 vs 重造派”之争的标准侧背景。

§9 关联节点

核心（必读）

延伸（可选）

跨专题引用（staging，降级文本）：0436 本专题 S 系列「Agent 权限边界与最小权限设计」、「审计与问责」、「NIST AI Agent Standards Initiative 剖解」均在 staging，未入主库，故以文本引用而非双链。0435 红队专题「S03 Agent 权限边界与最小权限设计」同为 staging，相关概念（confused deputy、权限漂移、副作用分级）以文本引用。

修订日志

R0.1（2026-06-07）：首稿。判断主轴”大厂把 agent 当一等身份主体治理的得失”成形，得/失各三项均带四件套与反例边界；引入 Karl McGuinness”授权授予 vs 身份护照”为 Rick 未读对手框架；韦伯科层制 + 阿伦特”无人统治”做跨域呼应，呼应 0430 准法律主体前提；与 A06/A07/m208/Function Calling 建立升级对照；事实接地：Entra Agent ID（Public Preview @ Ignite 2025，文档 2026-04-14）、Agent 365 GA 2026-05-01、NCCoE 概念文件 2026-02、RFC 8693 与 IETF 草案过期状态、EU AI Act Art.12 截止 2026-08-02、Anthropic 93% 数据 2026-04-29 均经核实；“2000 个 MCP server 无认证”标〔待核实〕。