AI身份验证与授权

AI身份验证与授权

作者：Dan Moore

人类身份是AI权威的来源。我知道你在想什么：又一篇关于AI安全的文章？请听我说完。这篇文章的不同之处在于它基于一个简单而几乎显而易见的真理，而行业在急于发布代理时却一直在忘记这一点：保护2010年代API繁荣所用的相同身份验证和授权模式，正是今天保护AI系统所需要的。

如果你曾构建OAuth集成、管理API密钥或设置基于角色的访问控制，你已经拥有了所需的大部分知识。AI身份验证并非一门新学科，而是现有最佳实践的延伸。

“任何考虑用算术方法产生随机数字的人，当然都是处于罪恶状态。”——约翰·冯·诺依曼

“任何让AI在缺乏确定性安全保障的情况下访问资源的人，当然都是处于愚蠢状态。”——作者

冯·诺依曼的引言是对假设你能从可靠事物中得到非确定性输出的经典警告。其逆原理同样适用这里：AI系统是概率性的——它们推理、产生幻觉和即兴发挥——但治理它们为谁行动以及允许做什么的身份层必须是确定性的。身份不是可以“随性”的东西。

本文通过三个AI用例：检索增强生成（RAG）、工具使用（MCP和API）以及代理系统，并以银行为背景，从身份验证、授权和身份管理的角度进行审视。我们以FusionAuth为例，但也会提到基于标准的解决方案。

用例速览

在深入之前，我们先定义工作内容。

检索增强生成（RAG）通过在查询时向AI模型提供文档来增强其可用数据。银行员工或客户提出问题，RAG系统检索相关内部文档，然后提供给LLM以锚定其回答。关键身份验证问题：并非每个用户都应看到每个文档。客户看到的文档与出纳员不同，而与副总裁看到的也不同。

工具使用（MCP和API）允许AI系统执行操作，例如读取数据库、更新客户记录或调用外部服务。模型上下文协议（MCP）是连接AI工具与服务的新兴标准，但带有丰富文档的普通API也同样有效。关键身份验证问题：控制每个工具能做什么，以及代表谁。

代理系统是半自主的、面向任务的工作流，可以读取数据、跨多个系统采取行动，并在需要时请求人工输入。它们是非确定性的软件组件，将推理步骤链接在一起。关键身份验证问题：维护从授权工作流的人到每个操作的身份链，以及限制代理的访问权限。

以下是它们与身份提供商功能的映射：

场景 | 授权 | 身份验证 | 身份管理 RAG | 是 | 是（框架特定） | 是（框架特定） 工具使用 | 是 | 是 | 是 AI代理 | 是 | 是 | 是

现在让我们深入每个用例。

RAG：确保模型从不见其不应见之物

场景：你拥有与客户支持任务相关的银行文档，如贷款协议、客户协议、合规政策、财富管理手册和欺诈调查程序。你希望通过AI界面供客户和员工查询。但并非所有文档都应对所有用户可用。客服、欺诈与安全、争议与退款、贷款服务团队各自需要访问不同的文档集。别忘了还有客户自己。

像LinkedIn、DoorDash和Vimeo这样的公司已经在生产中使用RAG。这个模式已经很成熟。

为什么身份对RAG重要：

当回答查询时，LLM甚至不应看到用户无权访问的文档。你不需要精心设计巧妙的提示，也不依赖于模型保守秘密。使用正确的授权框架，你在文档到达模型之前就过滤掉了它们。这主要是一个授权问题。你对用户进行身份验证（证明他们就是他们声称的人），处理他们的查询，从向量存储中拉取文档，然后根据用户有权查询的文档进行过滤。模型只接收通过授权检查的文档。

实现： 实现遵循一个直接了当的管道：

1. 将文档分块成适合向量搜索的片段。
2. 构建一个将用户和角色映射到文档访问权限的授权模式。
3. 在向量数据库中与文档块一起存储元数据，包括哪些角色、部门或用户可以访问每个块。
4. 检索时，对用户进行身份验证并获取其身份声明。
5. 在将结果传递给LLM之前，根据用户在步骤3中存储的属性进行过滤。

身份验证方面，一些框架使用JWT，另一些使用API密钥。过滤机制也取决于你的RAG框架。例如，LangChain允许你构建一个检索器包装器，在返回结果之前调用授权服务。

