Agent 一接企业知识库就开始串权限：从 Retrieval ACL 到 Tool Identity 最小授权的工程实战

🔐 为什么 Agent 一连知识库，权限问题就先暴露出来

很多团队把 Agent 接到企业知识库后，离线评测会先变好，因为可检索内容突然变多了；可一到线上，最先出现的往往不是准确率回落，而是权限边界开始模糊。⚠️ 用户明明只能看某个项目空间，Agent 却把同租户别的文档摘要拼进回答；更糟的是，后续工具还可能拿着放大的上下文继续执行。🧩

这类问题常被误判成向量库过滤不严，实际根因更靠前。真正危险的地方，是检索身份、重排阶段和工具执行身份没有被当成同一条链路设计。只要其中一环仍然使用共享服务账号，串权限就会从偶发错误变成系统性风险。🚨

🔍 真正的根因，不是单点过滤失效，而是身份链路断开

线上最常见的三个坑并不复杂。📉 第一种是 Planner、Retriever 和 Tool Runner 共用会话态，用户令牌在某一层被换成服务账号；第二种是 ACL 只在最终返回前做过滤，导致重排模型已经读到了不该看的候选；第三种是工具调用继续沿用平台级密钥，执行权限明显大于检索权限。🧠

这组数据说明，真正值得优化的不是某个过滤算子，而是“谁发起检索、谁消费候选、谁执行动作”这三个身份是否始终一致。📌 如果召回看的是用户权限，执行却换成平台超集权限，系统迟早会出事。🛑

🛠️ 更稳的做法，是把 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.now+120,}defsearch_with_scope(query,scope):signed=sign_scope(scope)hits=vector_store.search(query,acl=signed["doc_acl"])returnrerank(hits,scope_token=signed["token"])definvoke_tool(tool_name,payload,scope_token):returntool_gateway.call(tool_name,payload,delegated_scope=scope_token)

代码里的关键点只有一个：检索和工具都不重新推断权限，而是消费同一份签名范围。📦 一旦工具侧发现 scope 与资源标签不匹配，就立即拒绝并回传结构化原因，而不是让模型再试一次。🧪

📈 接下来 3 到 6 个月，企业 Agent 的分水岭会是授权可观测性

笔者认为，接下来企业 Agent 真正拉开差距的，不会只是模型效果，而是谁能把授权链路做成可观测基础设施。📊 监控里至少要同时看authorized_hit_rate、scope_mismatch_reject、delegated_tool_calls和acl_cache_staleness_ms；只看越权告警数量，通常已经太晚。🔁

另一个趋势也很明确。🚀 未来更多团队会把权限校验前移到检索入口，同时把工具侧改成短时委托令牌，而不是长期服务密钥。这样做会让链路稍长、接入更麻烦，但它换来的不是“更保守”，而是 Agent 在企业环境里可上线、可审计、可追责。🙂

Agent 接企业知识库后最危险的，不是答错，而是答对不该看的内容。💡 如果系统还在把 Retrieval ACL 和 Tool Identity 分开维护，现在最值得补的不是更多提示词，而是把身份链路先收拢成一条可验证、可拒绝、可审计的执行路径。欢迎交流你们线上更常见的是检索串权，还是工具借权。🤝