身份服务商 Curity 的 CTO Jacob Ideskog 这周发了一篇文章，论点是：大多数企业在跑的 IAM 栈是围绕一个模型设计的——人登录、拿到会话 token、在那次会话里采取动作——而当前这一代 AI 智能体正在打破这个模型。他引用的标题数字是：在现代企业系统中，非人类身份现在占了所有认证的 90% 以上。不论你信不信 Curity 的具体数字，方向性判断和过去一年所有云安全团队都在说的事情一致：服务账号、CI/CD 流水线、自动化 runner、现在加上 LLM 驱动的智能体，承担了认证流量的大头，而围绕它们的控制是从"以人为中心"的设计假设里继承下来的，跟现在的工作负载已经对不上了。

Ideskog 列举的具体架构失败模式是真实的。当前的 IAM 假设一次会话开始时有一个单一认证门。智能体不是这样工作的；它们跨服务做多步 API 调用链，往往跨越几分钟到几小时，步骤之间没有人在回路里。它们继承启动者的权限——意思是一个被攻破的智能体 token 给攻击者的是启动该智能体的用户的"宽广权限集"，而不是这个智能体本来要做的某个具体动作的"狭窄权限集"。对一个已登录员工原本工作得很好的常驻访问 token，当智能体自己决定调哪个 API 时就成了风险。而双重身份问题——智能体有自己的身份，同时它还代表某个用户行动——在大多数现有 IAM 栈里没有干净的原语。

被推荐的模式是真有道理的，而且并不是 Curity 独有的。以应用为中心而非以用户为中心的授权。即时按需、最小权限、按动作和时间窗口范围发的凭证，而不是常驻 token。每次 API 调用都做的运行时持续授权，不是会话开始的一次门控。带上下文的 token：行动者身份、被代表的用户、目标动作、当前信任级别。所有这些的技术原语在今天的 OAuth 2.0 里就有——token exchange（RFC 8693）做双重身份、dynamic client registration（RFC 7591）做短期智能体凭证、rich authorization requests（RAR，RFC 9396）做按动作范围的 token。缺口不在标准上。缺口在大多数企业 IAM 部署要么没实现这些 endpoint，要么把它们实现成没人开的开关。

对做智能体平台的开发者来说，实际解读是：访问控制工作是真正的工程，不是合规细节。你平台上跑的智能体大概需要自己的身份（不是从用户那借来的）、按任务发出的短生命周期范围化凭证（不是会话长度的）、以及一层运行时授权能在 token 已发出之后还能拒绝某个动作（因为信任信号会在会话中途变化）。Curity 卖的产品做这些；Okta 的 Workload Identity、AWS 的 IAM Identity Center 加 Verified Permissions、以及一批更小的玩家像 Aembit、Astrix 也都在做。Ideskog 那篇里的厂商推销在架构层面并没说错，但开发者应该直接评估 OAuth 2.0 原语、自己选部署路径，而不是把"智能体 IAM"当作单一货源类别处理。90% 非人类这个数字才是应该让每个安全团队回头审视自己跑的是什么的部分，不管最后买的是哪家。