AI agent 有 OAuth token，但它有身份吗？

OAuth 能证明请求可以到达某个资源，但它本身不告诉运营者持有 token 的角色的完整故事。一旦软件能规划、调用工具、重试、跨系统行动，问题就不再只是"这个请求被认证了吗"，还要问：

• 哪个 agent 在行动？
• 在谁的授权下？
• 为了什么目的？
• 针对哪个目标？
• 行动后留下什么证据？

如果系统不读 agent 的 prompt 就回答不了这些问题，它还没有运营身份模型——它只有一个凭据。

Token 是权限，不是全部身份

OAuth 仍是 agent 的关键基础设施。当前 MCP 授权规范构建在 OAuth 2.1、Protected Resource Metadata、Client ID Metadata Documents、audience 绑定和最小权限 scope 之上，还强化了 issuer 校验、定义了 step-up 授权、禁止 token 透传。这些控制回答了：token 是否给这个资源、用户批准了哪些权限、凭据过期没、资源服务器是否接受它的 audience。

但 token 仍是更大系统里的一个构件：它能携带身份声明，却不会自动给身份以生命周期、所有者、目的或可用的审计轨迹。运营身份是 token 周围的连续性——它说明凭据签发前后是同一个 agent，且它的权限可被理解、可被撤销。

借用人类身份会毁掉记录

让 agent 动起来最快的方式往往是借人类凭据：把 API key 拷进环境、复用浏览器会话、给一个为员工创建的 access token。于是日志说人行动了，其实是 agent。凭据可能带着那个人的全部权限，而任务只需要两个；撤销 agent 等于撤销那个人；后来的审查者分不清一个动作是批准、推断、重试还是从长会话继承来的。这是身份版的共享密码——OWASP 2026 Agentic Top 10 把身份与权限滥用列为独立的 agentic 风险。

实践建议

• 保持授权记录小而可解析：稳定 agent_id、可见的授权链、有界的目的与目标、短命凭据、可撤销、行动后证据；
• 记录模型示例：{agent_id: "qa-runner", authority: {type: "workspace", id: "acme-staging"}, purpose: "verify owned checkout flow", targets: [...], scopes: [...], expires_at: ...}——目标是让 token 能解析回一条小到可检查、具体到可执行的记录；
• 别借人类身份：agent 身份归 agent，权限留在组织侧，每个边界显式、有界、可撤销、能返回证据。

来源：Your AI Agent Has an OAuth Token. Does It Have an Identity? - DEV Community