07. 工具调用越权应该怎么防护？

简单回答

工具调用越权是指 LLM 在 Agent 场景中调用了超出授权范围的工具或参数——比如只有读权限却试图写入数据库、只能查自己的数据却查了别人的。防护的核心原则是权限最小化 + 外部校验，不能依赖模型自身的"判断"来做权限控制。

详细解释

为什么这是一个突出的问题？

在 Agent 架构中，模型根据用户请求自主决定调用哪个工具、传什么参数。模型本身没有安全意识——它可能因为 Prompt 注入、幻觉、或者对任务的"过度理解"而调用不该调用的工具。如果把工具调用的权限控制交给模型，等于把安全决策交给了一个不可靠的决策者。

典型的越权场景包括：模型调用了未授权的工具（比如系统有 10 个工具但用户只授权了 3 个）；模型传入了超出范围的参数（比如查询别人的用户 ID、访问不属于当前租户的资源）；模型做了危险操作（删除数据、发送邮件、修改配置）；模型通过组合多个安全的工具实现了一个不安全的操作。

防护策略

第一是工具白名单。为每个用户/角色/会话维护一个可用工具列表。模型返回的工具调用请求，第一步就是检查工具名是否在白名单中。不在白名单中的工具调用直接拒绝，不执行。

第二是参数校验。每个工具定义清晰的参数 schema（JSON Schema），包括类型约束、范围约束、枚举值等。模型返回的参数必须通过 schema 校验才能执行。比如 user_id 参数必须等于当前用户的 ID，database 参数只能是白名单中的数据库名。

第三是运行时权限校验。工具执行层要做独立的权限检查，不信任来自模型的任何参数。比如数据库查询工具收到一个 SQL，要检查这个 SQL 是否只涉及当前用户有权访问的表和行——这和传统后端的鉴权逻辑一样。

第四是操作分级。把工具操作按风险等级分类：低风险（查询、读取）可以自动执行，中风险（创建、修改）需要二次确认（让模型先展示操作计划，用户确认后再执行），高风险（删除、支付、发送外部通信）必须人工审批。

第五是审计日志。记录所有工具调用的完整信息：谁调用了什么工具、传了什么参数、返回了什么结果。用于事后追查和异常检测。

第六是沙箱执行。特别是代码执行类工具，必须在沙箱环境中运行，限制网络访问、文件系统访问和系统调用。Docker 容器或 Firecracker 微虚拟机是常见方案。

一个容易被忽视的风险

模型可能通过"合理"的多步操作实现不安全的目标。比如第一步查询用户列表获取其他用户 ID，第二步用这些 ID 查询其他用户的数据。每一步单独看可能都是合法的，但组合起来就是越权。防护方式是在 session 级别维护一个操作上下文，检测跨步骤的权限升级。

面试时可以这样答

工具调用越权的核心问题是：不能让模型做安全决策。模型可能因为 Prompt 注入、幻觉或任务理解偏差调用不该调用的工具。所有权限控制必须在模型之外实现。

具体防护分几层。第一是工具白名单，模型返回的工具调用先检查是否在授权范围内。第二是参数 schema 校验，强制约束参数类型和范围。第三是运行时权限校验，工具执行层独立做鉴权，不信任模型传入的参数。第四是操作分级，低风险自动执行，中风险用户确认，高风险人工审批。

还有一个容易忽视的风险是跨步骤的权限组合——每一步看起来合法，但组合起来实现了越权操作。这需要在 session 级别做上下文关联的安全检测。底线是所有安全校验在业务层做，不依赖模型判断，遵循最小权限原则。

常见追问

1. 工具的参数 schema 怎么定义才能既安全又灵活？
2. 如果模型频繁触发权限拦截导致任务完不成，怎么优化？
3. 多 Agent 协作场景下，Agent 之间的权限隔离怎么做？