AI Agent 身份认证：企业级 IAM 最佳实践移植

上周，我在排查一个问题：我们的 AI Agent 总是在任务执行到一半时丢失 session。那一刻我突然意识到，我们现在解决的，本质上就是企业 IT 团队早在 15 年前通过 SSO 和 IAM 解决过的问题。唯一的区别在于，这一次登录的“用户”不再是人类，而是一段能够自主决策的软件。

目前，大多数构建 AI Agent 的团队都把身份认证当成了事后才考虑的问题：把 API key 硬编码在某个地方，十个 Agent 共用一个 service account，没人知道究竟是哪个 Agent 执行了什么操作。这样的情况我已经见过不止一次。说实话，这就是一场尚未爆发的灾难。

所以，我们来聊聊企业身份管理领域已经总结出了哪些经验，以及我们可以如何借鉴。

1. 每个身份，无论是不是人类，都需要拥有独立凭证

在企业环境中，我们不会允许两名员工共用一个登录账号。否则，审计记录基本就失去了意义，责任归属也无从谈起。同样的逻辑也适用于 Agent。如果 Agent A 和 Agent B 共用一个 API key，一旦出现问题，你要如何追溯究竟是哪个 Agent 造成了损害？每个 Agent 都应该拥有独立的 machine identity，没有商量的余地。

2. 使用短期 token，而不是静态 key

这并不是什么新鲜观点。OAuth2 和 SAML 很早以前就教会了我们这一点。一个静态 API key 在环境文件里一放就是几个月，无异于一颗定时炸弹。Agent 应该主动申请短期 token，并按需刷新；一旦 Agent 的任务完成，对应的 token 就应该过期。Okta、Azure AD 等企业 IAM 工具已经可以自动为人类用户完成这些工作，我们也需要一套面向 Agent 的等价机制。

3. 最小权限原则不容妥协

我知道，为了“以防以后用得上”，给 Agent 开放更广泛的权限很有诱惑力。但这恰恰是企业在早期曾经犯过的错误，直到 RBAC 成为标准实践后，情况才有所改善。一个只需要读取日历的 Agent，不应该拥有对整个电子邮件账户的写入权限。始终把权限范围限制到最低。

4. 委托授权必须明确

真正有意思的地方就在这里。当 Agent“代表”用户执行操作时，企业身份管理其实早已有成熟的模式可供参考，例如 OAuth 的委托模型，甚至更早的 Kerberos constrained delegation。Agent 不仅要携带自身的身份信息，还应该携带能够证明它代表谁执行操作的凭据。否则，你甚至无法回答一个最基本的问题：这项操作究竟得到了用户授权，还是 Agent 擅自失控执行的？

5. 持续验证，而不是一次登录后永久信任

企业已经从“一次登录，永久信任”转向了 Zero Trust：每次请求都要根据上下文重新验证。Agent 的行为甚至比人类更加难以预测，因此这项原则对 Agent 而言更应该加倍重视。不要只在 session 开始时认证一次 Agent，随后就置之不理；必须持续进行检查。

说实话，这些观点并没有多少新意。身份与访问管理领域的从业者早已打过这场仗，犯过这些错误，也为此制定了相关标准。我们现在所做的，不过是把同样的原则应用到系统中的一种新型行为主体上。

我注意到，许多 AI 基础设施团队正在从零开始重新发明身份认证，而他们原本完全可以直接调整和复用 IAM 领域已有的方案，只需针对 Agent 的特点做一些修改：与点击按钮的人类相比，Agent 的行动速度更快、自主性更强，有时也更加难以预测。在“AI Agent 版凭证泄露”成为下一个重大新闻头条之前，这个问题值得认真思考。

若要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。