1. 从“人用的软件”到“Agent 用的软件”权限体系为什么必须推倒重来最近大半年我一直在帮几家中大型客户做企业软件系统的 Agent 化改造从 CRM、OA、工单到内部知识库都有涉及。做来做去最后基本都会卡在同一个问题上——权限。传统企业软件在权限上其实已经形成了一套相当成熟的模式RBAC基于角色的访问控制、ABAC基于属性的访问控制、数据权限范围、字段级脱敏、操作审计……这套东西支撑了企业信息化二十年大家已经习以为常。可一旦把 Agent 接进来就会发现这些老方法全都失灵了。为什么失灵根本原因在于身份模型发生了断裂。传统软件的身份主体是“人”你有账号有密码或者 SSO系统知道你姓甚名谁属于哪个部门权限自然能跟着身份走。而 Agent 是什么它是一段代码、一个进程、一个 API 调用链它不是“人”但又必须替“人”去操作业务系统。那么它到底算谁它有资格访问哪些数据它能执行哪些操作这中间如果处理不好要么权限给少了 Agent 干不了活要么权限给多了变成内部数据泄露的大口子。我见过最典型的翻车案例是某公司把内部知识库接给了智能问答 Agent为了方便直接用一个服务号把整库只读权限给了 Agent。结果员工通过 Agent 提问“去年天津分公司所有人的调薪记录”系统二话不说就吐出来了。从技术角度来说一点毛病没有Agent 就是在正常履行问答职责但从权限角度来说这属于严重的越权访问——因为提问的普通员工根本没有权限查看这些敏感数据而 Agent 替他问了就绕过了所有人的控制。这个案例让我下定决心要把“Agent 场景下权限怎么继承”这件事彻底想清楚。本文将围绕企业软件为 Agent 重做一遍的过程中最核心的权限继承机制展开覆盖原理、方案设计、具体落地步骤和常见坑希望能给正在做类似改造的团队一些参考。2. Agent 权限继承的本质身份、属性和信任边界的代际传递2.1 权限继承是个古老的计算机概念但在 Agent 场景下有了新含义权限继承Permission Inheritance这个术语玩过 Windows 文件系统或者 Linux 目录权限的人都不陌生——子目录默认继承父目录的 ACL新建子文件自动套用所属组的权限这就是继承。在面向对象编程里子类继承父类的方法和属性也是一种继承。Agent 场景下的权限继承本质上是同一件事Agent 作为用户的“代理人”需要继承用户的权限边界同时叠加 Agent 自身的额外约束。换句话说用户有什么权限Agent 就有什么权限但不能多。这叫“人机权限对齐”。但问题没有这么简单。如果只是简单地把用户权限拷贝一份给 Agent那会出现几个新麻烦一是会话割裂。Agent 不是你它是你的数字孪生或者说业务代理当你不在场时它可能还在后台跑流程。它执行操作时代表的是用户身份但其运行环境、网络出口、调用工具链跟人完全不一样。如果系统只认操作者身份而不校验更多上下文那任何人都能伪造一个“用户代理”来提取权限。二是横向越权。用户 A 的 Agent 和用户 B 的 Agent 如果跑在同一个服务号下一旦识别主体时只用了服务号身份那 A 的 Agent 就能操作用户 B 的数据。权限继承必须精确到每个 Agent 实例、每次会话而不能笼统地“所有 Agent 共用一个角色”。三是任务与身份的割裂。在很多业务流程里Agent 不是一个人在战斗而是多个 Agent 协作——A 负责拉数据B 负责做分析C 负责生成报告。每个 Agent 承担的职能不同但最终用户只有一个。权限继承必须考虑任务上下文一个只读分析型 Agent 哪怕继承了大老板的身份也不应该能执行删除操作。所以 Agent 权限继承本质上要解决的是一道三重映射题用户身份 → 用户权限 → Agent 任务所需最小权限 → 运行时授权。2.2 从热搜词看主流关注点大家其实都在同一个坑里我看到这个主题相关的热搜词主要集中在几类device/vpp权限问题、用户拒绝访问权限、admin权限删除、android系统日期权限、linux目录权限、数据库表空间无权限等——这些基本涵盖了日常开发中会遇到的各种权限报错。但针对“Agent 权限继承”大家真正关系的问题是Agent 能干什么、不能干什么、由谁说了算、怎么记账。网上讨论最多的几个高频方向Agent 安全Agent 能力越强权限失控风险越大安全防护怎么匹配。知识库如何控制权限到人企业内部知识库接 Agent 后数据权限如何精确落位。不同的继承方式有人提“角色继承”有人提“数据域继承”还有人提“任务级继承优先级”。封装继承多态这是在聊面向对象吗其实也是在隐喻 Agent 的权限模型需要按职责封装只暴露最少必要能力给外部。我注意到很多团队的困惑点在于Agent 框架本身提供了权限模块例如某些开源框架中有“Agent Skill 权限声明”但到了企业系统里这些小模块根本扛不住实际的业务复杂度——组织架构、角色、数据范围、密级、风控策略每一层都有一套存量规则。所以抱着一堆开源组件还是要回到企业权限中台去解决继承链路。2.3 权限继承的三种主流机制对比在实操层面我总结出目前业界用下来比较靠谱的 Agent 权限继承方案大体可以分成三类机制核心思路优点缺点适用场景租户级继承按租户/客户维度分配 Agent 权限同一租户下的 Agent 权限相同实现简单维护成本低无法精确到个人粒度太粗多租户 SaaS 产品面向企业客户的助手型 Agent任务级继承按任务发起人身份解析权限Agent 执行任务时模拟用户身份权限精确符合最小化原则需要处理长任务时的权限快照问题企业内部流程自动化、数据查询、审批代办身份传播继承通过协议头、Token、上下文传递用户身份各系统按解析出的用户去鉴权权限天然一致无需复制角色链路改造量极大跨系统协议不统一时易断裂微服务架构成熟、已有统一身份中台的大型企业这三种机制没有绝对的好坏实际项目中往往是组合使用。我见过做得最顺的案例——一家金融科技公司底层是统一身份中台所有系统接入 SSO 和统一鉴权 SDKAgent 调用企业内部 API 时通过 JWT 传递用户身份每个微服务内部用 Filter 解析出当前操作者Agent 层的路由网关再叠加一层任务上下文最终实现“用户身份 Agent 任务 设备指纹”三重校验。这个方案跑下来权限错误率不到万分之一。3. 核心实操企业属性继承的四层建模与落地方案3.1 四要素继承模型角色、组织架构、数据域、安全等级先不急着写代码我们把 Agent 权限继承归约成四个维度的“属性传递”这四层每一层都对应企业系统里已有的权限设计Agent 化改造只需要让它们贯通起来。第一层角色继承Role Inheritance。这是最基础的一层——Agent 启动时绑定一个“发起人”直接把发起人在 RBAC 体系里的角色列表包括角色层级复制到 Agent 执行上下文。例如张三在 OA 系统里是“部门经理”他的 Agent 就天然拥有部门经理角色的审批权限。但要注意角色继承是“动态引用”不是“快照复制”。如果张三刚被提拔成总监他的 Agent 权限也应该立刻跟着变不能因为会话还开着就继续用旧身份。第二层组织架构继承Organization Inheritance。企业权限往往附着在组织树上比如华东大区的人只能看华东数据财务部的角色只能操作财务模块。Agent 发起时需要把用户在组织架构中的节点位置一并带上。这里有一个容易出问题的点组织架构本身是层级结构如果用户既属于 A 部门又兼任 B 项目组权限是取并集还是交集我的建议是取“当前任务上下文相关的组织节点”比如发起一个“报销审批”任务优先使用财务线组织节点发起“销售看板”任务优先使用销售线组织节点。第三层数据域继承DataScope Inheritance。光有角色和组织还不够很多权限其实表达为“数据范围”比如只读自己的工单、只读本部门客户、只能导出最近 30 天数据。Agent 在访问企业数据时必须在 SQL 层注入数据权限条件而不是靠前端隐藏按钮就算了。具体实现上通常会把用户的 DataScope 规则翻译成 Agent 查询请求自动拼接的过滤条件比如WHERE owner_id current_user_id或WHERE dept_id IN (子部门列表)。第四层安全等级继承Security Level Inheritance。如果企业涉及敏感数据如核心源码、财务数据、商业秘密通常会有密级标签公开、内部、机密、绝密。Agent 在执行任务时要校验“用户密级 ≥ 数据密级”和“Agent 执行环境密级 ≥ 数据密级”两个条件同时满足才能放行。这里特别提醒一句很多系统里用户本身没有密级概念数据密级也形同虚设如果不先建设数据分类分级Agent 权限继承就是沙滩上盖楼。3.2 人机权限隔离Agent 不是用户本人权限边界要单独算踩坑之后我总结出一个原则Agent 永远不能直接替代用户。即便 Agent 完全继承用户的角色和数据域你也必须在技术上把“人操作”和“Agent 操作”区分开否则审计和风控都会失效。我见过的最危险做法是Agent 直接使用用户个人 Token 调用业务 API。表面上看权限没问题实际上 Token 一旦泄露或被截获攻击者拿到的是一个有完整权限的“人”入口而且可以任意操作。正确做法应该是Agent 服务统一使用独立身份Service Account不直接保存用户个人 Token每次任务开始或会话建立时Agent 向权限中台申请一个临时委派凭证该凭证绑定用户身份 任务范围 有效期下游系统校验凭证时能同时看到“真实用户”和“委派 Agent”两个主体在审计日志里也能区分。这个设计在业界有个叫法——Identity Propagation身份传播通俗说就是“人令牌不下沉Agent 令牌不越权”。在这个模式里用户 Token 在浏览器或客户端Agent 后台每次拿着一个短期凭证去干活凭证过期自动失效做到“人走权消”。3.3 技术落地一个最小可用的 Agent 权限继承实现流程光讲理论容易飘我直接给一套经过验证的最小实现流程。假设你已经有一个企业内部 API 服务使用 JWT 做认证要接入一个简单的问答 Agent。第一步改造用户身份认证增加 Agent 委托声明在用户登录后客户端调用新建任务接口时后台生成了一个 AgentTask Token结构携带user_id真实用户 IDagent_idAgent 实例 IDsession_id任务会话 IDrole_refs用户的角色 ID 列表data_scope数据范围表达式exp过期时间建议短时效如 10 分钟。// 简化示例生成 Agent 委派 Token const jwt require(jsonwebtoken); const agentToken jwt.sign({ user_id: u_10023, agent_id: agent_5, session_id: sess_901, role_refs: [role_dept_manager, role_finance_viewer], data_scope: { dept_ids: [d_102, d_103], owner_only: false }, level: 3 }, process.env.AGENT_JWT_SECRET, { expiresIn: 10m, audience: internal-api, issuer: agent-gateway });第二步API 网关解析 Agent Token翻译成标准鉴权上下文网关层拿到 Token 后不是直接把 Token 转发给业务服务而是解析后组装成一个标准化的 AuthContext 对象再通过 gRPC Metadata 或 HTTP Header 传给下游。# 示例Python FastAPI 网关注入鉴权上下文 from fastapi import Request, Header async def resolve_auth_context(request: Request): token request.headers.get(X-Agent-Token) if not token: # 走普通用户 Token 逻辑 return resolve_user_token(request) payload decode_agent_token(token) return { user_id: payload[user_id], agent_id: payload[agent_id], roles: payload[role_refs], scope: payload[data_scope], security_level: payload[level] }第三步业务服务根据 AuthContext 自动拼装数据权限条件这一步是整个方案的关键点。数据查询的 SQL 里必须注入权限过滤条件而不能只依赖应用层“你不点这个按钮就没事”的思路。以 MySQL 查询订单为例-- 原始查询危险 SELECT * FROM orders WHERE status PENDING; -- 加了数据权限条件后安全 SELECT * FROM orders WHERE status PENDING AND ( owner_id u_10023 OR dept_id IN (d_102, d_103) );在工程上一般建议用统一的 MyBatis 拦截器或 JPA 审计字段来拼条件不要让每个业务开发自己去写权限 SQL很容易漏。第四步操作级校验和敏感字段脱敏除了行级数据权限还必须有操作级权限——比如普通员工只能查看、无审批权限Agent 调用审批接口时如果发现 roles 里没有对应审批角色网关直接拒绝。敏感字段如手机号、身份证号、薪资则按字段密级做动态脱敏Agent 返回结果给用户前统一走脱敏中间件。// 示例字段级脱敏配置 SensitiveField(maskRule phone) private String phone;第五步全程审计落库每一条 Agent 请求必须记录用户、Agent、任务、目标 API、参数摘要、返回码、时间戳。这是日后排查“Agent 是不是越权了”的唯一依据。3.4 不同 Agent 形态下的权限继承差异有一种粗放的做法是“所有 Agent 统一走同一个权限模型”但实际项目里我见到的 Agent 形态至少分三种权限继承策略应当各有侧重。助手型 Agent陪人聊天、问答、信息检索权限以“用户视角”为主Agent 只是检索工具继承用户的只读权限即可不能有写操作核心是防止把不该问的数据问出来。流程编排型 Agent执行业务流程如审批、下单、报销权限按“任务发起人 任务定义”双因子决定。任务定义里会声明它需要哪些权限比如报销任务需要“读取费用明细”和“创建报销单”但不能直接“审批自己的报销”这个必须加防冲突规则。自主决策型 Agent无人值守跑批、自动化运维这类 Agent 没有明确单一用户权限应采用 Service Account 最小权限组合单独在权限中台里配置角色不走用户继承。风险较大时还要配人工审批闸口Human-in-the-loop重要操作前先挂起等人确认。4. 权限校验点到底该设在哪五道闸门缺一不可很多团队觉得权限继承方案设计好了就万事大吉结果一上线就被打脸。问题的根源在于Agent 调用企业系统往往要穿过多层链路只要有一层没有权限校验整个防线就形同虚设。我建议至少设置五道闸门。第一道Agent 网关入口校验。Agent 是否可信、Token 是否有效、是否在允许调用时间窗口内。这个校验粒度比较粗主要是拦截非法调用。第二道API 网关鉴权。每个业务 API 在进入服务前必须校验操作者身份和角色这是传统微服务已经具备的需要扩展的是把 Agent Token 解析成与用户 Token 等价的鉴权上下文。第三道业务服务内数据权限校验。在业务逻辑层校验当前用户是否有权限操作这个资源比如“这条工单是不是本部门的”“这个合同是不是自己的”。很多团队只做按钮级权限不做资源级权限Agent 一来就会出问题。第四道数据访问层ORM/SQL自动注入数据权限条件。如前面提到的 SQL 拼装防止“拖库式”查询把全表数据拉出来。第五道AI 语义层拦截。这一道是 Agent 场景特有的——Agent 本身是 LLM 驱动的相同的问题换个说法可能绕过关键词过滤。我建议在 Agent 和业务 API 之间再加一层“意图安全防火墙”用模型判断用户请求是否涉及敏感领域财务数据、他人隐私、口令类信息命中风险则要求用户二次确认或转为人工审批。我遇到过一个实际案例某企业内部 Copilot 接入了工单系统员工直接问“最近公司有哪些人申请了电脑补贴”这个请求其实涉及大量员工隐私。Agent 网关的 RBAC 没拦住因为员工确实有查看工单的权限SQL 层也没拦住因为工单表里确实有补贴字段。最后是靠语义层把“查询他人隐私信息”的意图识别出来才挡住的。这五道闸门缺一道都不行。4.1 权威分析传给 Agent 的 API Key 能否信任关于技巧层面我想多说一句“API Key 信任”的问题。如果你企业内部调用 Agent 服务时还在用全局 API Key那么权限继承根本无从谈起。API Key 是“身份等价物”而不是“权限约束物”。你要确保 Agent 在链条上每一跳都携带用户上下文而不是把底层一个高权限 Key 直接当万能钥匙。实操建议区分“服务器到服务器”的调用和“代理人操作业务对象”的调用前者用服务账号 Key后者必须用委派令牌。API Key 定期轮换至少 90 天一次防止长期有效 Key 泄露造成大范围破坏。在 API 网关配置“来源 IP 白名单”即便 Key 泄露也只能在可信内网环境调用。4.2 审计与追溯没有账本的权限继承就是耍流氓权限系统做得再好如果出事以后查不到是谁用哪个 Agent 做了什么操作那等于没做。企业软件为 Agent 重做的过程里审计体系一定要同步跟上。在实践中我强烈建议把 Agent 操作审计作为独立事件流存储而不是混在普通用户操作日志里。每条 Agent 操作记录建议包含字段说明示例req_id全局唯一请求 ID8f3d2e9a-c1a2-4b67-8f9a-1a2b3c4d5e6fuser_id真实发起人u_10023agent_idAgent 实例agent_5session_id任务会话sess_901action操作类型order.createtarget_resource目标资源order:10089result结果allow / deny / timeoutdata_scope生效的数据权限dept_ids: [d_102, d_103]ts时间戳2025-06-18 10:23:45.123有了这份审计数据当安全团队问“这个 Agent 为什么会看到这条记录时”你能快速定位到用户、任务和权限规则。如果没有那基本只能靠猜。5. 常见问题与排查技巧我在实际项目中踩过的那些坑5.1 权限报错高频问题速查表我整理了一份高频问题速查表覆盖了几个热词里提到的常见报错也补充了 Agent 场景特有的权限问题典型问题可能原因排查建议Agent 返回 403Token 未包含对应角色或委派凭证过期检查 AgentTask Token 的 exp 和 role_refsSQL 无查询结果数据权限条件拼错过滤条件过严先不带数据权限查一遍确认数据存在再逐步加条件数据泄露风险Agent 查询未注入数据权限条件检查 ORM 拦截器是否生效确认是否走了统一数据权限组件“你没有权限访问内存文件/提问材料”常见于 Agent 读取附加文件时文件 ACL 不允许服务账号访问单独给 Agent 目录授权但不要给整个盘符的权限“需要管理员权限才能删除/安装”Agent 自动化操作中需要提权提权策略配置不当区分安装类操作和业务操作安装类操作保持人工干预“对表空间无权限”数据库账号权限不足给独立数据库账号赋最小必要的 CRUD 权限别都走管理员账号Agent 越权读取到其他部门数据数据域继承规则未生效重点排查 DataScope 的注入位置测试跨部门和同部门两个用例审计日志中出现未知 Agent 调用服务账号被多个 Agent 共享紧急旋转服务账号 Key审计每个 Agent 的入网 IP 和调用路径5.2 权限继承粒度多细才合适我推荐“够用就好”原则有些团队一上来就追求“字段级动态权限”——每个字段每个角色每个加密策略全上结果越搞越复杂Agent 性能直线下降最后大家干脆绕开权限系统直接连数据库。这其实是本末倒置。我个人的实践经验是权限继承先粗后细按风险等级决定粒度。非敏感业务如公告、产品资料可以按部门级 Read 权限粗放处理敏感业务如财务、薪酬、客户联系人再启用字段级和 SQL 级细粒度控制。你要知道权限越细链路越长调试维护成本是指数级上升。对一个内部 Wiki Agent你没必要把每一篇文章的阅读记录都单独做 ACL但对一个能访问 HR 系统的 Agent就必须逐字段、逐操作严格限制。5.3 灰度切换老权限系统与新继承模型并行期怎么过渡改造权限继承模型是一件高风险的事最稳妥的策略是灰度切换。我的建议分四步走影子模式新权限继承逻辑上线但只记录判定结果不真正拦截或放行。运行两周对比新旧逻辑的判定差异找出被错误拦截或错误放行的用例。只读试点选一个低风险部门或系统启用新的权限判定但不允许写操作。让真实用户使用 Agent 服务观察行为是否符合预期。全量只读在所有只读场景放开新权限继承写操作继续走双审批流程旧逻辑 人工确认。全量切换确认无重大差异后开启写操作的新权限继承并保留审计日志至少 180 天以排查潜在问题。5.4 最容易被忽略的最小权限原则Agent 的“可回退”能力最后提醒一个特别容易被忽略的点Agent 权限的最小化不只是“能给只读就不给写”还要考虑回退能力。比如一个自动化运维 Agent 执行了批量更新如果出问题了能不能回滚权限模型里是不是包含了回滚操作的授权我见过一个实际事故Agent 批量更新了客户状态后来发现规则有误但因为权限模型里“写操作”被拆成了多个子权限回滚所需的另一个写权限 Agent 根本没拿到结果只能人工跑脚本修复耽误了一整晚。所以设计权限继承时务必把“正向操作”和“反向恢复”都纳入同一套职责模型里哪怕回滚操作平时很少触发也必须提前赋予对应的最小权限。6. 一点个人经验总结给正在做 Agent 化的团队一个比较直接的叮嘱权限继承这件事不要在项目后期才补越早做越好。技术原理并不复杂难的是企业系统里存量权限数据太乱角色权限矩阵散落在各个系统里口径还不一致。我见过不少团队花了大半年做完 Agent 功能最后却因为权限没法继承整个方案被安全部门打回重做。我自己在一个客户现场摸索出来的实用流程是先用一个月梳理组织、角色、数据权限的映射关系形成一张“权限地图”再花一个月搭好权限继承的中间层之后 Agent 功能开发都是在这个中间层上去迭代的。这样虽然前期慢了一点但后期几乎不会再出现“Agent 能说话却动不了手”或者“能动的手太大”这种尴尬局面。如果这篇文章能帮你少踩几个大坑那就值了。后面我还会继续写 Agent 场景下知识库权限到人、Agent 操作审计体系、LLM 语义安全网关等系列内容这些都是企业内部落地时绕不开的硬仗。