企业智能体的权限设计，核心不是“给它多少权限”，而是明确它在什么身份、什么任务、什么数据范围和什么业务条件下，可以执行什么动作。若权限只绑定一个智能体账号，模型就可能把“能够访问”误认为“可以处理”，造成越权查询、错误修改或未经审批的业务提交。
权限边界的四个维度
权限至少应同时绑定四类条件。第一是身份：谁发起任务，属于哪个部门和业务区域；第二是数据范围：允许查看哪些客户、订单、合同或财务信息；第三是动作类型：仅可查询，还是可以创建、修改、通知和提交；第四是业务条件：金额、客户等级、订单状态、审批节点等是否满足规则。
因此，“允许销售人员查看订单”并不等于允许其批量修改客户信用状态；“允许智能体生成付款申请”也不等于允许它直接提交付款。权限判断应发生在每次工具调用之前，而不是只在用户登录时完成一次。
用风险等级控制自动化深度
权限边界还应与任务风险绑定。只读查询、数据汇总和异常解释可以不设置审批，但必须保留查询日志；生成订单草稿、退款建议或回复内容，应由人工确认后执行；低风险、低额度且规则稳定的任务，可以按条件自动处理；大额付款、合同变更、核心数据修改等高风险操作，则应强制人工审批，必要时采用多级审批。
审批页面不能只展示“同意”或“拒绝”，还应说明智能体使用了哪些数据、应用了什么规则、准备执行哪些动作，以及可能产生的影响。审批人应能够修改参数、要求补充信息或转交他人。
让权限可审计、可撤销
智能体调用的业务工具应采用受控封装，例如“查询订单详情”“更新客户跟进阶段”“发起费用审批”，而不是直接暴露底层数据库操作。创建、修改和提交类动作应支持预览或试运行，正式执行前保留确认节点；数据库接入原则上以只读查询为主，避免直接写入生产库。
每次任务都应记录原始请求、用户身份、权限判断、数据来源、实际调用的工具、每一步状态、审批记录和最终回写结果。跨系统执行失败时，任务必须进入失败、待处理或人工接管状态，不能把部分完成显示为全部成功。
企业智能体的最小权限原则，最终应落到一个可验证的问题：在当前身份和业务上下文中，它是否只能完成被授权的那一步，并且每个动作都能被追踪、复核、撤销或补偿。只有边界先于能力，自动化才不会演变成不可控的系统授权。