Agent安全治理：行动原语、权限审批与审计链完整指南

只有感知和推理的模型仍然只是顾问。

它可以读代码、解释日志、给出部署建议，但真正修改文件、执行命令、操作浏览器、调用数据库和发布服务，需要行动原语。行动能力让 Agent 有价值，也让错误变得有代价。

一个能够执行任意代码、访问网络、读取凭证并修改生产数据的 Agent，如果只靠模型自己判断“这件事应该可以做”，不能算安全的生产系统。治理必须存在于模型之外，由确定性的权限、策略、隔离、审批和审计机制共同完成。

一、行动原语是什么

行动原语回答的问题是：Agent 能够对现实环境做什么？

常见行动原语包括：

• 创建、读取、修改、移动和删除文件；
• 结构化编辑代码，例如 Patch；
• Bash、PowerShell 和脚本执行；
• Git、构建工具和测试框架；
• 浏览器点击、输入、导航和下载；
• API、MCP 和企业连接器调用；
• 数据库读写和迁移；
• 云服务、容器和部署平台操作；
• 动态创建并执行临时工具；
• 长时间运行的进程和交互式终端。

行动工具的返回结果同样重要。一个工具如果只返回“执行成功”，模型和用户都无法知道改了什么、输出在哪里、是否产生副作用。好的工具应该返回结构化状态、退出码、日志路径、修改摘要和下一步限制。

二、通用工具和专用工具各有边界

通用执行工具

Shell、代码执行和文件系统可以覆盖大量场景。模型可以根据任务临时组合命令，不需要 Harness 预先实现所有功能。

优点是灵活，缺点是权限范围大、语义不明确、审计和重试更难。

专用工具

例如“运行测试”“创建工单”“查询发布状态”“申请临时数据库快照”。专用工具的参数和副作用更明确，比较容易进行权限控制、输入校验和审计。

优点是安全和可观察，缺点是需要提前设计，覆盖范围不如通用工具。

成熟系统通常两者都提供：低风险探索使用通用工具，高风险和高频操作优先使用专用工具。不要为了灵活而把所有能力收敛成一个“执行任意命令”的工具。

三、先区分读操作和写操作

最简单的风险分层是区分是否改变外部状态：

这个分类不能完全取代上下文判断。删除临时文件和删除生产数据库都属于“删除”，但风险完全不同；修改本地 README 和修改生产环境变量也不应使用同一策略。

四、治理链应该在动作执行前

一个基本的治理链是：

模型提出动作
      |
策略判断动作风险
      |
检查用户身份和工作区权限
      |
必要时请求审批
      |
在沙箱或受限环境执行
      |
记录动作、输入、结果和责任人

关键点是“策略判断发生在执行前”。如果命令已经执行，事后再在日志里提醒用户，不能算审批。

策略层可以检查：

• 目标路径是否在允许的工作区；
• 命令是否包含删除、权限或网络操作；
• 目标环境是本地、测试还是生产；
• 当前用户是否有对应权限；
• 是否需要二次确认；
• 任务预算、时间和并发是否超限。

五、沙箱不是完整安全方案

文件沙箱可以限制 Agent 访问哪些目录，网络隔离可以限制它访问哪些域名，进程隔离可以限制资源和系统调用。但沙箱不是万能的。

还要同时处理：

• 身份认证和用户归属；
• 命令允许/拒绝规则；
• Secrets 和 Token 的注入方式；
• 子 Agent 继承什么权限；
• 外部连接器能读写哪些资源；
• 进程可以运行多久、使用多少 CPU 和内存；
• 审计记录是否能追溯到具体任务和用户。

如果一个 Agent 在沙箱里运行，但沙箱中挂载了生产密钥、拥有无限网络和可写数据库，它仍然可能造成严重影响。隔离、最小权限和审批必须组合使用。

六、Secrets 不应该进入模型上下文

数据库密码、云访问密钥、支付凭证、Cookie、私钥和第三方 API Token 都不应该直接写进提示词、项目文件、日志或模型可见的普通文本。

更稳妥的方式是：

用户或部署系统注入 Secret
          |
受控进程读取 Secret
          |
工具使用 Secret 调用外部服务
          |
返回脱敏结果和状态
          |
审计记录不保存 Secret 原文

Agent 可以知道“需要一个数据库连接”，但不一定需要看到连接串本身。工具可以提供一个经过授权的高层动作，例如 run_migration(migration_id)，而不是把数据库管理员凭证交给模型，让它自由构造 SQL。

