智能体接入企业系统时，最危险的设计不是“模型不够聪明”，而是默认给了它过大的操作权限。最小权限机制的核心，不是限制智能体完成任务，而是让它只在明确的业务边界内，访问完成当前任务所必需的数据和工具，并在高风险动作发生前暂停、确认或转交人工。
最小权限不是只读权限
只读是常见起点，但并不等于完整方案。企业应先为每个智能体建立独立身份，避免直接复用员工账号，再按任务拆分权限：哪些数据可以读取，哪些对象可以创建或修改，哪些动作必须经过审批，哪些操作永远禁止。内部知识检索、工单分类等场景可以从低风险权限开始；涉及付款、合同、客户承诺、账号管理或生产配置的动作，则应设置人工确认，并尽量保留撤销或补救机制。
权限还应绑定任务、用户、部门和项目，而不是一次授权后长期有效。工具调用应采用短时、可审计的授权方式；当任务超出范围、身份不明、数据冲突、工具异常或预算耗尽时，系统应自动停止，而不是让模型自行扩大权限。
把权限控制放在模型之外
模型可以提出调用工具的请求，但不应成为最终的权限裁决者。更稳妥的架构是：模型负责理解任务，业务规则负责判断是否允许，权限系统负责签发具体授权，工具层负责执行和记录。这样即使模型输出错误，也不会直接绕过企业既有的审批和访问控制。
每次调用都应留下可追踪记录，包括任务标识、模型版本、提示词版本、工具名称、参数、返回结果、审批人以及失败和重试过程。对于不可逆操作，日志还要能够回答“谁发起、谁批准、执行了什么、使用了哪些数据”。
上线前不要只验证正常流程。应重点测试工具不可用、接口超时、上下文压缩、并行任务冲突和恶意输入等异常情况。只有当权限边界可验证、异常能安全退出、责任链可复盘时，智能体才适合从试验环境进入业务流程。