1. Agent 重做企业软件卡在权限继承这道坎上最近圈子里的热度很明确AI Agent 不是概念而是已经在动手重构企业软件了。各路团队都在用 Agent 重写业务流程、自动化操作、决策支持但所有人都绕不开同一个问题——权限怎么继承。这个问题的核心矛盾在于传统权限模型是为“人操作软件”设计的用户登录系统系统按角色授权操作记录直接归属到人而 Agent 场景下操作者是 Agent它代表用户去执行任务但它又不是人。权限该挂在 Agent 身上还是用户身上Agent 调用外部工具时它拥有谁的权限如果 Agent 执行的链条里涉及多个系统、多个角色权限怎么传递才不会越权我先抛出结论权限继承不是简单的把用户权限复制给 Agent而是要构建一套围绕身份代理Identity Delegation 、最小权限Least Privilege 和上下文隔离Context Isolation 的权限传递模型。这背后牵扯到身份识别、令牌传播、资源隔离、审计追溯等一系列问题。别急下面我逐个拆开讲。如果你正在做 Agent 项目或者正准备把 Agent 引入到企业软件体系里这篇文章会给你一套可落地的权限继承设计思路和实现参考。不需要你预先精通安全架构但如果你懂 RBAC、OAuth、ABAC 的基础概念理解起来会更快。2. Agent 权限继承的本质是身份和操作链路的重新建模2.1 传统权限模型为什么在 Agent 场景下失效传统企业软件几乎清一色走 RBACRole-Based Access Control 模型给你一个角色角色绑定一堆权限你登录后就能看你能看的东西、做你能做的事。这套模型默认的前提是操作者就是那个登录的人系统可以通过账号体系把每一次操作追溯到具体自然人。Agent 场景把这个前提直接干碎了。Agent 不是人没有身份证没有静态角色它可能是长期运行的自动化进程也可能是用户对话式触发的临时任务甚至可能是多个 Agent 协作组成的一个执行链。你再按“一个账号 一个角色 一组固定权限”来做继承就会发现Agent 的诉求是动态的它执行一次任务可能需要临时跨系统调数据任务结束就不需要这些权限了Agent 的权限应该是用户授权的子集而不是用户权限的完整拷贝——没人希望 Agent 拿着管理员的全部权限满系统乱跑Agent 可能在一个执行链里切换不同的“身份视角”访问不同系统的数据时需要遵循不同系统的权限规则。我在实际项目中见过太多翻车案例团队做了一个很聪明的 Agent直接让它接管用户会话用同一个令牌调所有内部 API结果 Agent 一个误操作把生产环境配置改了——因为令牌是管理员的权限全量继承瞬间炸掉。这种事本质上就是没搞清楚 Agent 权限继承的边界。2.2 权限继承三要素身份、范围、时效要做对权限继承先抓住三个核心维度第一身份Identity 。Agent 执行任务时必须明确它代表谁这个“谁”是发起任务的用户、还是某个系统服务账号。身份决定了权限的上限。你不能让 Agent 干用户没权限干的事这是底线。第二范围Scope 。Agent 一次任务能访问的资源边界。范围是对身份的细化比如市场部门的用户发起的 Agent 任务只能拿市场部的数据不能碰财务数据哪怕这个用户在系统里被赋予了超管角色Agent 任务依然要按最小范围收敛。第三时效Temporal Validity 。Agent 任务是一次性的还是长期后台运行的权限的有效期多久期限一到立即回收。传统权限模型里你开通一个账号权限可能一年都不清一次Agent 场景绝不允许这样——Agent 任务的临时性决定了权限必须有时效约束。这三个要素合起来才构建出 Agent 权限继承的完整轮廓。身份保底范围收敛时效限制。少一个都是隐患。2.3 权限继承的三种模式你应该按场景选结合我接触过的真实项目业界现在大致形成了三种 Agent 权限继承模式模式一完全模拟Full Impersonation Agent 直接代表用户以用户身份调用系统。优点是实现简单兼容性好——因为所有系统都认用户身份Agent 只需要拿到用户的令牌就行缺点是风险大用户权限多大 Agent 权限就多大一旦 Agent 被诱导执行恶意操作提示词注入攻击后果难以预估。模式二受限代理Scoped Delegation Agent 代表用户但权限通过策略引擎动态裁剪。用户还是授权主体但系统会给 Agent 单独下发一个受限令牌这个令牌的权限范围是在用户权限基础上经过策略过滤后的子集。比如用户权限可以读全公司的数据但策略引擎规定这个 Agent 任务只能读市场部门的数据那么下发给 Agent 的令牌就只带市场部门的数据读权限。风险可控实现也不复杂是目前推荐度最高的方式。模式三独立身份 权限映射Independent Identity Permission Mapping Agent 拥有自己的独立身份不直接继承任何用户权限而是通过权限映射表来分配固定权限。适合长期运行、无需代表特定用户的后台 Agent。风险最低但灵活度也最低不适合对话式、动态任务的场景。从架构角度讲这三个模式不是互斥的一个成熟的 Agent 平台应该同时支持三种模式按任务类型动态选择。交互式任务走受限代理后台任务走独立身份映射。3. 权限继承分层的架构设计从用户到 Agent 到工具3.1 用户层到 Agent 层的继承令牌传递与降权企业软件里最关键的继承链路就是用户发起任务后Agent 如何安全地“继承”用户身份。我的建议是采用“双令牌”架构用户认证完成后得到用户令牌User Token 当用户发起一个 Agent 任务时系统生成一个新的 Agent 令牌Agent Token 。Agent 令牌有两个特征首先它关联到用户令牌所以审计时能追溯到“这个 Agent 代表谁”其次它的权限范围是用户令牌经过策略裁剪后的子集比如去掉删除类操作、去掉敏感数据表的读权限、限制访问 IP 范围等。这个降权过程不是随手写的需要一套策略引擎来定义。策略引擎的输入是用户权限、任务上下文、资源属性输出是一个受限的权限策略。我常用 JSON 来描述这类策略简单、可读、好调试。比如{ identity: user-12345, agent: agent-8899, expires_at: 2026-12-31T23:59:59Z, permissions: [ { resource: sales.database, actions: [select, insert], conditions: { row_level: department market, time_window: 09:00-18:00 } }, { resource: internal.api, actions: [invoke], conditions: { rate_limit: 100/min } } ] }这个 JSON 里最关键的是permissions数组——它不是用户权限全集而是裁剪后的子集。row_level甚至在数据库层面加了行级过滤Agent 就算拿到了数据库访问能力能读到的行也是受控的。这种降权设计能应对大多数数据泄露风险。3.2 Agent 层到工具层的继承按需授权不用全量Agent 真正要干活光有身份没用还得调用各种工具内部 API、数据库、消息队列、第三方服务……工具层的权限继承我强烈推荐走“按需授权”模式。什么叫按需授权就是 Agent 每次要调用某个工具时权限控制系统实时检查这次调用是否在其策略范围内逐一放行。它和传统的“账号开通后就一直能用”完全不同更像是每一次都问一句“你真有权限做这件事吗”如果你用的是 OpenAI 的 Function Calling 或者类似的 Agent 框架工具定义里就应该加权限元数据。比如{ name: delete_order, description: Delete an order by ID, permission_level: admin_only, requires_approval: true }执行引擎读到requires_approval: true时不会直接调这个工具而是先挂起等授权人确认后继续。这个设计能规避很多“Agent 自作主张”的坑。3.3 多 Agent 协作时的权限传播逐级衰减复杂业务流程往往不是单个 Agent 干的而是主 Agent 拆解任务分发到多个子 Agent 分别执行。权限逐级传播时每传一级都应该做一次衰减。我的经验法则是子 Agent 的权限上限是母 Agent 权限的子集绝不能等于更不能超过。母 Agent 有销售数据的读写权限那正常任务的子 Agent 只能拿到读权限任务真的需要写权限时必须触发审批流单独申请。类似于“幂等权限”的概念每个子 Agent 的令牌里都带上父级令牌的 ID形成一条完整的授权链。等审计的时候你可以顺着这条链看用户 → 主 Agent → 数据抓取子 Agent → 数据库 JDBC 连接。任何一环都逃不掉。4. 实操落地从 RBAC 到 ABAC 的改造路线4.1 先确认你到底有哪一层权限模型如果你正在重构一个已有的企业软件先别急着写代码确认你现在有什么。三种常见情况第一种只有简单的账号密码 一个 is_admin 标记没有细粒度权限。这种情况你要先补基础 RBAC建好角色和权限表再考虑 Agent 接入。第二种有 RBAC角色权限划分清晰。这是最普遍的可以直接进入 ABAC 改造阶段。第三种已有 ABAC基于属性的访问控制 能按用户属性、资源属性、环境条件动态判定。这种底子最好你只需要扩展属性来源加 Agent ID、任务类型接入成本最小。4.2 RBAC 向 ABAC 扩展的最小改造方案RBAC 的痛点是静态角色定死无法表达“市场部用户在日常工作时间能读本部门销售数据但深夜不行”这种动态规则。ABAC 则是把判断条件从“角色”拓展成“属性组合”灵活得多。最小改造方案核心是加一张策略表字段名类型说明policy_idvarchar策略唯一标识effectenum允许allow 或拒绝deny subject_attrjson主体属性匹配规则如用户部门、Agent IDresource_attrjson资源属性匹配规则如表名、API 路径actionenum读、写、执行conditionjson附加条件如时间窗口、IP 段、行级过滤判断逻辑从“查角色-查权限”变成“查策略-算匹配”。每次访问请求进来带上主体属性和资源属性策略引擎匹配所有 policy按deny overrides allow的规则得出最终结论。注意一点任何策略都不匹配时默认拒绝这是安全底线。RBAC 的角色可以保留作为属性之一参与判定。比如你依然维护 user_role但判定时不再只看角色而是看“角色 部门 Agent 标记 时间”的组合。老系统切换时阻力最小原有的权限表、角色表不删除只是新增强制访问控制层拦截在 API 网关位置。4.3 权限策略引擎选型与实现细节策略引擎选择上用过不少开源方案后我的偏好很明确AWS 的 Cedar 和 Open Policy AgentOPA 是当前两个最值得关注的方向。Cedar 语法简洁适合纯授权判定OPA 用 Rego 语言写规则能力强但学习曲线陡。如果你不想引入外部依赖自己写一个轻量策略引擎也不难。核心就是三个模块策略解析器加载 JSON/YAML 策略文件编译成内存中的规则树请求上下文每次调用时封装主体、资源、动作、环境条件评估器按优先顺序匹配规则输出 allow 或 deny。我用简化版逻辑给个伪码思路def evaluate(subject, resource, action, context): # subject 包含 user_id, agent_id, department, role # resource 包含 resource_type, resource_owner, sensitivity_level # context 包含 current_time, ip, request_id matched_policies [ p for p in load_policies() if match_subject(p.subject_attr, subject) and match_resource(p.resource_attr, resource) and p.action in (action, *) ] # 先检查 deny再检查 allow if any(p.effect deny for p in matched_policies): return deny allowed [p for p in matched_policies if p.effect allow] if allowed and all(check_condition(p.condition, context) for p in allowed): return allow return deny # 默认拒绝这套逻辑我已经在多套系统里验证过简单能跑性能也不差——策略表加载到内存后单次判定在微秒级。复杂点在于条件匹配的粒度比如行级过滤要拼到 SQL 里、接口级限流要联动网关这部分要跟具体基础设施结合。4.4 令牌和会话的权限统一分发链路设计系统里有了策略引擎接下来是令牌分发链路。整体流程我是这样设计的用户登录拿到用户会话令牌里面存用户 ID、角色、部门信息用户发起 Agent 任务Agent 平台调用策略引擎传入任务上下文任务类型、涉及资源、执行时长预估策略引擎返回一份受限权限策略JWT 格式里面明确列出允许的资源和动作以及过期时间Agent 平台用这份受限 JWT 去调用内部 APIAPI 网关解析 JWT 后向策略引擎做强校验每个请求都验任务结束或超时Agent 平台吊销 JWT权限即刻失效。这份受限 JWT 的标准结构建议{ iss: agent-platform, sub: agent-8899, on_behalf_of: user-12345, scopes: [sales:read, internal-api:invoke], resources: [sales.db, PM系统], exp: 1735689599, parent_token_id: tok_abcdef123456 }on_behalf_of与parent_token_id这两字段一个对人确认、一个对链确认协同支撑审计能力——任何一个环节出问题能立刻定位到具体的用户、具体的 Agent、具体的一次任务。5. 常用权限模型与继承方案对比按场景选下面给一份我整理的对照表方便团队选型时快速做判断模型适合场景优点缺点与 Agent 配合度RBAC传统企业管理后台模型成熟、开发快静态角色无法表达动态规则低需要额外降权处理ABAC多租户、复杂组织架构动态策略、灵活度高策略管理成本高、需要策略引擎高天然适配 Agent 动态任务ReBAC关系型社交网络、Doc 协作天然表达资源归属关系实现复杂图数据库依赖中高适合文档型 Agent基于令牌的客户授权开放平台、API 网关粒度细、易审计令牌生命周期管理繁琐高按需授权容易实现RBAC 不是不能用关键看你有没有额外加一层“受限代理”的逻辑。ABAC 是目前接入 Agent 最平滑的方案。如果组织里已经全是云原生的现代化架构K8s、服务网格、微服务那 ABAC 服务间 mTLS 是更扎实的组合。代码层面的简化实现Cedar 策略可以这样写permit ( principal is Agent, action in [Action::read, Action::write], resource is Document ) when { principal.on_behalf_of resource.owner };这条策略表达了“Agent 只有代表资源所有者时才能读写该资源”。如果用户没权限Agent 也不可能有。这一句就是整个权限继承设计的灵魂。6. 踩坑实录权限继承里最常见的十个问题项目实践下来团队最容易栽跟头的点集中在这几个地方问题一Agent 退出后令牌没回收Agent 任务执行完很多人忘了吊销令牌。令牌一直有效相当于给攻击者留了个后门。解决方案是在 Agent 平台加定时扫描发现任务结束后还在使用的旧令牌强制下线。问题二提示词注入攻击导致越权这是最头疼的安全问题。Agent 在读取外部不可信内容时可能被恶意指示执行一些操作。权限降级能有效缓解但降级的粒度要够细。我的经验是凡是 Agent 读取了外部网页内容的场景默认把所有写操作的标成高危需要人工二次确认。问题三子任务权限泄漏主 Agent 子任务 A 需要调用数据库子任务 B 不需要但由于共用了同一个 Agent 令牌B 也能顺手碰数据库。解决办法是严格实施一任务一令牌不做共享令牌。问题四权限审计日志缺失权限继承链条拉长了出问题找人却找不到缺的就是审计日志。务必做到用户 ID、Agent ID、任务 ID、资源 ID、动作、时间、策略 ID 七个字段全量落库。问题五跨系统权限传播断链一个 Agent 涉及内部系统 A、B、C系统各自维护独立权限体系时令牌传入 B 就说不清了。这里建议在 B、C 系统面前统一用 OAuth2 和 JWT 模式来识别 Agent 身份尽量别使用系统各自的 Session。问题六降权过度导致任务失败权限裁剪太狠Agent 正常任务做不下去。此时不能随意放宽策略而是让 Agent 学会“申请权限”——遇到权限不足时明确提出需要什么资源的什么权限由授权方审批后下发。这种设计符合人类工作方式下属能干的直接干干不了的请示领导。问题七时间窗口和时区问题不少策略里带了时间条件但跨时区任务容易误判。统一用 UTC 存储和比较或者直接和用户本地时区对齐两者都可以前提是别混着用。问题八策略缓存导致旧权限还在生效策略引擎加了缓存后旧策略未失效前新策略不生效。权限这种数据建议缓存时间短一点或者干脆做强一致。数据量可接受时不建议给权限策略加缓存。问题九子 Agent 里的 API Key 硬编码Agent 日志里打印出 token 这类的事见多了这是硬伤。所有密钥统一走 Secret Manager 分发日志里做字段脱敏。问题十走审批流程时的阻塞高危操作需要人工审批但如果审批流程设计成邮件等待Agent 任务能卡一天。实践上要加超时机制等待时间超过阈值自动降级为只读模式或直接放弃任务并通知用户。7. 实战案例给一个数据分析 Agent 配置完整的权限继承理论说完来一个我在实际项目里做过的完整案例。背景是一个金融企业的数据分析 Agent核心需求是业务人员向 Agent 提需求Agent 自动查询数据库、生成报表。7.1 需求背景与权限边界定义业务人员的原始权限是能读本部门的业务数据表不能读取其他部门的数据不能删除任何记录只能在 9:00-20:00 之间访问数据库。那么 Agent 的权限边界我定义为身份模拟发起任务的业务人员数据范围只读该业务人员所在部门的数据表操作类型只允许 SELECT不允许 INSERT/UPDATE/DELETE时间限制跟随业务人员的访问时间窗口行级限制SQL 查询自动注入部门过滤条件。这个案例的敏感点在于数据库里有全公司的数据Agent 的执行能力又强如果权限没收敛好一次“误操作”就能把全量数据拖出来。7.2 权限策略的具体配置我给这个 Agent 设计的策略文件核心如下{ agent_name: data-analyst-agent, on_behalf_of_user: true, permissions: [ { resource: financial_db.*, actions: [select], row_filter: department_id ${user.department_id} } ], denied: [ { resource: financial_db.*, actions: [insert, update, delete] } ], time_restriction: [09:00-20:00] }row_filter是关键它在所有查询语句后面强制追加WHERE department_id 用户的部门 ID。不管 Agent 的模型推理出什么 SQL到了数据库执行层都会带上这个过滤条件。就算 Agent 被诱导生成SELECT * FROM users实际执行的是SELECT * FROM users WHERE department_id 123。7.3 继承链路中每一步的校验记录在这个链路里我特别强调审计。每次 Agent 执行数据库查询都会记录用户 ID谁提交的需求Agent 任务 ID哪一次任务会话令牌 ID哪个会话派生的SQL 原文Agent 生成的 SQL执行后的 SQL加了行级过滤的真实 SQL目标库表及影响行数执行结果状态成功/失败/权限拦截这套审计日志上线后曾在一个月内抓到六次 Agent 生成的 SQL 试图跨部门查询的情况——全部被行级过滤拦截。之后我们把相同案例沉淀成了测试集每次更新 Agent 模型都要跑一遍确保没有回归。如果你做的是 Agent 平台或为 Agent 开发框架这种“权限测试集 回归测试机制”是最直接的安全防线。7.4 Agent 任务里的人工确认节点设计Agent 自动查询不是所有操作都放行高危操作的要加人工确认节点。我的做法是在 Agent 任务状态机里增加pending_approval状态普通 SELECT自动放行聚合查询COUNT/SUM/AVG 且涉及多表自动放行但要杀掉超过 30 秒的长查询跨部门查询需要业务人员手动确认任何写操作一律拒绝没有审批流程查询返回行数超过设定阈值自动阻断提示用户缩小范围。Agent 执行链路会等待人工确认结果确认后继续拒绝则终止任务。这套机制既能保持自动化效率又给风险操作留了一道闸门。8. 行业趋势Agent 权限管理正在成为一个独立的基础设施8.1 企业级工具已经开始内建权限继承机制我关注到现在主流的 Agent 开发框架和企业 SaaS 都在原生支持 Agent 的权限继承逻辑。比如企业级项目里经常用的低代码 Agent 平台会在 Agent 配置界面里直接提供“数据源权限映射”模块管理员选哪个数据源、限制 Agent 能读哪些表和字段、按什么规则过滤行点击配置即可。底层实现就是我前面说的“受限代理 策略引擎”的组合。同时AI 编程助手类产品也在做 Agent 权限的硬化——当 AI 生成代码或命令时IDE 插件会实时显示“即将调用哪些受保护 API、需要以什么权限运行”用户确认后命令才真正执行。这和我在权限工具层设计的按需授权思路完全一致。这说明一个问题权限继承不再是你自己在应用层写得稀碎的逻辑而正在被平台化、基础设施化。作为开发者和架构师提前理解这套体系比到时候被框架推着走要舒服得多。8.2 权限继承设计走向标准化从 OAuth2 到 Agent 扩展OAuth2 的授权码模式已经解决了“用户授权第三方应用访问资源”的问题Agent 场景本质上就是“用户授权 AI 助手访问资源”。目前业界不少人在讨论 OAuth2 的 Agent 扩展比如用 Token Exchange 模式把用户令牌换成 Agent 受限令牌再用 JWT 携带授权链信息。这套思路如果能跑通Agent 在不同系统之间的权限继承就会有一个统一标准不再每个项目各自造轮子。我个人的判断未来 1-2 年会看到更多企业将 Agent 权限模块从大单体 App 里拆出来形成专门的权限代理服务统一处理 Agent 的身份映射、策略裁剪、令牌分发和审计追踪。现在如果你从零做 Agent 项目建议按照这个方向设计后面演进成本会大大降低。8.3 可控的 Agent才是好 Agent圈子里说“Agent 重做企业软件”这个趋势没问题但重做的前提是把安全和权限问题解决干净。每个 Agent 的每个动作都应当在权限边界内权限永远继承自自然人且只能“小于等于”自然人的权限。可控才敢放权。等到权限继承这套体系成熟了Agent 才能在企业软件里走得更远。9. 最后分享一点落地心得从最小闭环开始如果让我给正在做相关项目的人一条最实际的建议那就是别一上来就想着把全部权限模型一次性重构完先找最小闭环跑通。找一个安全的业务场景比如纯只读的数据查询 Agent 搭好“用户令牌 → 策略引擎裁剪 → Agent 受限令牌 → API/数据库执行”的最小链路跑上两周摸清边界在哪里、哪里容易出问题再逐步扩展到写操作、跨系统调用、多 Agent 协作场景。权限这东西不出事的时候没人关注出事就是大事渐进式扩展远比一步到位稳妥。我在第一次搭建 Agent 权限继承链路时最大的教训是过度设计。一开始把 ABAC、ReBAC、服务网格全叠上去反而各层之间互相干扰一查问题就进迷宫。后来压回最小模型一层一层加每一步都能定位这种踩坑节奏才是稳妥的落地方式。