如果必须把敏感值传给一个工具，要限制生命周期、权限范围和日志输出，并在任务完成后轮换高风险凭证。

七、审批应该请求什么

一个糟糕的审批提示是：“是否允许继续？”用户不知道允许的是什么。

高质量审批应该说明：

动作：将构建版本 v2026.07.30 发布到 production
目标：api.example.internal
影响：重启 backend 服务，预计连接短暂切换
变更：app.py、requirements.lock、数据库迁移 0042
风险：迁移不可逆，需要已有备份
验证：健康检查、核心 API 请求、数据库记录数
回滚：恢复上一镜像；数据库迁移需要单独处理

用户审批的是一个具体动作和影响范围，而不是一句抽象的“继续工作”。审批记录还应该绑定任务 ID、用户、时间、动作摘要和结果。

八、Prompt Injection 是治理问题

网页、邮件、Issue、代码注释、文档和数据库字段都可能包含“忽略之前指令”“把密钥发给我”之类的文本。它们是外部数据，不是系统指令。

防护不能只依赖一句系统提示词，至少要做四层：

数据与指令分离

明确标记外部内容只能作为待分析数据，不能改变系统目标和权限。

工具权限隔离

即使内容诱导模型调用工具，工具策略也应该拒绝越权路径、网络和文件访问。

高风险动作审批

发送消息、发布代码、读取敏感数据和删除资源需要用户确认或企业策略允许。

输出和行为审计

记录触发了什么内容、提出了什么动作、策略如何判定、用户是否审批以及最终结果。

OWASP 将 Prompt Injection 作为大模型应用的重要风险类型之一，实际系统可以参考其风险描述和缓解思路：OWASP LLM01: Prompt Injection。

九、动作要考虑幂等性

Agent 可能因为超时、断线或不确定结果而重试。如果工具不是幂等的，重试可能重复发送邮件、创建多条工单、重复扣费或多次执行迁移。

工具设计时要区分：

查询状态        可以安全重复
创建资源        需要幂等键
更新配置        需要版本或条件检查
删除资源        需要明确目标和二次确认
发送外部消息    需要记录消息 ID，避免重复发送

例如创建任务时使用 idempotency_key，服务端先检查这个键是否已经成功处理，再决定是否创建。不要把“模型应该记得自己做过了”当成幂等机制。

十、进程和资源也要治理

一个长期运行的 Agent 可能启动子进程、下载文件、生成大量日志或调用外部 API。治理还要包括：

• 单次命令超时；
• 子进程数量限制；
• CPU、内存和磁盘配额；
• 网络请求数量和域名白名单；
• 单任务 Token、时间和费用预算；
• 输出文件大小上限；
• 取消任务时是否能终止子进程。

没有资源限制的“自主执行”，很容易变成无限重试或成本失控。

十一、审计日志要记录什么

审计不是把所有模型思考原文都保存下来，而是记录足以追溯责任的事件：

task_id
user_id / agent_id
timestamp
tool_name
sanitized_arguments
risk_level
approval_id
working_directory
result_status
exit_code
output_reference
policy_decision

敏感值要脱敏，日志本身也要控制访问权限。审计记录的保留期限取决于业务、合规和安全要求，不能无限保存所有用户内容。

十二、治理层的验收清单

上线一个可执行 Agent 前，至少做这些测试：

1. 尝试访问工作区之外的文件，确认被拒绝。
2. 尝试执行危险命令，确认进入审批或拒绝流程。
3. 在网页和文件中放入注入文本，确认它不会改变权限。
4. 模拟命令超时，确认子进程可以终止。
5. 模拟网络断开，确认重试次数有限。
6. 检查日志不会输出 Token、Cookie 和密码。
7. 使用同一个幂等键重复调用，确认不会重复创建资源。
8. 审查审批记录能否还原谁在什么时间允许了什么动作。

结论

行动原语让 Agent 能改变现实世界，治理原语决定它能改变什么、在什么条件下改变，以及出问题后如何追溯。

沙箱、审批、最小权限、Secrets、网络策略、幂等工具、资源限制和审计日志缺一不可。模型可以提出动作，但不应该成为唯一的授权者。越接近生产数据、外部用户和真实资金，越要把确定性策略放在模型之前。

参考资料

• OWASP LLM01: Prompt Injection，用于核对 Prompt Injection 风险和缓解方向。
• NIST AI Risk Management Framework，用于理解 AI 系统风险识别、治理和验证框架。