智能体一旦能够访问企业系统、调用工具并推进流程，权限治理就不能再沿用“模型是否可信”的单一判断。真正需要控制的是智能体可以代表谁、访问什么、执行哪些动作，以及异常发生后能否及时暂停和追责。权限分级的核心，不是给智能体贴上“可信”或“不可信”的标签，而是把任务风险拆解为可配置、可审计的行动边界。
先按行动风险分级
最基础的一层是只读权限，允许智能体检索知识、查询业务数据或生成分析，但不能修改系统状态。第二层是建议权限，智能体可以生成工单、变更方案、客户回复或审批意见，但必须由人确认后执行。第三层是受限执行权限，允许其完成低风险、可撤回的写入操作，并限定数据范围、时间窗口和调用工具。最高风险层涉及删除数据、发送外部承诺、审批付款、修改生产配置等动作，原则上应设置人工确认、双人复核或明确的业务阈值。
这种分级不能只按工具名称判断。同一个工具在不同任务中的风险可能不同：查询客户资料与修改客户资料不是同一级别，生成退款建议与实际退款也不应共享权限。权限设计应同时考虑数据敏感度、操作不可逆性、影响范围和责任归属。
建立动态而非永久授权
每个智能体、工具和服务都应拥有可识别身份，避免多个任务共用无法追溯的高权限账号。授权时应绑定具体任务、数据范围、调用对象和有效时间；任务结束后自动收回，而不是长期保留。MCP可以规范智能体与工具、数据源之间的交互，A2A可以支持智能体协作，但协议只解决连接方式，不能替代身份认证、授权和责任划分。
跨智能体调用尤其需要默认不信任。远程智能体返回结构化结果，并不代表结果可靠，更不意味着它拥有继续执行的权限。调用链应记录发起者、任务目标、工具操作、返回结果、人工介入和最终状态；对异常重试、越权请求和敏感数据流动设置拦截机制。
权限治理的验收标准也不应只是“能否完成任务”，还要看越权是否可阻断、行动是否可解释、异常时能否暂停、日志是否足以复盘。企业应从边界清晰且错误可撤回的场景开始，逐步开放权限，而不是因为演示效果良好就直接授予智能体完整执行权。只有权限最小化、风险分层和运行审计同时成立，智能体才具备进入生产环境的基础。