AI 身份验证与授权：为什么传统安全模式恰好是 AI 时代需要的

2026/7/6 5:17:02

AI 身份验证与授权：为什么传统安全模式恰好是 AI 时代需要的

引言

当所有人都在 rush to ship AI agents 时，一个关键的真相被遗忘了：2010 年代保护 API 繁荣的身份验证和授权模式，恰恰是你今天保护 AI 系统所需要的东西。

如果你已经构建过 OAuth 集成、管理过 API 密钥、或设置过基于角色的访问控制（RBAC），那么你已经拥有了大部分所需的知识。AI 安全不是一门新学科——它是现有最佳实践的延伸。

"让 AI 在没有确定性防护措施的情况下访问资源，是一种愚蠢行为。"

AI 系统是概率性的——它们推理、幻觉、即兴发挥。但控制它们为谁行事以及它们被允许做什么的身份层必须是确定性的。身份认证不是可以"随缘"的事情。

三种 AI 用例的安全分析

文章以一个贯穿始终的场景展开：你是一家银行的工程经理，希望通过 AI 改善员工和客户的支持台运营。围绕这个场景，文章分析了三种 AI 用例：

1. RAG（检索增强生成）：确保模型永远看不到不该看的内容

RAG 通过在查询时向 AI 模型提供文档来增强其可用数据。核心安全关注点是：并非每个用户都应该看到每份文档。

为什么身份对于 RAG 至关重要：

当回答查询时，LLM 甚至不应该看到用户无权访问的文档。这不是 prompt 工程的问题——你不需要精心设计提示词让模型保守秘密。借助正确的授权框架，你可以在文档到达模型之前进行过滤。

LLM 模型只接收通过授权检查的文档。这首先是一个授权问题——验证用户身份，处理查询，从向量数据库中提取文档，然后根据用户权限过滤文档。

实施步骤：

将文档分块成适合向量搜索的片段
构建授权模式，将用户和角色映射到文档访问权限
在检索时存储元数据，包括哪些角色、部门或用户可以访问每个块
进行身份验证，获取用户的身份声明，根据用户和文档属性进行过滤
将结果传递给 LLM

这里的关键是，授权逻辑应该是集中且确定的，而不管使用的是什么 RAG 框架。

这是一个流程图，展示了请求流程（以及如果文档已存储适当的元数据）：

flowchart LR subgraph User["用户"] A[身份验证] end subgraph RAG_Pipeline B[查询向量数据库] C(使用 FGA 进行过滤 + 文档属性) D(返回已授权的块) end

关于元数据的注意事项：

文档并不总是干净地映射到某个访问级别。例如，一份合规 PDF 可能包含所有员工都能访问的部分，以及仅限于法律团队的部分。确保你的分块流水线可以处理这个问题。

如果你想要 LLM 不看到用户不应访问的文档，请确保用户和访问权限数据在检索之前就可用于过滤。

2. 工具使用：MCP 与 API

工具使用让 AI 系统能够执行读取数据库、更新客户信息、调用外部服务等操作。

MCP（模型上下文协议）是 Anthropic 推出的一种新兴标准，它使任何 API 或服务都可以以结构化方式供 AI 工具使用。Block、Bloomberg 和 Amazon 等公司已经在内部使用 MCP。

MCP 的安全实现：

在现有 API 和服务之上构建 MCP 服务器
配置 MCP 服务器指向支持 OAuth 2.1 的身份提供商
MCP 客户端应预先注册或动态创建
当 MCP 客户端尝试访问 MCP 服务器时，服务器会重定向到身份提供商，后者对用户进行身份验证并颁发令牌

MCP 的最新版本使用 OAuth 2.1 和授权码授予进行 AI 系统或工具的认证。同时也有使用客户端凭证授予的扩展正在开发中。

API 的安全实现：

API 复用了传统的身份验证方法：API 密钥或访问令牌。自 REST API 时代以来，你一直在使用的相同网关模式可以帮助限制速率或监控对 MCP 或 API 服务器的访问。

3. 智能体系统：自主与安全

智能体是非确定性的软件组件，可以通过提示完成具有不同自主程度任务。它们可以扩展到数十或数百个实例，与人类、API 和 MCP 工具交互，并将推理步骤串联起来。

核心安全概念：身份链（Chain of Identity）

当一个人类启动一个智能体工作流时，该人类的身份需要跟随智能体完成每一个步骤。如果智能体读取文件，你需要知道是哪个人类授权了那次读操作。如果智能体安排了会议，你需要知道是代表谁安排的。如果出了问题，你需要一条可追溯到发起者的审计线索。

这就是身份链。

使用 JWT 实现身份链：

FusionAuth 的Vend JWT API允许你创建嵌入原始用户并在智能体交接工作时传播该身份的令牌。它使用act声明（遵循 OAuth 令牌交换规范 RFC 8693）来表示委托链中的执行者：

const response = await client.vendJWT({ keyId: 'your-signing-key-id', timeToLiveInSeconds: 300, claims: { sub: 'coordinator-agent-entity-id', act: { sub: 'original-human-user-id' }, permissions: ['read:documents', 'check:credit', 'schedule:meetings'] } }); // response.response.token 包含签名的 JWT

智能体的设计模式：子智能体架构

一个设计良好的智能体系统将工作拆分给多个子智能体，每个子智能体具有有限的作用域。以开设企业银行账户为例，我们可以有四个智能体：

协调智能体— 编排整个工作流
文档智能体— 收集企业文件
信用检查智能体— 调用信用检查 API
日历智能体— 安排入职会议

这种拆分的好处：

安全爆炸半径缩小：如果日历智能体被攻破，它无法访问文档或信用数据
上下文窗口管理：每个智能体只需要与其任务相关的上下文
显式信任边界：信任在智能体之间的边界处授予，而不是一个可以访问一切的智能体
防止交叉污染：来自一个服务的数据不会泄漏到另一个智能体的上下文中

实体权限配置示例：

// 为智能体创建实体类型 const entityTypeResponse = await client.createEntityType({ entityType: { name: 'Banking Agent', description: 'AI agents for banking workflows' } }); // 创建权限 await client.createEntityTypePermission({ entityTypeId: entityTypeId, permission: { name: 'invoke', description: 'Permission to invoke this agent' } }); // 创建智能体实体 const coordinator = await client.createEntity({ entity: { name: 'business-account-setup', entityTypeId: entityTypeId } });

审计日志：

所有智能体操作都应记录到审计日志中，捕获智能体身份、人类发起者身份、操作类型和时间戳。这提供了完整的可追溯性。

清理策略：

工作流成功完成后，清理智能体实体凭据
对于错误状态，实现一个"收割者"进程来处理失败工作流产生的孤立实体

结论：三个不变的真理

文章最后总结了三个核心信念：

人类身份是 AI 权威的根源— 有人编写了那个任务，有人授权了那个智能体，这应该始终被追踪
AI 安全最好是作为现有最佳实践的延伸— OAuth、令牌、网关：保护 API 时代的技术同样适用于 AI 时代，不要重新发明轮子
身份执行必须是确定性的— AI 系统是概率性的，但管理它们的身份层不能是。当你检查智能体是否有权限读取文档或安排会议时，答案必须是"是"或"否"，而不是有时"是"有时"否"