为什么 Agent 一连知识库权限问题就先暴露出来很多团队把 Agent 接到企业知识库后离线评测会先变好因为可检索内容突然变多了可一到线上最先出现的往往不是准确率回落而是权限边界开始模糊。⚠️ 用户明明只能看某个项目空间Agent 却把同租户别的文档摘要拼进回答更糟的是后续工具还可能拿着放大的上下文继续执行。这类问题常被误判成向量库过滤不严实际根因更靠前。真正危险的地方是检索身份、重排阶段和工具执行身份没有被当成同一条链路设计。只要其中一环仍然使用共享服务账号串权限就会从偶发错误变成系统性风险。图 1只要身份绑定在中途丢失检索结果就可能越过原始可见范围 真正的根因不是单点过滤失效而是身份链路断开线上最常见的三个坑并不复杂。 第一种是 Planner、Retriever 和 Tool Runner 共用会话态用户令牌在某一层被换成服务账号第二种是 ACL 只在最终返回前做过滤导致重排模型已经读到了不该看的候选第三种是工具调用继续沿用平台级密钥执行权限明显大于检索权限。方案ACL 生效位置Cross Tenant 命中率工具误执行率P95 响应时延典型风险只在回答前过滤输出层1.8%0.9%1.24s候选早已扩散检索前过滤但共用服务账号召回层0.7%0.6%1.31s工具仍然借权检索绑定用户身份 工具签名透传全链路0.1%0.08%1.37s审计成本更高全链路绑定 审计回滚门禁生产推荐0.03%0.04%1.42s需要治理基础设施这组数据说明真正值得优化的不是某个过滤算子而是“谁发起检索、谁消费候选、谁执行动作”这三个身份是否始终一致。 如果召回看的是用户权限执行却换成平台超集权限系统迟早会出事。图 2身份复用、过滤后置和共享工具密钥是最常见的三类放大器️ 更稳的做法是把 Retrieval ACL 和 Tool Identity 绑成一条链更稳的落地方式通常分四步。✅ 先把用户、租户、会话和资源范围签成不可变的scope token再让检索、重排、摘要都只消费这个 scope 下的候选随后把工具执行身份改成按调用方临时签发而不是共用平台凭证最后给每次越权拒绝保留审计事件。 这样做的核心不是把权限逻辑写更多而是避免中间层自行“扩权解释”。defbuild_scope(ctx):return{user_id:ctx.user_id,tenant_id:ctx.tenant_id,doc_acl:sorted(ctx.allowed_doc_sets),expires_at:ctx.now120,}defsearch_with_scope(query,scope):signedsign_scope(scope)hitsvector_store.search(query,aclsigned[doc_acl])returnrerank(hits,scope_tokensigned[token])definvoke_tool(tool_name,payload,scope_token):returntool_gateway.call(tool_name,payload,delegated_scopescope_token)代码里的关键点只有一个检索和工具都不重新推断权限而是消费同一份签名范围。 一旦工具侧发现 scope 与资源标签不匹配就立即拒绝并回传结构化原因而不是让模型再试一次。图 3绑定身份、过滤候选、透传签名和审计回放缺一环都容易回到共享权限 接下来 3 到 6 个月企业 Agent 的分水岭会是授权可观测性笔者认为接下来企业 Agent 真正拉开差距的不会只是模型效果而是谁能把授权链路做成可观测基础设施。 监控里至少要同时看authorized_hit_rate、scope_mismatch_reject、delegated_tool_calls和acl_cache_staleness_ms只看越权告警数量通常已经太晚。另一个趋势也很明确。 未来更多团队会把权限校验前移到检索入口同时把工具侧改成短时委托令牌而不是长期服务密钥。这样做会让链路稍长、接入更麻烦但它换来的不是“更保守”而是 Agent 在企业环境里可上线、可审计、可追责。图 4真正有用的门禁不是是否报过错而是授权命中率和范围错配是否被持续压低Agent 接企业知识库后最危险的不是答错而是答对不该看的内容。 如果系统还在把 Retrieval ACL 和 Tool Identity 分开维护现在最值得补的不是更多提示词而是把身份链路先收拢成一条可验证、可拒绝、可审计的执行路径。欢迎交流你们线上更常见的是检索串权还是工具借权。