工具越权与数据外泄
本节目标
能从功能、权限、自主性和数据流四个维度审查工具型 Agent；理解工具 schema 不是授权；能设计读写分离、对象级授权、外发控制、幂等和速率限制。
从“聊天”到“行动”的风险跃迁
普通模型输出错误文本，工具型 Agent 可能把错误变成数据库写入、付款、邮件或代码执行。OWASP 所说的 Excessive Agency 可拆成：
- 功能过多：任务只需读取，却能发送、删除或执行任意代码；
- 权限过多：工具使用共享管理员身份，可访问其他用户或租户；
- 自主性过多：高影响动作无需预览、批准或预算限制。
再加一个常被忽略的维度：数据流过宽。工具只要能把敏感上下文传到外部目的地，就可能成为外泄通道。
混淆代理问题
Agent 可能拥有合法服务身份，却替不具备该权限的用户完成动作，这叫“混淆代理（confused deputy）”。例如用户在 Prompt 中提供别人的文件 ID，模型照样调用读取工具。执行器必须根据经过认证的用户、租户、对象和动作做服务器端授权，不能相信模型提供的 user_role="admin"。
认证回答“你是谁”，授权回答“你能对这个对象做什么”，人工审批回答“本次具体高影响动作是否得到知情同意”。三者不能互相替代。
安全工具契约的七层
1. 用途到能力
从任务目的推导最小工具集。读写工具拆开；生产环境默认不暴露调试、shell、任意 HTTP、任意 SQL 等通用能力。
2. 严格输入结构
拒绝未知字段、错误类型、超长值和非标准 JSON；对枚举、范围、格式做校验。结构化 schema 只能保证“长得像正确参数”，仍需业务授权。
3. 身份与对象级授权
工具适配器从可信会话取得用户/租户身份，服务端检查对象归属、scope 和策略。不要让模型选择服务账号或自行构造授权上下文。
授权决策应对每次调用重新计算，并至少覆盖调用者、被代理主体/租户、工作负载身份、动作、对象、目的、环境和当前状态版本。对象 ID 即使通过 schema，也必须在服务端解析到真实租户并校验；来自模型参数、工具描述、MCP Resource/Root 或上一次缓存结果的角色与范围都不能当授权事实。
4. 参数与解释器边界
数据库使用参数化查询；命令避免 shell 拼接；文件路径解析后限制在允许根目录；URL 按 scheme、主机、端口、DNS 解析结果和重定向再次校验。仅做字符串前缀检查通常不足。
5. 目的地与数据出站
目的地默认拒绝，允许列表按环境、用户和租户配置。敏感字段在进入模型和离开边界时都做最小化；检查邮件、Webhook、搜索查询、URL 参数、日志、文件名与 Agent 间消息等隐蔽通道。
6. 副作用控制
写操作先 dry-run/preview，再由可信通道确认；使用幂等键防重复，状态版本防 TOCTOU，速率/金额/数量预算限制爆炸半径。重试只能用于明确可重试且幂等的操作。
7. 输出与审计
工具返回也不可信：先按逐工具 exact output schema、枚举、大小和深度验证，再做字段分类与模型可见投影；原始错误、堆栈、receipt、主体和内部 operation ID 只进入受保护审计。模型结果与审计应从同一内部 outcome 生成，但不能把审计对象整体送进模型。完整 request/result/call binding 用于同一可信流水线内防交换和篡改；它不是跨服务身份认证。
写操作出现 OUTCOME_UNKNOWN 时不要把“失败”解释成“未执行”后自动重做。可信 host 应通过独立状态查询重新授权并核对主体、工具、request hash、effect/producer revision 与 receipt；无证据时继续 unknown，冲突时人工处理。完整离线合同见结果、错误与不可信数据和幂等、超时与可观测性。
审计记录主体、工具、规范化参数摘要、策略决策、对象、结果和关联 run ID，同时最小化敏感数据。MCP Resources、Roots 与能力声明同样不能替代对象级授权；相关协议边界见MCP 授权与安全边界。
数据外泄路径分析
当以下三项同时存在时，应按高优先级评审：
敏感资产 + 攻击者可控内容 + 可达外部通道例如：恶意网页诱导 Agent 把检索到的客户名单编码进搜索 URL。即使没有名为 send_secret 的工具，搜索、图像 URL、DNS、日志或协作 Agent 都可承担外发。数据丢失防护应检查“哪类数据流向哪类目的地”，而不是只匹配几个敏感词。
一个更安全的发送流程
模型提出草稿
→ schema 校验
→ 身份/对象/目的地/数据分类策略
→ 展示规范化收件人、主题、正文摘要
→ 用户在可信 UI 批准
→ 批准绑定参数哈希与状态版本
→ 幂等执行 + 审计 + 限流若任何一步状态改变，旧批准失效。模型不得生成、修改或“解释”为批准令牌。
常见错误与排查
- 有 JSON Schema 就安全：检查是否还有对象级授权、目的地和业务规则。
- 共享服务账号便于开发：检查是否能还原最终用户主体，是否跨租户。
- 工具描述写了“仅内部使用”：描述是提示，不是执行器策略。
- 失败自动重试：检查写操作是否幂等，重试是否造成重复付款/发信。
- 日志越多越安全：日志可能成为新的秘密仓库，应脱敏、限权和设置保留期。
练习与自测
审查同时具有 read_inbox、send_email、fetch_url 与 run_shell 的草稿助手：
- 按用途删除不需要的工具；
- 为保留工具写严格参数与对象授权；
- 找出至少三条外泄通道；
- 为发送动作设计批准、幂等、限流和审计字段；
- 写跨租户、参数替换、未知目的地和重复提交负向测试。
- 能解释工具 schema 与授权的区别。
- 能识别混淆代理和隐蔽外泄通道。
- 能让模型无法自行扩大权限或生成批准。
- 能让高影响工具安全失败并留下最小充分证据。
- 能区分模型可见 tool result 与受保护审计（protected audit），并用显式状态查询处理未知执行结果。
下一步
继续 身份、最小权限与供应链。
参考资料
- OWASP LLM06:2025 Excessive Agency（获取日期：2026-07-21）
- OWASP LLM02:2025 Sensitive Information Disclosure（获取日期：2026-07-21）
- OWASP Top 10 for Agentic Applications（2025 年 12 月发布；获取日期：2026-07-21）