北京
把整套公司的 API Key 直接交给一个能自主决策的 AI 助手，这和把保险柜密码写在门垫下有什么区别？过去半年，让 AI 直连内部系统干活早已不是新闻，但一个尖锐的问题被甩到台前：它到底该“以谁的身份”调用接口？一旦拥有的权限和人一样宽，一个精心设计的 prompt 注入或一次幻觉输出，后果可能比人类的手滑严重得多。
这就是 ID-JAG（Identity Assertion JWT Authorization Grant）想堵上的口子。它现在还是一份 IETF 互联网草案，尚未晋升为正式 RFC，但 LY Corporation（基于 Athenz 授权体系）、Okta 等厂商已经落地开跑，甚至 MCP 规范也直接引用了这份草案。
传统的服务间授权常常在两个极端之间摇摆：要么整个服务共享一把万能主钥匙（API Key 或 Service Account），要么直接把用户的 session 或长寿命令牌借给程序。前者的权限大到失控，后者则缺了一条能追溯的审计链——令牌一旦泄露，攻击者几乎可以完美冒充用户，还很难被察觉。当 AI 开始自行决定该叫哪个工具、该连哪个内部 API 时，这两种风险都被急剧放大。手里攥着万能钥匙的程序一旦被操控，全公司的数据就任它摆弄；而在多层架构里，协调主程序再去调用子程序，风险更是沿着链条一路下传。
ID-JAG 追求的，是为每一次操作都粘上一张“身份便签”：必须能证明“某个用户在某个时刻授权我替 ta 做某件具体的事”，并且这个授权范围要尽可能窄、有效期要尽可能短。它建立在 OAuth2 令牌交换（RFC 8693）的基础上，额外叠加了一层证明——“这个令牌是从真实人类的身份断言衍生出来的”。
这也是 OAuth.net 把它收进跨应用访问（XAA）页面的原因：这正是智能体时代冒出的新命题。
从技术实现上看，ID-JAG 的令牌交换流程更像是一次“权限缩放”。用户先以常规方式登录并产出一枚身份断言，AI 助手随后携带这枚断言去换取一个只针对当前任务的、权限极度收敛的访问令牌。
随后所有针对受保护资源的调用都只能用这枚短寿令牌，原始的用户凭证始终不会直接暴露给调用者。
作者为理清这套机制，用 Go 把 ID-JAG 的 MCP Server 从官方教学仓库 athenz-community/id-jag-the-hard-way 重写了一遍，项目名为 kkdai/id-jag-mcp，可供直接运行和测试。通过这个项目，我们能清晰地看到：它每做出一个决定，背后都必须有一条可核验的、人对机器的授权链路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
