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。