人工智能时代的身份验证：为何传统安全架构依然不可或缺
在众人争相部署AI智能体之际，一个关键事实被忽略了：2010年代守护API繁荣的身份验证与授权模式，正是当下保护AI系统所需的核心要素。
倘若你已构建过OAuth集成、管理过API密钥、或配置过基于角色的访问控制（RBAC），那么你已掌握大部分必备知识。AI安全并非全新领域——它是对现有优秀实践的延伸。
"让AI在缺乏确定性防护机制的情况下接触资源，是一种鲁莽之举。"
AI系统具有概率特性——它们会推理、产生幻觉、随机应变。但管控它们为谁服务以及允许执行何种操作的身份层必须是确定性的。身份认证不能是"凭运气"的事情。
文章以一个贯穿始终的场景展开：你是一家银行的工程经理，希望通过AI优化员工和客户的支援台运营。围绕这一场景，文章剖析了三种AI应用场景：
RAG通过在查询时向AI模型提供文档来扩充其可用数据。核心安全关注点是：并非每个用户都应看到每份文档。
为何身份对于RAG至关重要：
当回答查询时，大语言模型甚至不应看到用户无权访问的文档。这不是提示工程的问题——你无需精心设计提示词让模型保守秘密。借助正确的授权框架，你可以在文档抵达模型之前进行过滤。
大语言模型仅接收通过授权检查的文档。这首先是一个授权问题——核实用户身份，处理查询，从向量数据库中提取文档，然后根据用户权限筛选文档。
实施步骤：
1.将文档分块成适合向量搜索的片段
2.构建授权模式，将用户和角色映射到文档访问权限
3.在检索时存储元数据，包括哪些角色、部门或用户可以访问每个块
4.进行身份验证，获取用户的身份声明，根据用户和文档属性进行过滤
5.将结果传递给大语言模型
这里的关键是，授权逻辑应是集中且确定的，而不管使用何种RAG框架。
这是一个流程图，展示了请求流程（以及如果文档已存储适当的元数据）：
关于元数据的注意事项：
文档并不总是干净地映射到某个访问级别。例如，一份合规PDF可能包含所有员工都能访问的部分，以及仅限于法律团队的部分。确保你的分块流水线可以处理这种情况。
如果你希望大语言模型不看到用户不应访问的文档，请确保用户和访问权限数据在检索之前就可用于过滤。
工具使用让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服务器的访问。
智能体是非确定性的软件组件，可以通过提示完成具有不同自主程度任务。它们可以扩展到数十或数百个实例，与人类、API和MCP工具交互，并将推理步骤串联起来。
核心安全概念：身份链（Chain of Identity）
当一个人类启动一个智能体工作流时，该人类的身份需要跟随智能体完成每一个步骤。如果智能体读取文件，你需要知道是哪个人类授权了那次读操作。如果智能体安排了会议，你需要知道是代表谁安排的。如果出了问题，你需要一条可追溯到发起者的审计线索。
这就是身份链。
使用JWT实现身份链：
FusionAuth的Vend JWT API允许你创建嵌入原始用户并在智能体交接工作时传播该身份的令牌。它使用act声明（遵循OAuth令牌交换规范RFC 8693）来表示委托链中的执行者：
constresponse=awaitclient.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
·日历智能体—安排入职会议
这种拆分的好处：
1.安全爆炸半径缩小：如果日历智能体被攻破，它无法访问文档或信用数据
2.上下文窗口管理：每个智能体只需要与其任务相关的上下文
3.显式信任边界：信任在智能体之间的边界处授予，而不是一个可以访问一切的智能体
4.防止交叉污染：来自一个服务的数据不会泄漏到另一个智能体的上下文中
实体权限配置示例：
//为智能体创建实体类型 constentityTypeResponse=awaitclient.createEntityType({ entityType:{ name:'Banking Agent', description:'AI agents for banking workflows'} }); //创建权限 awaitclient.createEntityTypePermission({ entityTypeId:entityTypeId, permission:{ name:'invoke', description:'Permission to invoke this agent'} }); //创建智能体实体 constcoordinator=awaitclient.createEntity({ entity:{ name:'business-account-setup', entityTypeId:entityTypeId } });
审计日志：
所有智能体操作都应记录到审计日志中，捕获智能体身份、人类发起者身份、操作类型和时间戳。这提供了完整的可追溯性。
清理策略：
·工作流成功完成后，清理智能体实体凭据
·对于错误状态，实现一个"收割者"进程来处理失败工作流产生的孤立实体
文章最后总结了三个核心信念：
1.人类身份是AI权威的根源—有人编写了那个任务，有人授权了那个智能体，这应始终被追踪
2.AI安全最好是作为现有优秀实践的延伸—OAuth、令牌、网关：保护API时代的技术同样适用于AI时代，不要重新发明轮子
3.身份执行必须是确定性的—AI系统是概率性的，但管理它们的身份层不能是。当你检查智能体是否有权限读取文档或安排会议时，答案必须是"是"或"否"，而不是有时"是"有时"否"
AI数据溯源和身份链的概念正在定义之中，但基本要素不会改变：人类身份为根、确定性执行、纵深防御。基于这些原则构建，你的AI系统将拥有安全的基础。
原文：AI Authentication and Authorization — Dan Moore, FusionAuth