AI代理如何揭示传统IAM架构的根本缺陷

核心问题：人类并不总是在键盘后面

传统的身份与访问管理（IAM）系统建立在一个假设之上——有人实际上在那儿进行验证。一个人坐在登录界面前，输入密码，收到多因素认证（MFA）推送通知，批准它。这一工作流程已经定义了数十年的安全标准。

但人工智能代理彻底打破了这个假设。

当自主代理在非工作时间以高速处理API请求时，它无法暂停以应对MFA挑战。当代表用户处理日历和电子邮件任务的委托代理时，它绝不应继承该用户的全部权限集。认证系统不能要求在没有人工监督的24/7运行的流程中进行人工交互。整个架构——登录界面、密码提示、人类验证的多因素认证——在代理接管工作流程执行的那一刻，变成了架构债务。

真正的问题在于：传统的IAM无法区分合法的代理请求和在有效凭证下被劫持的请求。 当主体无法通过正常授权渠道访问API操作时，系统会捕获到。但当该主体的凭证被劫持，或当代理的意图通过上下文污染变得恶意时，传统系统没有防护措施。这一技术身份验证与实际可信度之间的差距，定义了代理认证的核心挑战。

两种根本不同的代理模型，两个不同的身份需求

人类委托代理：范围和最小权限问题

人类委托代理在授权范围内操作——你授权AI助手管理你的日历。但危险之处在于：目前大多数系统要么授予代理你的全部权限，要么要求你手动定义限制。这两种方式都不可行。

代理不需要继承你的全部身份。它只需要精确限定的权限。你直觉上知道，支付账单的服务不应转账到任意账户。你本能地防止财务指令被误解。AI系统缺乏这种上下文推理能力，这也是最小权限访问不是可选项——而是必须的原因。

技术实现方式：

系统实现双重身份验证。代理同时以两种身份操作：

• 你的身份(授权人)，拥有全部权限
• 代理的受限身份，具有明确的范围边界

当你授权时，会进行令牌交换。代理不会获得你的凭证，而是获得一个范围缩小的令牌，包含：

• agent_id：该特定代理实例的唯一标识符
• delegated_by：你的用户ID
• scope：权限边界(例如，“银行：支付账单”但明确不包括“银行：转账”)
• constraints：策略限制，如批准的收款人名单、交易金额上限和到期时间戳

流程大致如下：