北京
周三下午，一个工程师正在调试他的AI代理。这个代理需要调用三个下游服务：一个数据库、一个云函数和一个内部API。他下意识地把用户的IdP令牌随着请求一路传了下去——反正能通过认证就行，对吧？
这样做当然能跑通。用户登录后拿到一个令牌，代理持有它，再让每个下游服务也能识别“用户是谁”。表面上看，身份传递没有断，审计日志里也能追到同一个sub字段。对于急着上线的团队来说，“能跑就行”的诱惑始终存在。
但安全工程师看到的是另一幅图景。那个令牌本来就是发给浏览器前端的，受众写的是网关，不是后面那些服务。它包含的权限可能是几十个微服务的全部访问范围，有效期还是按小时计的。更要命的是，一旦这个令牌落入代理进程的内存，代理就等于拿到了用户的万能钥匙——它可以冒充用户去任何地方。Christian Posta在AgentGateway的博客里说得直接：“把敏感的MCP/API凭证（密钥、API key、令牌等）暴露给AI代理，就是一张你不该制造的泄漏面。”
于是，一个选择摆在了架构师面前：是继续依赖原生用户令牌的“直接透明”，还是引入一套令牌交换机制，把每一次下游调用都重新包装一次身份？
接受令牌交换，意味着每次代理代表用户访问下游时，网关要先拿用户的IdP令牌向授权服务器换一个新的、专用的令牌。新令牌的受众被限制为那个特定的下游服务，作用域只包含这次调用的最小权限，有效时间可能只有几分钟。用户身份（sub声明）还保留着，但令牌已经不可能被滥用于其他服务。如果代理本身也要被识别，还会带上act声明，标明谁在代表用户行事。整个流程符合RFC 8693的标准化定义，不再需要每个服务各自理解用户原始令牌的庞大声明集。
反对的声音往往落在复杂度和延迟上：多一次令牌交换就多一次网络往返，而且还要配置交换策略、维护令牌映射。但在AgentGateway的实现里，内置的后端认证策略backendAuth.oauthTokenExchange已经封装了这个过程：网关收到用户请求时，自动向Keycloak等身份提供方发起RFC 8693交换，然后把换来的令牌转发给上游，原始的令牌根本不会走出网关。所有交换还配置了缓存，重复调用不会一直捶打IdP。
所以这场辩论的结论其实很清楚：当AI代理开始触碰多个下游服务时，“直接传原始令牌”就已经不是一个架构选项，而是一个迟早要爆炸的隐患。用网关集中进行令牌交换，既保住了用户的身份信息，又把每个服务得到的凭证限制在了最小必要范围内。而这一切，靠AgentGateway里一段声明式的策略配置就能跑通——一个干净的分离，远比事后追查“令牌泄漏面”要划算得多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
