企业 Agent 权限映射:角色不是简单复制组织架构
企业 Agent 权限映射:角色不是简单复制组织架构
一、组织架构不等于权限模型
企业 Agent 落地时,权限是第一道门槛。很多系统直接把组织架构同步进来,部门、岗位、上级关系都有了,就以为权限解决了。实际不行。Agent 执行任务时需要访问文档、调用系统、提交审批、读取客户数据,权限粒度比组织架构更复杂。
角色不是简单复制组织架构。权限要围绕任务和数据设计。
某制造业客户部署 Agent 后,销售部门所有人都能"读取客户数据"。但合同细节只有客户经理能看,报价只有总监能批。组织架构说"同部门",权限模型说"不同能力"。直接复制组织架构,Agent 会越权访问合同。
二、先拆资源和动作
flowchart TD A[用户角色] --> B[资源] A --> C[动作] B --> D[文档] B --> E[客户] B --> F[工单] C --> G[读取] C --> H[修改] C --> I[提交]Agent 权限至少要包含资源、动作、范围和条件。比如能读取销售文档,不代表能读取客户合同;能生成回复,不代表能自动发送。
permission_rule: resource: customer_contract action: read scope: owned_accounts condition: approval_required_for_export权限规则越具体,越能控制风险。
对比两种模型:组织架构映射说"销售部可以读客户",资源动作映射说"销售部可以读自己负责的客户,不能导出"。前者一句话就给全部门开了大门,后者按资源、动作、范围三层收窄。粒度差一个数量级,风险差一个数量级。
三、Agent 要继承用户权限
Agent 不应该拥有超出用户的默认权限。用户不能访问的文档,Agent 也不能读;用户不能执行的操作,Agent 也不能代劳。
agent_permission: inherit_user_permissions: true allow_service_permissions: limited require_audit: true只有少数系统级任务可以使用服务权限,而且要审计。
四、敏感动作要二次确认
发送邮件、修改 CRM、创建合同、删除数据、发起付款,这些动作即使用户有权限,也应该在 Agent 执行前确认。
high_risk_actions: - send_external_email - update_customer_record - delete_data - submit_payment确认界面要显示动作、数据来源、影响范围和可回滚性。不能只让用户点一个"确认"。
最后,权限映射要持续同步。员工转岗、离职、项目权限变化后,Agent 的能力也要同步变化。
权限系统还要记录"为什么允许"。当 Agent 读取某份文档或提交某个动作时,审计日志里应该能看到依据:用户角色、资源范围、审批状态和策略版本。企业客户排查权限问题时,不会接受一句"系统判断可以"。
permission_audit: user_id: required agent_id: required policy_version: required decision_reason: required还要处理临时授权。企业常见场景是项目支援、客户交接、临时审批。临时权限必须有过期时间,到期自动撤销,否则 Agent 会长期保留过宽能力。
对于跨系统权限,不能只同步一次。CRM、文档库、工单系统、数据仓库的权限变化频率不同,Agent 网关需要定期校验,并在权限不确定时选择拒绝。
最后,权限错误的用户提示要清楚。告诉用户缺少哪个资源的哪类权限,以及应该找谁申请,比一句"无权限"更能推动任务完成。
实践中的关键洞察
从实际项目经验来看,上述方案的落地效果高度依赖于两个前提条件。第一,团队需要对核心指标达成共识,而不是各说各话。第二,监控和反馈机制必须自动化,手工检查在团队规模扩大后会迅速失效。创业团队最宝贵的资源是创始人的注意力,任何需要人工盯盘的流程本质上都在消耗这个有限资源。
回到根本问题:技术决策最终服务于商业目标。在资源受限的创业阶段,每一次架构选择、每一项工具选型、每一个流程设计,都应该可以追溯到它对用户价值、团队效率或公司生存概率的影响。那些无法回答"这个决定如何帮助我们活得更久或跑得更快"的技术投入,都值得重新审视优先级。
五、总结
企业 Agent 权限映射要围绕资源、动作、范围和条件设计,并默认继承用户权限。
角色不是简单复制组织架构。Agent 能做什么,必须比人类操作更清楚。
核心要点:权限拆成资源、动作、范围、条件四层。Agent 默认继承用户权限,不做加法。敏感动作必须二次确认,不能一键执行。权限变更要实时同步,过期自动回收。