多步骤智能体的权限设计，核心不是“让模型能做什么”，而是限定它在什么条件下、以什么身份、对哪些数据执行哪些动作。企业应把智能体视为业务流程中的受控执行组件，而不是拥有统一系统账号的“数字员工”。权限边界必须覆盖数据访问、工具调用、任务编排、审批触发和结果交付，并且能够被审计、暂停和恢复。
先按任务拆分权限
权限不应按照“智能体”整体授予，而应绑定到具体步骤。计划阶段可以读取流程规则，查询阶段只能访问完成任务所需的数据，执行阶段才允许调用指定工具，交付阶段则限制为生成报告或创建工单。数据库、企业知识库、CRM系统、工单系统、财务软件和内部审批接口应分别建立工具目录，禁止模型自行发现或组合未授权能力。
最小权限原则还应落实到参数层。即使某个工具已获准调用，也要限制查询范围、字段内容和操作类型；模型生成的参数必须经过格式、身份、资源归属和业务规则校验，不能直接作为系统指令执行。
把高风险动作留在控制面
读取信息与改变状态的风险不同。付款、合同处理、账号权限调整和个人信息操作，不宜由智能体无条件完成，更适合采用“智能体建议、系统校验、人工确认”的分级机制。低风险动作可以自动执行，中风险动作需要规则校验，高风险动作必须进入审批节点；任何一步出现异常，都应支持中断，而不是通过重试不断扩大影响。
多步骤流程还要具备超时、失败重试、幂等和错误回滚机制。重试并不等于安全：如果首次操作已经成功，重复执行可能造成重复创建或状态错乱，因此每项写入操作都应明确唯一标识和可恢复状态。
用审计验证边界是否有效
企业至少要记录每一步的身份、输入、输出、工具、参数、耗时、费用、审批结果和失败原因，并区分模型建议与系统实际执行结果。这样才能判断越权来自模型判断、参数构造，还是应用层控制缺失。
权限边界的验收标准也应从“能否完成任务”改为“只能在授权范围内完成任务”。先选择规则清晰、数据结构化、结果容易验收的低风险流程试运行，再逐步扩大工具范围。智能体越接近业务执行层，权限、审批和可观测性就越不能依赖模型自律。