智能体权限怎么配置：最小授权与授权边界清单

把智能体接到营销流程里的风险，大多不是模型坏，而是权限给太宽。配权限有一条主原则：先收后放——从"什么都不给"开始，任务需要什么再加什么，而不是配好再说。本文按文件、网络、外部写入、密钥四类权限分别给最小授权动作，文末附一张审查清单。

先立基准：最小授权意味着什么

最小授权不是"能不给就不给"，而是"这个任务完成所必需的最小范围"。判断标准：它需要读哪些文件才能完成任务；需要联网访问哪些明确网站；需要在完成时写哪些外部系统；哪些动作必须停在草稿状态等人批准。四条各问一遍，权限清单就出来了。

文件权限：限定目录而不是全盘

最危险的配置是"允许访问全部文件"。正确做法是划定工作目录：只允许智能体读写任务相关的文件夹。动作包括：把数据、草稿、发布内容放进专门目录；只读数据源与可写产出目录分开；临时文件用后清理。审查时重点看有没有"全盘读写"这类宽泛授权停留在配置里。

网络权限：白名单而不是放行一切

智能体需要联网时，不直接给"所有网络访问"。做法是明确它要访问哪些域（比如你自己的CMS接口、特定数据源），把网络访问收敛到这些地址。涉及外部API的调用，检查有没有把密钥交给智能体直接使用。临时需要访问新地址时，加一条记录说明用途，而不是永久放行。

外部写入权限：停在草稿等人批准

涉及外部写入（发布文章、发邮件、推送消息、改数据）的智能体，默认只给草稿权限，提交流程里加上人工批准。高影响动作（公开发布、批量外发、删改线上数据）必须在配置里单独列出来，不能和普通写入混在一起。判断批准的规则是：对外可见、不可逆、影响他人的动作，一律停。

密钥权限：隔离而不是内嵌

数据库口令、API token、CMS登录凭据不要写进智能体的指令或对话记录里。密钥应来自环境变量或专用密钥存储，并在配置里设置只读引用。定期轮换密钥，特别是智能体曾配置过外部系统访问之后。审查时检查历史对话和日志里有没有密钥明文残留。

权限审查清单

按季度过一遍这张清单：文件访问是否仍在需要的目录内；网络白名单是否还准确；外部写入是否保持草稿+审批；密钥是否轮换过；离职或更换成员后是否取消了旧授权；权限变更有没有记录在案。有一项不过，先修权限再继续用，别带着旧的宽权限跑新流程。

授权边界冲突时怎么取舍

当任务需要权限超出当前配置时，先问"这个任务必须由智能体完成吗"，再决定是否放权。能用只读方式解决的，不放开写权限；能用草稿完成的，不放开直接发布。每一次放宽权限都记录原因和期限，避免权限只加不减。

多人共用一个Agent时的权限分隔

团队共用的Agent比个人Agent更需要权限边界。建议的做法：按角色建不同的配置实例（运营实例、投放实例、内容实例），每一实例只配它任务所需的那部分权限；敏感操作归到单一负责人，不共享一个宽权限账号。这样即使某人配置出错，影响也限定在他的实例里。

最小授权与审计日志配合

最小授权只是门槛，能不能看清谁在什么时间做了什么同样重要。给Agent的执行过程开启审计记录，特别是文件读写、外部API调用和发布动作。定期抽查审计日志与权限清单是否一致：如果日志显示出比授权更大的操作范围，说明权限配置或工具行为有出入，需重新收敛。