当AI代理开始“办事”，OAuth为何成了安全底座

这是一次来自OAuth老兵的现场反思：当AI代理被连接到越来越多真实系统时，传统“给权限就完事”的做法正在失效。Jared Hanson结合自己在Passport.js、身份基础设施和最新创业Keycard中的经验，解释为什么OAuth依然重要，但必须被重新使用。

为什么“更聪明的代理”，反而让安全变成不可能的选择题

这一段的核心问题只有一个：当AI代理越来越有用，我们是否正在被迫在“价值”和“安全”之间二选一。Jared一开场就点破了这个困境——连接越多系统，代理越强大，但风险也指数级上升。他直言：“今天我们面临一个几乎不可能的选择：要么给代理广泛访问权限并接受安全风险，要么限制它们的能力，牺牲业务价值。”

他用当下流行的MCP（Model Context Protocol）服务器配置举例，说明很多团队为了让代理“跑得起来”，默认给了过大的访问范围。这在演示阶段或许没问题，但一旦进入真实生产环境，代理可以读邮件、改日历、访问内部API，攻击面立刻被拉到最大。

这个判断并非理论推演，而是来自他多年做身份系统的直觉：任何无法精确表达“谁在什么时间、为了什么目的访问什么资源”的系统，最终都会被滥用。AI代理只是把这个老问题，以更快的速度、更大的规模重新摆在我们面前。

OAuth并不陌生，但大多数人用错了它

当Jared问现场“有多少人熟悉OAuth？”时，几乎所有人都举了手。但他紧接着抛出的观点却让人警醒：我们熟悉的OAuth，主要是为“人”设计的，而不是为“代理”。

他花了相当篇幅澄清OAuth里最容易被混淆的一点——授权（authorization）和认证（authentication）。OAuth解决的是“你能做什么”，而不是“你是谁”。在人类应用中，这通常通过浏览器跳转、同意页面来完成；但AI代理没有浏览器，也不会点“Allow”。

问题因此变得棘手：如果我们只是把用户的长期访问令牌直接交给代理，那么代理获得的权限，实际上等同于这个用户本人。这正是他反复强调的风险来源。正如他在台上说的那样，这会让代理“轻易越过我们原本设计的安全边界”，比如访问Google Calendar这类高度敏感的个人数据。

从MCP v1说起：一次看似方便、实则危险的设计

在谈到MCP的第一个版本时，Jared的语气明显变得谨慎。他认为早期设计的一个核心问题，是把过多责任推给了OAuth服务器本身，而不是清晰地区分代理、用户和资源之间的关系。

在这种模式下，代理往往被当作“缩小版的人类应用”，使用同样的授权方式。这在技术上可行，但在安全模型上并不成立。因为代理是异步的、可复制的，而且可能在你不知情的情况下被触发。

他并没有否定MCP的方向，而是指出这是一个“必经阶段”。正如他所说：“我们现在回到了一个相对不错的位置，但这个方案长期来看并不太可行。”这句话背后，是他对身份系统演进路径的判断——先跑通，再补安全，最终一定要重构。

真正可行的方向：代理身份、密钥与异步交互

那么替代方案是什么？Jared给出的答案是：把代理当成一等公民，而不是用户的影子。这意味着代理需要自己的身份、自己的密钥，以及可验证的授权边界。

他特别强调了基于公钥的机制：代理使用私钥发起请求，资源服务器通过对应的公钥验证身份。这种方式不依赖用户在线，也更适合代理的异步特性。更重要的是，它让权限可以被精确地绑定到“这个代理、这个任务、这个时间窗口”。

在最后一部分，他将这一切与更大的“代理图谱”联系起来：未来的代理不是单点存在，而是在系统之间流动、协作。如果没有一个清晰的身份和授权模型，这些连接只会放大风险。这也是他认为“非常值得我们所有人认真思考”的地方。

总结

这场演讲的价值，不在于教你如何实现OAuth的某个细节，而在于重新校准一个行业共识：AI代理不是普通应用，更不是用户本人。Jared Hanson用他十多年的身份系统经验提醒我们，安全不是给代理“踩刹车”，而是给它们一套可控、可审计的行动规则。谁能最早把这件事做对，谁就能真正释放代理的长期价值。

关键词： AI Agent， OAuth， 身份与访问管理， AI安全， MCP

事实核查备注： Jared Hanson：Passport.js创建者，Keycard联合创始人；OAuth：授权框架而非认证协议；MCP：Model Context Protocol；提及Google Calendar作为高敏感资源示例；观点来自视频《How to Secure Agents using OAuth》