Agent 接入邮件、Shell 和 API 后，权限边界应该怎么设计？

AI Agent 进入真实工作环境后，风险就不只是“回答错了”。

如果一个 Agent 能读邮件、发消息、访问文件系统、执行 shell、创建 cron 任务、调用外部 API，它就已经不是普通聊天机器人，而是一个能改变系统状态的执行单元。能力越强，权限边界越重要。

Agents of Chaos 这项实验很适合给开发者提个醒。研究团队把 6 个自主 Agent 放进一个真实多人环境，给它们邮件、Discord、shell、持久文件系统、cron 和外部 API，让 20 位研究人员在 14 天内进行正常和对抗式交互。结果既出现了越权、误判、资源耗尽，也出现了拒绝注入、拒绝伪造和跨 Agent 安全协作。

这说明 Agent 安全不是一句提示词能解决的事，而是工具权限、身份验证、审批流程和日志审计共同决定的工程问题。

身份权限：不要让 Agent 靠“像不像老板”判断

实验里有一个典型问题：非 owner 用户让 Agent 执行数据请求，Agent 仍然照做；还有攻击者在新频道里伪装成 owner，让 Agent 接受了错误身份。

企业内部也容易遇到类似场景。比如 Agent 接了邮件、IM、工单或 CRM，如果它只根据一句“我是负责人”“这个很紧急”来判断权限，就很容易被绕过。

更稳妥的做法是：身份绑定稳定用户 ID、组织账号或授权 token；不同渠道不要默认继承高权限；涉及数据导出、转发、删除、权限变更时，必须进入二次确认。

Agent 不能因为一个人说自己有权限，就执行高风险动作。

文件系统：默认给沙盒，不给完整项目权限

持久文件系统可以让 Agent 保存上下文、处理文档和修改代码，但它也可能误删、误改或污染项目。

如果 Agent 能直接操作项目根目录、配置文件、密钥文件或部署脚本，一次错误执行就可能影响真实服务。更合理的设计是给 Agent 单独 sandbox：默认只允许读必要目录，写入限制在 drafts、temporary、logs 等低风险路径。涉及配置、生产代码、密钥和构建脚本时，先生成 diff，再由人确认。

文件权限不要按“Agent 很聪明”设计，而要按“Agent 一定可能犯错”设计。

Shell 执行：命令能力必须分级

shell 是 Agent 工具链里最危险的一类能力。它能跑测试、装依赖、处理文件，也能删除数据、泄露环境变量、启动无限循环或修改系统状态。

建议把命令分成三类：

• 低风险：查看目录、读取日志、运行测试、格式检查；
• 中风险：安装依赖、批量修改文件、启动本地服务；
• 高风险：删除文件、改系统配置、访问密钥、执行远程命令、操作生产环境。

低风险可以自动执行；中风险要留记录和回滚方式；高风险必须人工确认。尤其是 rm、权限提升、批量覆盖、输出环境变量、curl | sh 这类命令，不应让 Agent 自动执行。

Cron 和后台任务：必须有停止条件

Agent 能创建 cron 或 watcher 后，问题会变复杂。实验中就出现过消息循环、后台任务和资源消耗相关问题。

任何自动运行任务都应该有运行周期、最大次数、超时机制、状态记录、失败告警和手动停止入口。不能让 Agent 启动一个“持续监控”“一直同步”“不断重试”的任务，却没有 owner 知情，也没有终止条件。

实际工程里，新增、修改、删除 cron / watcher 应该视为高权限操作。临时写运行记录可以自动，但改变调度本身要审批。

外部 API：只给当前任务需要的权限

当 Agent 接入 GitHub、CRM、邮件服务、数据库或第三方 API，风险会从本地扩展到外部系统。

这里最常见的问题是权限过宽。只需要查 issue，却给了写仓库权限；只需要读客户资料，却能批量导出；只需要生成草稿，却能直接对外发送。

API 权限应遵守最小权限原则：read、draft、write、publish 分开；敏感动作审批；调用过程留痕；不同 Agent 不共用高权限 token。Agent 接 API 的目标不是让它什么都能做，而是让它在可控范围内稳定完成任务。

一个实用的四层权限模型

开发 Agent 工具链时，可以按四层设计权限：

第一层是只读：搜索、读文档、看日志、分析代码，不改变系统状态。

第二层是草稿：生成内容、创建临时文件、提出修改建议，但不影响生产对象。

第三层是可回滚执行：在受控目录内改文件、跑测试、提交低风险变更，并保留 diff 和日志。

第四层是高风险动作：对外发布、删除、权限变更、生产操作、调度任务变更、敏感数据导出，必须人工确认。

这样既不会把 Agent 限制成只能聊天，也不会因为追求自动化而放弃安全边界。

真正可靠的 Agent，不是“永远不会出错”的 Agent，而是出错前有边界、执行中有记录、出错后能发现和回滚的 Agent。