AI 没有制造身份难题，只是取消了速度限制

在基础设施、安全、开发团队和产品开发领域从事技术工作30年后，有一件事始终不变。

永远不要相信一项新技术意味着你可以抛弃旧规则。

基本原则依然成立，因为新技术建立在它们之上，改变了它们的适用范围，而且往往在你出错时提高了后果的严重性。

AI也不例外。

AI是概率性的，而智能体可以推理、做出决策、与其他系统交互，并且越来越多地在没有人类逐步批准的情况下采取行动。但所有这些之下的安全问题都是熟悉的。

这是谁？

他们代表谁或什么在行动？

他们在与谁对话？

他们被允许做什么？

他们能信任什么？

他们实际做了什么？

AI并没有创造大多数这些问题。它取消了速度限制。

人类以人类的速度运作。智能体则不然#

在身份认证历史的大部分时间里，我们围绕人来设计系统。

一个人出现，证明自己是谁，获得访问权限，然后做某件事。他们点击、输入、停下来思考、去吃午饭，最终去睡觉。

这些限制很重要，因为它们为一个人行使访问权限的速度设定了天然上限，而AI智能体可以持续运行、调用API、访问服务、与其他智能体和授权服务器交互，并以比其所使用权限归属者快数千倍的速度行使委托权限。

一个稍微过宽的权限可能在某人的工作日内被行使几次，但一个自主系统可以以机器速度一次又一次地击中同样的弱点。

在我们的2026年AI与身份状况报告中，88%的技术领导者告诉我们，AI部署正在超过他们的身份和安全基础设施。

总有一个竞争对手行动更快，一个客户询问某件事何时发布，或者一位高管问你为什么不做其他人似乎都在做的事，所以公司会继续交付AI。

仅靠政策无法保护那些智能体可以触及的系统。控制措施必须存在于架构中。

概率性智能需要确定性边界#

AI是概率性的。授权不能是。

一个模型可以对你意图的含义有87%的把握，但你的身份基础设施不能对某个智能体被允许访问你的客户数据库有87%的把握。

智能体可以决定它想采取的下一步行动，而身份决定它是否有权采取该行动。

该权限源自一个人或组织，所以如果我授予某个智能体代表我行动的权限，它的自主性不应扩大我委托给它的权限。

随着智能体能力越来越强，身份需要提供确定性。

谁或什么在请求访问？

他们在行使谁的权限？

他们被允许访问什么？

在什么条件下？

授权来自哪里？

我能看到这些何时发生变化吗？

FusionAuth 1.69加强了这些问题背后的若干控制措施。

在FusionAuth 1.69中加强身份控制平面#

FusionAuth 1.69增加了颁发者标识、对受信任加密密钥的更严格控制、对非人类身份的更好可见性，以及在浏览器应用中更轻松地使用发送方约束访问令牌。

这些控制措施已经保护了应用程序和 API，但 AI 增加了它们被使用的频率，也加快了薄弱假设演变为安全问题的速度。

我知道我在和谁说话吗？#

现代身份架构可能涉及多个授权服务器，而智能体架构将在应用程序、API、智能体以及为其授权的系统之间增加更多连接。

当客户端收到授权响应时，它需要确认该响应来自它打算使用的授权服务器，否则它可能在一个服务器上启动授权流程，却接受来自另一个服务器的响应。这就是授权服务器混淆攻击。

FusionAuth 1.69 增加了对 RFC 9207，OAuth 2.0 授权服务器颁发者标识的支持。我们默认启用了它，使我们成为唯一这样做的商业支持的 CIAM 提供商。

借助 RFC 9207，授权响应包含颁发它的服务器的身份。虽然 FusionAuth 默认在授权响应中包含颁发者标识，但客户端仍需要根据它打算使用的授权服务器来验证该标识符。

然后客户端可以验证授权响应来自哪里，而不是假设。

我信任的东西是否超出了需要？#

JWT 验证确认令牌是由受信任的密钥签名的，这使得受信任密钥池的大小变得重要。

如果某个应用程序只需要信任两个验证密钥，却会接受二十个中的任何一个，你就创建了十八个不需要的信任关系。

FusionAuth 1.69 增加了签名验证密钥选择，因此应用程序可以明确控制它在验证 JWT 签名时接受哪些密钥。

验证你正在处理的是哪个授权服务器，然后限制应用程序将从中接受的签名密钥。

由于验证现在严格限定于配置的密钥，使用外部 JWT 或 SAML 身份提供商或活跃密钥轮换的部署应在升级前查看 1.69 迁移指南。

我能看到我的非人类身份发生变化吗？#

FusionAuth 1.69 增加了 AI Agent 实体类型，因此你可以明确区分 AI 智能体与其他非人类实体，并且它增加了用于创建、更新和删除事件的实体生命周期 webhook。

你的安全和审计系统现在可以跟踪 AI 智能体何时出现、其配置何时更改以及何时被移除，同时这些事件可以从 FusionAuth 流入负责监控、审计和自动化的系统。

如果有人窃取了令牌会怎样？#

标准持有者访问令牌就像现金一样运作：谁持有令牌，谁就能使用它。如果持有者令牌从浏览器中被窃取，任何攻击者都可以重放它。

DPoP，即 Demonstrating Proof of Possession，将持有者令牌转变为发送方约束令牌。访问令牌以加密方式绑定到请求它们的客户端，并且客户端在每次请求时证明其拥有私钥。因此，仅窃取访问令牌不足以从另一个客户端重放它。

FusionAuth 自 1.63 版本起已在服务器端支持 DPoP，而 React、Angular 和 Vue SDK 支持已于 2026 年 8 月 5 日发布，使 DPoP 成为原生功能，并且易于从浏览器应用程序中使用，无需编写自定义 JOSE 加密。

当访问受保护资源时，你的 API 仍然需要验证 DPoP 证明。

有些安全工作很枯燥。但它依然重要#

1.69 中还有更多内容。

我们增加了 SAML 配置的灵活性，更新了密码哈希导入支持，改进了群组审计，更新了运行时支持和依赖项，并修复了整个平台上的安全问题。

安全产品需要做这项工作，因为依赖项需要打补丁，运行时支持需要更新，密码学实践会变化，审计要求也在增长。

当身份控制着对你的用户、应用程序、API、机器、服务、数据和 AI 智能体的访问时，保持依赖项和运行时最新就是工作的一部分。

AI 提高了对基础的要求#

AI 智能体将变得更有能力、更加自主，我们委托给它们的权限也会随之增长。

这给那些在访问以人类速度发生时设计的身份基础设施带来了巨大压力，因此 FusionAuth 1.69 在今天强化了该基础设施，同时我们继续为接下来出现的智能体授权问题而构建。

AI 是概率性的。控制它能做什么的身份不能是概率性的。