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

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 系统是概率性的但管理它们的身份层不能是。当你检查智能体是否有权限读取文档或安排会议时答案必须是是或否而不是有时是有时否AI 数据溯源和身份链的概念正在定义之中但基本要素不会改变人类身份为根、确定性执行、纵深防御。基于这些原则构建你的 AI 系统将拥有安全的基础。原文AI Authentication and Authorization — Dan Moore, FusionAuth