对于授权检查，使用细粒度授权（FGA）系统。FusionAuth FGA by Permify是一个选项。它提供确定性授权，可以在现场部署以保障数据安全，并随需求扩展。

你的授权逻辑应该集中化，并成为唯一可靠来源，无论你使用哪个RAG框架。你希望一个过滤器能利用这一点，并且是确定性的，而非概率性的。

以下是请求流的简化图，前提是在加载过程中文档上存储了适当的元数据。

（流程图略）

但捕获元数据呢？文档并不总是清晰地映射到某个访问级别，有些文档的不同块可能有不同的访问权限。分块可能会丢失元数据。例如，一份合规PDF可能包含所有员工可访问的部分，以及仅限于法律团队的受限部分。确保你的分块管道能处理这一点。

因此，计划在RAG过程中捕获用户和访问元数据。如果你希望LLM从不看到用户不应访问的文档，你必须确保用户和访问数据可用。

工具使用：MCP和API

假设你希望允许客服团队成员使用AI工具更新银行客户信息——联系方式、账户偏好、服务请求。但不同角色可用的工具不同，即使使用相同工具，不同用户也有不同限制。一级支持代理可能可以更新电话号码，但不能调整信用额度。

两种路径：MCP和API

模型上下文协议（MCP）是使任何API或服务以结构化方式可被AI工具访问的新兴标准。Block、Bloomberg和Amazon等公司已经在内部使用MCP。但MCP不是唯一选择——普通API也工作得很好。AI模型能够从良好文档中理解API语义。

在发布时最新版本的MCP使用OAuth 2.1和授权码授予用于AI系统或工具的身份验证。还有正在开发的扩展支持客户端凭证授予。

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

MCP实现： 以下是使用身份设置MCP的方法：

1. 在你的现有API和服务之上构建一个MCP服务器。将MCP服务器配置为指向支持OAuth 2.1的身份提供商。MCP客户端应预先注册或动态创建。
2. 当MCP客户端尝试访问MCP服务器时，MCP服务器应重定向到配置的身份提供商，该提供商将对驱动MCP客户端的用户进行身份验证，然后颁发令牌。令牌随后呈现给MCP服务器。

（了解更多关于MCP和实现）

如果你需要超出OAuth范围的细粒度控制，你可能需要向MCP服务器访问的服务添加细粒度授权。

API实现： 对于API访问，模式更简单：

1. 使用你现有的API和服务；无需MCP服务器。
2. 使用身份提供商对用户进行身份验证。
3. 获取访问令牌。
4. 如果AI有web工具，它可以使用REST调用访问API，传递令牌。
5. 考虑也提供使用API的SDK。同样，如果你需要超出OAuth范围的细粒度控制，你可能需要向API和服务添加细粒度授权。

你可能有围绕身份验证和API的一些基础设施，可以重用。例如，多个API网关与FusionAuth一起工作。

代理系统：出发去工作

这是情况变得有趣的地方，也是AI身份验证需要新思维的地方。

代理是能够被提示以不同程度自主权完成任务的非确定性软件组件。它们扩展到数十或数百个实例，与人类、API和MCP工具交互，并将推理步骤链接在一起。

场景： 你的银行希望自动化新企业账户设置。新企业需要支票账户、储蓄账户、商户服务和薪资设置。代理需要：

• 评估企业类型并推荐套餐
• 从文档存储中收集企业文件（EIN、公司章程）
• 通过API检查信用状况
• 通过日历服务安排与关系经理的入职会议

这是一个多步骤工作流，处理混乱的数据和外部服务。这正是代理擅长的地方。但这也意味着它们将读取敏感文档、调用外部API并代表人类安排会议。风险很高。

身份链：

保护代理的基本概念：你需要知道谁在何时授权了什么。

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

这条审计线索就是身份链。

人类身份的携带深度取决于你的需求。如果你在每一步都进行授权检查，所需的身份取决于规则。如果你主要进行日志记录和调试，你可能只需要人类身份和当前代理身份。对于由计划触发的代理工作流，身份链可能从服务账户或cron作业的作者开始。

你可以使用签名的JWT来实现这一点，这确保了身份链在你的系统中得以保留。

FusionAuth目前不支持OAuth令牌交换（RFC 8693），但Vend JWT API实现了相同的身份链语义。如果你的身份提供商原生支持令牌交换，那是一个基于标准的替代方案。

FusionAuth的Vend JWT API允许你创建嵌入原始用户并传播身份信息的令牌。