AI 工具调用怎么防止参数越权：服务端重算权限、字段白名单与拒绝验收

客服机器人收到“帮我导出本月订单”后，模型通常会先提出一个工具参数：用户 ID、时间范围、状态和导出格式。真正危险的地方不在 JSON 能不能解析，而在服务端是否把这份参数当成了最终授权结果。只要调用方能把 user_id 换成别人的，或者把查询范围改成全量，工具就可能从“帮用户查数据”变成越权接口。

模型输出只能作为待校验的请求意图。服务端必须根据当前登录身份重新计算资源范围，按字段白名单过滤参数，并让越权、超范围和高风险动作进入明确的拒绝路径。

先画清边界：工具参数不是授权票据

把一次调用拆成三层会更容易排查：模型提出的意图、网关解析出的结构、业务服务最终批准的动作。第一层可能出现幻觉，第二层可能被绕过，只有第三层应该接触数据库或外部系统。

例如工具定义里有 user_id 并不代表它可以由模型自由填写。若当前会话属于租户 t-17 的成员 u-42，服务端应从认证上下文取出这两个值，再查询资源归属。模型可以建议订单号或日期，但不能凭空扩大身份边界。

第一道控制：只接收业务真正需要的字段

工具输入先做结构校验，再做业务授权。结构校验关注类型、长度和格式；授权校验关注“这个人是否能对这个资源做这件事”。两者不要混成一个返回值，否则排查时很难知道是参数格式不对还是权限配置不足。

type ExportOrdersInput struct {
    OrderIDs []string `json:"order_ids"`
    From     string   `json:"from"`
    To       string   `json:"to"`
    Format   string   `json:"format"`
}

func authorizeExport(ctx context.Context, in ExportOrdersInput) (ExportScope, error) {
    principal := PrincipalFromContext(ctx)
    if principal.UserID == "" || principal.TenantID == "" {
        return ExportScope{}, ErrUnauthenticated
    }
    if len(in.OrderIDs) > 100 || in.Format != "csv" {
        return ExportScope{}, ErrPolicyDenied
    }
    scope := ExportScope{UserID: principal.UserID, TenantID: principal.TenantID}
    scope.OrderIDs = ordersOwnedBy(scope, in.OrderIDs)
    if len(scope.OrderIDs) != len(in.OrderIDs) {
        return ExportScope{}, ErrResourceDenied
    }
    return scope, nil
}

示例里刻意没有从 in 读取用户和租户。即使模型把额外字段塞进 JSON，解码器也不应让它影响授权；生产代码还应对未知字段采取明确策略，最好在边界层拒绝并记录字段名。

第二道控制：服务端重算资源范围和高风险动作

“查询我的订单”与“导出全部订单”不是同一个权限。服务端需要同时判断当前主体、资源归属、动作类型和范围上限。对导出、删除、发信、改配置这类有副作用的工具，建议增加一次显式确认或转入人工审批，不要因为模型给出了完整参数就直接自动放行。

权限判断应靠近真正执行动作的服务，而不是只放在提示词或编排层。编排层可以先拦截大部分无效调用，最后接入业务服务时仍要独立完成授权判断。这样即使模型、工具网关或重试逻辑后续做了调整替换，已有的授权边界也不会随之消失。

拒绝路径要可解释，也要避免泄露资源信息

对调用方返回“没有权限完成该操作”通常比返回“订单 3817 属于另一个租户”更安全。内部审计记录可以保留规则编号、主体、租户、动作、资源数量和关联 ID，但不要把其他用户的资源名称、数量或存在性信息回显给模型侧。

type AuditEvent struct {
    RequestID string
    Rule      string // resource_owner_mismatch / range_limit / unknown_field
    Action    string
    TenantID  string
    ResourceN int
    Result    string // denied
}

func deny(ctx context.Context, rule, action string, n int) error {
    audit.Write(AuditEvent{
        RequestID: RequestIDFromContext(ctx),
        Rule: rule, Action: action,
        TenantID: PrincipalFromContext(ctx).TenantID,
        ResourceN: n, Result: "denied",
    })
    return ErrPolicyDenied
}

四组拒绝用例，能抓住大多数参数越权

不要只测一条正常跑通的样例。至少准备下面四组输入，并核对数据库没有产生越界读取或者非预期的副作用：

• 把 user_id、tenant_id 替换成另一个主体，结果必须拒绝，且审计规则为资源归属不匹配。
• 把日期范围从七天扩大到一年，或把申请的订单数量超过预设上限，结果必须直接拒绝或者要求走分段审批流程。
• 增加 role、is_admin、export_all 等未声明字段，结果不能因为字段名看起来合理而升级权限。
• 重复提交同一个高风险请求，结果应由幂等键或审批状态保护，不能重复创建多余的导出任务。

验收日志至少串起 request_id、工具名、规范化后的动作、策略结果和下游调用次数。最重要的断言是“拒绝后没有下游副作用”，而不是只检查 HTTP 状态码。

上线前把权限规则做成可回退的配置

新规则可以先在影子模式下记录“如果启用当前规则会拒绝哪些请求”，但影子模式不能用于高风险动作的最终放行判断。正式切换时按租户或工具维度逐步放量启用，保留旧规则版本和一键回退开关；一旦拒绝率突然异常升高，先冻结新增权限，再根据审计事件定位误伤范围。

工具 schema、服务端策略和审计字段要一起做版本化管理。只改 schema 配置不改对应的授权测试，往往会留下一个看起来校验更严格、实际仍存在越权漏洞的接口。

相关问题：工具调用安全的几个边界

把 user_id 从工具参数里删除就足够了吗？

不一定。删除多余参数能减少一类逻辑混淆，但服务端仍需校验订单、文档或项目是否属于当前操作主体，并确认动作范围没有被其他字段悄悄扩大。

JSON Schema 能不能替代权限校验？

不能。Schema 解决的是字段形状和类型校验问题，权限校验需要读取会话信息、资源归属关系和业务侧的专属策略，两者必须做分层处理。

拒绝时要不要把原因告诉模型？

可以返回稳定、低信息量的错误类别，例如“当前身份不能执行该动作”，避免泄露资源存在性；详细规则和资源敏感信息留在受控的审计日志里留存即可。

只读工具还需要这么严格吗？

需要。只读类越权也可能泄露用户个人资料、交易订单和内部文档。副作用较小不等于可以跳过资源归属与租户隔离校验。

模型负责提出调用意图，服务端负责确认身份、资源归属和动作合法性。把这条责任边界固定下来，再用覆盖全场景的拒绝用例验证没有下游副作用，工具调用才能搭建出可持续的安全边界。