Agent 越能调用工具，身份和授权就越重要。过去很多团队把安全边界写在提示词里，希望模型自己判断哪些动作可以做。现在看，这种方式不够。提示词可以提醒模型，但真正的权限判断，最好放到模型外部的身份层和授权层。
近期身份社区也在把这个问题往前推。OpenID Foundation 在 2026 年 7 月 14 日发布的 AuthZEN at Identiverse 2026 提到，面向 AI agents 的授权已经成为年度重要议题。OpenID 在 2026 年 6 月 15 日还发布过 AuthZEN 工作组草案进展。与此同时，MCP 授权规范 也把 HTTP 传输下的授权能力放在协议层讨论。
事实梳理
AuthZEN 关注的是授权决策如何在不同组件之间标准化通信。简单说，应用或 API 网关提出“这个主体能不能执行这个动作”，外部策略决策点给出判断。这个思路放到 Agent 场景里，就是不要让模型自己拥有全部判断权。
MCP 授权规范则更贴近 Agent 接工具的入口。它说明 MCP 客户端如何代表资源所有者向受限 MCP 服务器发起请求，并基于 OAuth 2.1 等机制处理授权。对企业来说，这意味着工具调用不能只靠 API key 粗放接入。
影响分析
Agent 身份层会影响三个地方。第一是工具调用：同一个 Agent 在不同用户、不同任务、不同审批状态下，能调用的工具不应该一样。第二是审计：日志里要能看出是谁授权、代表谁执行、执行了什么参数。第三是最小权限：临时任务完成后，授权应该失效。
这和本站之前写过的 权限矩阵、审计日志字段、工具白名单 能串成一条线。身份层负责说明“谁在行动”，授权层负责判断“能不能做”，审计层负责留下“做过什么”。
老达点评
我觉得 Agent 身份层会从安全话题变成产品基础设施。因为只要 Agent 进入生产，它就不再只是一个聊天窗口，而是一个会代表用户访问系统、读取数据、提交动作的执行者。没有身份和授权，后面所有治理都会变得很虚。
普通团队现在不一定要马上引入完整授权平台，但至少要避免一个错误：给 Agent 一个长期有效、权限很大的通用账号。更稳的做法是按场景拆账号、按动作拆权限、按任务设有效期，并把每次客户可见动作留到人工确认。
总结
OAuth、AuthZEN 和 MCP 授权规范指向同一个趋势：Agent 权限不能只靠提示词约束，而要放到身份、授权和审计体系里管理。Agent 越接近生产，越需要细粒度授权和可复盘的工具调用记录。
