Agent 越能做事，越需要安全、授权和沙箱。一个只能回答问题的模型，风险主要是内容是否准确；一个能读文件、改代码、发消息、删数据、部署服务的 Agent，风险就变成了真实系统风险。
因此，Agent 安全不是上线前才补的功能，而是架构设计的一部分。权限、沙箱、人工确认和审计日志，决定了 Agent 能否在真实环境中可靠运行。
Agent 安全要回答的问题
设计 Agent 安全机制时，至少要回答几个问题。
第一，Agent 能访问什么资源？例如哪些文件、哪些数据库、哪些 API、哪些用户数据。
第二，Agent 能执行什么操作？读取、创建、更新、删除、发布、发送、部署，这些操作风险完全不同。
第三，谁授权了这些操作？授权是一次性的，还是长期有效的？是否可以撤销？
第四，哪些操作必须人工确认？确认信息是否足够清晰？用户是否知道将发生什么？
第五，操作是否可审计？出问题后能否知道 Agent 做了什么、为什么做、结果是什么？
最小权限原则
最小权限原则要求 Agent 只获得当前任务需要的权限。
如果用户只是想查询标签列表，Agent 不应该拥有删除标签的权限。如果用户只是想读取文件，Agent 不应该能写入整个文件系统。
最小权限可以从多个层面实现：
- 工具级权限；
- API scope；
- 文件系统沙箱；
- 网络访问白名单；
- 用户身份隔离；
- 临时授权。
权限越细，系统越安全，但使用成本也会上升。因此需要在安全性和体验之间平衡。
沙箱机制
沙箱用于限制 Agent 的运行环境。它可以限制文件读写范围、网络访问、命令执行、环境变量和系统资源。
例如一个代码 Agent 可以被限制只能修改当前工作区文件，不能访问用户 Home 目录。一个内容管理 Agent 可以被限制只能调用查询接口，写入操作需要额外确认。
沙箱的价值不是阻碍 Agent，而是让用户敢于把更重要的任务交给 Agent。
Human-in-the-loop
Human-in-the-loop 指在关键节点让人参与确认。它适合高风险操作，例如：
- 删除数据；
- 发布文章；
- 修改生产配置；
- 发送邮件或消息；
- 执行部署；
- 进行付费操作；
- 授权访问敏感系统。
确认应该具体，而不是简单问“是否继续”。好的确认会展示操作类型、目标资源、关键参数和潜在风险。
授权流程
Agent 授权通常分为两类。
第一类是平台授权，例如 OAuth。用户授权 Agent 访问日历、任务、文档等资源。
第二类是本地执行授权，例如允许 Agent 访问网络、写入某个目录、运行某个命令。
这两类授权经常同时存在。比如一个 Agent 创建飞书待办，既需要飞书 API scope，也需要本地执行环境允许调用 CLI 和访问 keychain。
审计日志
审计日志应该记录关键操作：
- 用户请求；
- Agent 计划；
- 工具名称；
- 调用参数；
- 返回结果；
- 用户确认；
- 时间；
- 操作者身份；
- 错误信息。
没有审计日志，Agent 出错后只能猜原因。生产系统必须能复盘。
常见安全误区
第一个误区是把权限全交给提示词。提示词可以提醒模型不要做危险事，但不能替代系统级权限控制。
第二个误区是默认信任工具参数。模型生成的参数必须校验。
第三个误区是为了方便关闭确认。短期体验变好了，长期风险会大幅增加。
第四个误区是忽略读取权限。读取敏感数据同样有风险，不只是写操作危险。
小结
Agent 安全的目标不是让 Agent 什么都不能做，而是在可控边界内让它放心地做事。最小权限、沙箱、人工确认和审计日志，是 Agent 从演示走向生产的必要条件。