
很多人一谈 Agent 安全就会走向两个极端。一端是过度乐观模型很强给它权限它会自己判断。另一端是过度保守Agent 很危险最好什么都别让它做。这两个判断都不够工程化。生产级 Agent 的目标不是让它完全自由也不是把它关成只能聊天。而是让它在明确边界内行动。该读的能读。 该写的能写。 高风险动作要审批。 生产资源要隔离。 所有关键动作可审计。 失败以后能回滚或补偿。这就是权限、沙箱与人类监督要解决的问题。一、安全不是“不让它做事”如果一个 Agent 只能回答问题风险当然低但价值也有限。真正有价值的 Agent一定会开始行动修改文件 运行命令 访问数据库 调用内部 API 创建工单 发消息 发起退款 触发部署这些动作风险不同不能一刀切读 README 和删除生产数据不应该在同一套权限里。运行单元测试和执行部署也不应该被同样看待。所以第一步不是问给不给 Agent 权限而是问这类动作属于哪一级风险 需要什么边界 需要谁确认 执行后如何留痕二、五级权限模型我建议先用五级模型做基础分层。Level 0: Read-only Level 1: Write workspace Level 2: Run commands Level 3: Network / external services Level 4: Production / irreversible actionsLevel 0 是只读。适合新项目第一天接入读文件 查文档 分析日志 总结结构 审查 diffLevel 1 是工作区写入。允许修改本地文件但不能执行高风险命令。适合改代码 补文档 生成测试 更新配置样例Level 2 是命令执行。允许跑测试、构建、格式化、脚本。这里要开始引入 allowlist。比如pnpm test pnpm typecheck pytest go test但不应该默认允许rm -rf deploy kubectl apply terraform applyLevel 3 是外部服务。包括网络访问、SaaS API、数据库、云资源这里要看凭证来源、最小权限和审计。Level 4 是生产或不可逆动作。比如删除数据 退款 发消息给用户 发布文章 部署生产 修改权限 旋转密钥这一级默认不应该自动执行至少需要人工确认、二次校验和审计记录。三、沙箱解决环境边界权限模型回答的是“能做什么”。沙箱回答的是“在哪里做”。常见沙箱维度包括filesystem sandbox network isolation process isolation container / devcontainer temporary workspace read-only mount command allowlist secret isolation文件系统沙箱限制 Agent 能读写哪些目录网络隔离限制它能访问哪些外部地址。容器隔离限制命令执行的系统影响。临时工作区让 Agent 可以大胆尝试但不会污染主工作区。密钥隔离则避免它误读.env、云凭证、生产 token。沙箱不是为了降低效率沙箱是为了让你敢开放更多能力。没有沙箱你只能给 Agent 很少权限。有了沙箱你可以让它安全地试错。四、审批门不是每一步都问很多工具的审批体验很差。Agent 每跑一个命令都问一次。人类不停点确认。最后大家要么烦了全放开要么不用了。更好的审批策略应该按风险触发。低风险动作可以自动执行。中风险动作可以批量确认。高风险动作必须逐项确认。例如读取文件自动允许 修改工作区文件允许但展示 diff 运行测试自动允许 安装依赖询问 访问外网按域名询问 修改生产资源强制人工审批 删除数据禁止或双人审批审批门要精确太粗会挡住正常工作太松会让风险进生产。五、Human-in-the-loop 与 Human-on-the-loop人类监督也要分层Human-in-the-loop 是人在循环里。Agent 每到关键节点都要等人确认。适合高风险、低频、价值判断强的任务。比如退款审批 生产部署 客户通知 法律合规判断 数据删除Human-on-the-loop 是人在循环上方。Agent 可以持续运行但人类通过仪表盘、告警、审计和抽检监督它。适合低风险、高频、可回滚、可验证的任务。比如每日文档漂移检查 PR 风险摘要 测试失败归因 依赖更新建议 工单分类成熟系统不会只选一种。它会把不同动作路由到不同监督模式。六、敏感动作分类你可以从这张清单开始给动作分类。支付退款、扣款、订阅变更 数据删除、导出、批量修改 发布部署、发文章、发公告 通讯发邮件、发短信、发站内信 权限加管理员、改角色、读密钥 隐私访问用户资料、下载日志 基础设施改 DNS、改云资源、改防火墙这些动作不一定都禁止但必须有更强边界。至少包括明确对象 明确金额或范围 明确原因 明确执行人 明确审批记录 明确回滚或补偿方案如果一个动作不能回滚就不要让 Agent 自动执行如果必须自动执行就要把验证、审计和熔断做得更强。七、审计日志是安全边界的一部分很多团队只记录最终结果这不够。Agent 审计日志至少应该回答谁触发了任务 Agent 看到了哪些上下文 调用了哪些工具 工具输入是什么 工具输出是什么 哪些动作经过审批 谁批准的 是否触发了错误或回滚 最终结果是什么没有这些记录出了问题就只能靠聊天记录和记忆排查这在生产系统里不可接受。审计不是合规装饰它是事故恢复的基础设施。八、实战Checklist给 Agent 接入新任务前先问这十个问题。1. 这个任务最高风险动作是什么 2. 默认能否只读启动 3. 哪些目录可以写 4. 哪些命令自动允许 5. 哪些命令必须审批 6. 是否需要网络访问 7. 是否会接触密钥或隐私数据 8. 是否会产生外部副作用 9. 是否有回滚或补偿方案 10. 审计日志是否能复盘全过程如果答不上来不要先接生产系统。先在沙箱里跑先只读。先生成草稿。先让人确认。九、最后Agent 安全的目标不是让它无能而是让它有边界地有用。没有权限它只能建议。没有边界它会危险。生产级 Agent 需要的是分级权限 隔离环境 审批门 审计日志 人类监督 回滚策略这套系统越清楚Agent 越能进入真实工作流。下一篇我们讲 Harness 的最后一层可观测性。因为看不见 Agent 的循环就无法调试 Agent。参考资料OpenAI Agents SDK: Guardrails and Human ReviewAnthropic Claude Code Permissions DocumentationMartin Fowler: Harness Engineering for Coding Agent UsersAnthropic: Effective Harnesses for Long-Running Agents参考文献第十篇权限、沙箱与人类监督让 Agent 有边界地行动