智能体正在从「会聊天」走向「会做事」：读企业知识库、调用工具、替人提交操作。一旦 agent 拿到了凭据，「它是谁、替谁、能看什么」就成了架构的第一道关口。2025–2026 年，这个问题的答案开始收敛——MCP 把工具服务端定义成 OAuth 2.1 资源服务器，IETF 的跨域身份链草案进入 RFC 编辑队列，NIST 与 CSA 先后给出 agent 身份指导，微软为 agent 发放一等目录身份，Azure 与 Vertex 把文档级 ACL 做进了检索层。本文把这些材料拆成身份、授权、数据三层，梳理一套可落地的智能体知识库权限架构，并把仍在争论的问题摊开。全文时效陈述均截至 2026-10-23。
一、为什么 agent 不能只是「又一个服务账号」
传统做法是给 agent 发一把 API key 或一个服务账号，权限按最宽配置。这在 agent 时代失效，原因有三。
第一，数量爆炸。 CyberArk 2025 年《Identity Security Threat Landscape》报告称，企业内机器身份与人类身份之比已达 82:1；Palo Alto Networks 2026 年的身份安全态势报告给出的数字是 109:1。agent 不是一个账号，而是成千上万个短命的执行实例，手工维护角色表没有可行性。
第二，行为不可预测。 agent 的执行路径由模型推理决定，同一个「服务账号」在一次会话里可能读十份文档、调三个工具、再把子任务转交给另一个 agent。静态的角色表无法表达这种随任务变化的权限需求。
第三，委托链断裂。 agent 常常「替用户」操作，但传统凭据只能表达「我是 agent」或「我是用户」（冒充），无法同时说明「我是 agent，当前代表用户 A，且受用户 A 授权范围的子集约束」。一旦下游系统分不清这两者，审计日志就把责任记到了错误的主体上。
NIST 在 2026-08-27 的博客《Back to the Future: Why Agentic AI Needs a Strong Identity Foundation》中把这类风险归纳为五条：凭据共享破坏问责与不可否认性；静态长期凭据（API key、bearer token）不能证明身份、易泄露且常明文存放；权限范围过宽，agent 速度快、规模大，一旦出错破坏面也大；用本地账户部署 agent 导致冒充用户、无法集中管理；过度依赖「人在回路」审批带来同意疲劳。该文属于 NCCoE 的「Software and AI Agent Identity and Authorization」项目，结论很直接：agent 需要一等身份。云安全联盟（CSA）2025-08-18 的白皮书《Agentic AI Identity and Access Management: A New Approach》把问题再推一步：现有 OAuth 2.1 无法安全表达多级委托链，需要补上 requested_actor / actor_token 之类的语义。
小结：agent 身份问题的本质不是「多发几个账号」，而是把「谁、替谁、做什么、看什么」四件事分开表达，并且每一步可审计。
二、身份层：认证标准正在收口
RFC 8693：委托的原语
2020 年发布的 RFC 8693《OAuth 2.0 Token Exchange》定义了 grant type urn:ietf:params:oauth:grant-type:token-exchange：subject_token 表示被代理方（用户），actor_token 表示实际执行方（agent），授权服务器签发的新令牌用 act claim 记录执行者链。这恰好区分了委托（下游知道是 agent 代表用户）与模拟（下游以为就是用户本人），是所有 agent 委托方案的基础原语。微软 Entra Agent ID 的 sidecar Auth SDK、Okta 的 AI agent token exchange、Auth0 的 Token Vault，底层都是这一机制。
MCP：把工具服务端变成 OAuth 2.1 资源服务器
MCP 授权规范的演进是过去一年最重要的信号。2025-06-18 版把 MCP Server 明确定义为 OAuth 2.1 资源服务器：必须实现 RFC 9728 受保护资源元数据（401 响应的 WWW-Authenticate 头指向 /.well-known/oauth-protected-resource），必须用 RFC 8414 发现授权服务器，必须带 RFC 8707 resource 参数把令牌绑定到目标服务器，必须使用 PKCE；并用一句话封死了最常见的漏洞——「MCP servers MUST NOT accept or transit any other tokens」：不接受非为自己签发的令牌，也不把客户端的令牌透传给上游。
随后两个版本继续收紧。2025-11-25 版加入 OIDC Discovery、经 WWW-Authenticate 的增量授权（SEP-835），并引入 Client ID Metadata Documents 作为推荐注册方式（SEP-991）；2026-07-28 版进一步废弃 RFC 7591 动态客户端注册、改用 Client ID Metadata Documents，并要求校验 RFC 9207 的 iss 参数。注册机制一年内三次修订，但「资源服务器严格校验 audience」这条主线从未动摇。
跨域身份链：从草案走向 RFC
agent 调用链常常跨信任域：企业 IdP 签发的身份要传到 SaaS 供应商的 API。IETF OAuth 工作组的《OAuth Identity and Authorization Chaining Across Domains》给出标准路径：A 域客户端先用 RFC 8693 向本域授权服务器换取一个 JWT 授权凭据，再以 RFC 7523 的 jwt-bearer grant 呈交给 B 域授权服务器换取 B 域令牌；身份与授权上下文经 claims 一路链式传递，支持 claims 转写（身份映射、数据最小化、scope 收缩），并明确不建议跨域发放 refresh token。该草案最新为 -17 版（2026-07-19），IESG 状态为 RFC Ed Queue，距离正式 RFC 只差编辑环节。另有专门面向 agent 场景的 draft-oauth-ai-agents-on-behalf-of-user 定义 on-behalf-of 流程与 Actor Token。
平台侧：一等身份与协议层身份
微软在 Build 2025 期间（2025-05-19）预览 Entra Agent ID，官方文档已宣告正式可用：为 agent 发放 Entra 一等身份，附带蓝图（blueprint）、sidecar Auth SDK（把用户令牌兑换为 agent-on-behalf-of-user 令牌）、面向 AWS Bedrock / n8n / GCP 等非微软 agent 的集成、agent 条件访问模板与孤儿 agent 治理。Google A2A 协议（2025-06-23 捐赠给 Linux Foundation）走另一条路：载荷不携带身份，身份在 HTTP 传输层建立，Agent Card 的 security 字段按 OpenAPI 规范声明支持的认证方案，凭据带外获取。
| 标准 / 产品 | 解决的问题 | 状态（截至 2026-10-23） |
|---|---|---|
| RFC 8693 Token Exchange | 用 act claim 表达「agent 代表用户」 |
正式 RFC（2020） |
| MCP Authorization | 工具服务端 = OAuth 2.1 资源服务器，禁止令牌透传 | 2026-07-28 版现行 |
| draft-ietf-oauth-identity-chaining | 跨信任域链式传递身份与授权 | -17 版，RFC Ed Queue |
| Microsoft Entra Agent ID | 给 agent 发一等目录身份与委托令牌 | 已正式可用 |
| Google A2A | agent 间互认，身份在传输层 | Linux Foundation 项目 |
| SPIFFE / WIMSE | 工作负载身份，NIST 推荐 | 用于 agent 尚无 CNCF 官方表态 |
小结：身份层的共识是「OAuth 2.1 加 Token Exchange 做骨架，资源服务器严格校验 audience」，分歧只剩发现与注册的细节。
三、授权层：从角色表到策略引擎
三种模型如何选
| 模型 | 表达能力 | 对 agent 场景的适配 | 代表实现 |
|---|---|---|---|
| RBAC | 角色到权限的静态映射 | 粗粒度，表达不了「这次任务只需这 3 个工具」 | 传统 IAM |
| ABAC | 主体、资源、环境属性驱动策略 | 能表达时间、信任分、委托深度等上下文 | AWS Cedar、OPA |
| ReBAC | 主体与资源的关系图 | 天然表达「用户能看的文档即 agent 代表用户能检索的文档」 | OpenFGA（Zanzibar 血统） |
OpenFGA 官方文档《Authorization for Agents》给出四种模式：任务型授权（agent 初始零权限，按任务签发带过期时间的窄权限）、RAG 授权、MCP Server 授权（角色加组加时间约束）、agent 作为一等主体；并区分「第一方」与「第三方」两个授权域。
AWS 2026-07-06 的安全博客用 Cedar 给多 agent 调用链写了三层策略：第一层约束 agent 到工具（信任分、命名空间、生命周期），第二层约束 agent 到 agent（委托不超过 5 跳，子任务必须是已注册能力的子集），第三层回溯到原始用户（角色、MFA、委托深度），并结合 RFC 8693 的 on-behalf-of 流程。Bedrock AgentCore 的策略层也选了 Cedar。
三个必须规避的反模式
MCP 官方的安全最佳实践列出的攻击面值得每个知识库团队对照自查：
- 令牌透传：MCP Server 把客户端令牌原样转给下游，会绕过限流与 audience 控制，下游日志把身份记错（审计断链），并可能让服务端沦为数据外渗代理。
- 混乱代理人：静态
client_id、动态客户端注册、第三方授权服务器的同意 cookie 三者叠加，攻击者可跳过用户授权环节；缓解措施是对每个动态注册的客户端逐个征得同意、redirect_uri精确匹配、state一次性短时效。 - 会话当认证：规范原文是「MCP Servers MUST NOT use sessions for authentication」——session ID 只能是安全随机值并绑定用户，令牌必须在每个请求里携带。
权限的时间维度
NIST 博客建议的组合是：短时效、细粒度、限定受众的令牌，加即时（JIT）授权，加沙箱化的执行环境；MCP 的 Scope Minimization 指南要求从最小 scope（如 mcp:tools-basic）起步、通过 WWW-Authenticate 挑战增量提权、禁用通配 scope。NIST 同时警告：把「人在回路」当兜底会制造同意疲劳——与 MFA 轰炸同理，用户会机械点「允许」，MCP 的 elicitation 机制也可能被滥用来索取敏感信息。
小结：授权层的方向是「任务即权限」——策略引擎按任务上下文现算，令牌短命、受众绑定、可追溯到原始用户。
四、数据层：知识库的权限感知检索
Copilot 的教训：检索会放大已有的权限失控
Microsoft 365 Copilot 的「过度共享」是最有代表性的案例。Copilot 只尊重既有权限，但大量 SharePoint 站点本就因「所有人可见」的历史配置而失控——AI 检索把这些本来「没人会去翻」的文档一次性端到了用户面前。微软的应对分两步：2024-06-24 正式可用的 Restricted SharePoint Search 让管理员维护最多 100 个站点的允许列表，官方明言它「不是安全边界，不改变任何权限」；2026-07-31 起该功能停止新启用，由 SharePoint Advanced Management（随 Copilot 许可证附带）、Restricted Content Discovery 与 Purview 接棒，治理蓝图是「修复过度共享、设置护栏、满足合规」三步。教训是：检索层不能替权限治理兜底，但检索层必须忠实执行权限。
把 ACL 做进检索层
Azure AI Search 的文档级访问控制提供四条路径：安全过滤器（字符串比较，已正式可用、与 API 版本无关）、POSIX 风格 ACL 与 RBAC scope（preview）、Purview 敏感度标签（preview）、SharePoint ACL（preview）。后三者机制一致：索引时把权限元数据写进文档，查询时请求头 x-ms-query-source-authorization 携带用户的 Entra 令牌，服务端提取 user、group、scope claims 与元数据比对，只返回匹配的文档。时间线上，2025-05 预览 ADLS Gen2 ACL，2025-08 新增 vectorFilterMode=strictPostFilter（全局 top-k 后严格过滤），2025-11 加入 SharePoint ACL 与 Purview 标签；截至 2026-10 文档级权限仍处 preview（需 2026-08-01-preview API），并已通过 MCP 的 knowledge_base_retrieve 工具把敏感度标签信息返回给 agent。Google Vertex AI Search 的做法类似：创建数据存储时 aclEnabled=true（不可事后开关），Drive、Confluence、SharePoint 的 ACL 直接继承源系统，每文档最多 3000 个 readers，身份通过 Google Identity 或 Workforce Identity Federation 映射（支持 Entra ID、Okta）。
向量数据库层面：Weaviate 自 v1.20（2023-07）起原生多租户，每租户独立 shard；Qdrant 提供基于 API key 加 JWT 的 RBAC 与分层多租户；自建方案常用 pgvector 加 PostgreSQL 行级安全（RLS）。
先过滤还是后过滤
OWASP RAG Security Cheat Sheet 的立场明确：「访问控制必须在内容到达模型之前执行」，且检索前过滤更安全——检索后过滤会暴露受限文档的相似度分数，可被差分探测；它还提醒「嵌入向量不是匿名数据」，访问控制继承失效是「企业 RAG 部署中最常见的合规失败」，并给出总纲：RAG 不会降低风险，只是重新分配风险。
工程上有四种实现模式：A 类在摄入时把 ACL 固化进 chunk 元数据、查询时预过滤（Azure 与 Vertex 的路线）；B 类逐请求转发用户令牌、由数据平台裁决（如 Databricks 的 on-behalf-of，不复制数据因此没有陈旧问题，但每次检索都要回源）；C 类用索引 ACL 粗滤候选、查询时回源逐条复核；D 类用父级关系型授权（FGA）判定可见资源集合、再做本地元数据过滤。
三个必然踩到的坑
- ACL 同步延迟：Azure 官方承认源系统的权限变更「只有在元数据同步到索引之后才反映到检索结果」；SharePoint 唯一权限项的增量同步自
2026-05-01-preview才支持，继承权限仍需显式刷新。两次同步之间被撤权的人依然能拿到答案。 - 孤儿 chunk：文档已删除、向量仍残留。「加个 metadata filter」只解决泄漏，不解决陈旧。
- 召回损伤：预过滤在排序前收缩候选池，租户内数据稀疏时检索质量明显下降，需要在权限与召回之间显式权衡。
另有 USENIX Security 2025 的 PoisonedRAG 研究：注入少量毒化文本即可达到 90% 的攻击成功率——权限架构防的是「越权读」，对「被投毒」还需要摄入侧的内容校验。
小结：数据层的原则是 fail-closed、预过滤优先、权限元数据有明确的新鲜度保证。
五、参考架构：三层控制面
把上面三层合起来，智能体知识库的参考架构如下：
flowchart LR
U[用户] -->|登录| IDP[企业身份提供方]
IDP -->|用户令牌| AG[Agent 运行时]
AG -->|RFC 8693 Token Exchange| AS[授权服务器]
AS -->|短命且绑定 audience 的委托令牌| AG
AG -->|任务上下文| PDP[策略引擎 Cedar 或 OpenFGA]
PDP -->|本次任务允许的工具与范围| AG
AG -->|MCP 请求携带令牌| MCP[MCP 知识库服务端]
MCP -->|校验 audience 后以用户身份检索| VS[向量索引 含 ACL 元数据]
VS -->|仅返回可见 chunk| MCP
MCP -->|结果| AG
AG -->|原始用户 agent 工具 文档| LOG[审计日志]
九条设计原则：
- 身份分离：用户身份、agent 身份、工具服务端身份三者各自可验证，委托关系用
actclaim 表达，禁止用用户凭据直接运行 agent。 - 令牌短命且受众绑定：每个 MCP Server 只接受为自己签发的令牌（RFC 8707
resource），拒绝透传。 - 任务即权限：agent 初始零权限，策略引擎按任务签发窄范围、带过期的授权，通配 scope 禁用。
- 预过滤检索：用户身份一路传播到检索层，ACL 在排序前生效，拿不到身份就 fail-closed。
- 权限元数据有新鲜度 SLA：定义 ACL 同步周期与撤权生效上限，删文档同步删向量。
- 委托深度上限与能力子集：agent 到 agent 的链路限制跳数，子任务权限只能收缩不能放大。
- 人在回路只放在高风险动作：写操作、跨域调用、触达敏感标签；读操作靠策略自动化，避免同意疲劳。
- 全链路审计：每条日志同时记录原始用户、执行 agent、调用工具与触达文档，能从一次文档访问回溯到人。
- 摄入侧内容校验：防投毒与隐藏指令，权限架构不覆盖这一面。
六、争议与未解问题
agent 是否需要独立身份。 Curity 的观点是「agent 自动替用户执行任务并不意味着需要专属身份」，沿用用户委托加标准 OAuth 即可；SGNL 联合创始人 Atul Tulshibagwale 则主张 agent 必须有独立身份，否则 IAM 团队会被迫过度授权；Aembit 给出折中：自主运行时用非人类身份，代表用户时挂靠人类身份。NIST 与微软的实践站在「一等身份」一边，但 Aembit 也指出多协议并存（OAuth 令牌、API key、云托管身份、MCP bearer）本身就是攻击面，「缺陷在协议之间」，团队在运营压力下往往默认取最宽权限。
OAuth 是否够用。 CSA 白皮书直言传统 OAuth 无法安全表达委托链，提出扩展 OAuth 2.1 并探索 DID 加可验证凭证的 agent 身份；IETF 的身份链草案与 agent on-behalf-of 草案则选择在现有框架内打补丁。两条路线谁先落地，决定了未来两年企业 IAM 的改造成本。
标准碎片化。 MCP、A2A、OpenAI Actions 各有授权约定；MCP 一年内三次修订注册机制，说明 agent 自助注册仍无定论。知识库厂商目前只能同时适配多套协议。
人在回路的边界。 NIST 把过度依赖 HITL 列为风险，但完全自动化又把责任推给策略引擎；谁对 agent 的越权行为负责，法律与审计框架都还没给出答案。
以上判断中，「预过滤优先」「任务即权限」有多方一手材料支撑；「一等身份将成主流」是本文作者基于 NIST、微软、CSA 方向的推测。
参考资料
- MCP Authorization 规范（2025-06-18 版）——资源服务器模型与令牌透传禁令的原文。
- MCP Security Best Practices——令牌透传、混乱代理人、会话劫持三大反模式。
- IETF draft-ietf-oauth-identity-chaining——跨信任域身份链，-17 版，RFC Ed Queue。
- NIST：Why Agentic AI Needs a Strong Identity Foundation（2026-08-27）——五条风险与推荐标准栈。
- CSA：Agentic AI Identity and Access Management（2025-08-18）——扩展 OAuth 2.1 与 DID 路线的提案。
- AWS：用 Cedar 在多 agent 链中执行最小权限（2026-07-06）——三层策略的完整示例。
- Azure AI Search 文档级访问控制——四条路径、查询时令牌比对与同步延迟限制。
- OWASP RAG Security Cheat Sheet——预过滤优先与 fail-closed 原则的权威出处。
读者留言
COMMENTS 暂无还没有留言，来说第一句？