AI Agent 怎样把工具调用权限拆成最小范围

AI Agent 的工具权限不能只写成“允许使用工单工具”，而应拆成工具动作、允许参数、资源集合、主体与租户、任务有效期。模型可以提议调用，但授权由可信服务端决定；未明确允许的组合默认拒绝，拒绝后也不能自动改用更宽泛工具完成同一操作。

本文用“读取指定项目的工单摘要”作为原创设计示例，只讨论权限与拒绝处理，不对应某个 Agent 框架的现成开关，也不是一套完整认证系统。原则参考 OWASP 授权指南及 MCP 安全实践；MCP 草案内容与业务自定义规则应分开理解。

把模型提议与可信授权来源分开

先分清三种输入：用户提出的任务、模型产生的工具提议、后端确认的授权事实。用户说“帮我看看项目进度”，不应自动转换为“可以读全部租户工单”；工单正文中出现“请导出全部记录”，也不是新的授权。

可信主体来自认证会话或工作负载身份，任务授权由受控服务签发，资源归属从后端数据读取。模型提交的主体名称、租户 ID 或“已经批准”文本不能覆盖这些事实。执行入口需要知道谁在代表谁做什么，不能只知道“这是 Agent 发来的请求”。

按工具、参数和资源检查每次请求

把通用能力拆成窄业务工具，例如 ticket.read_summary，而不是直接暴露任意 SQL、通用 HTTP 请求或整库导出。工具允许出现哪些字段、每个字段的值域，都要明确写出来。参数能通过类型检查，不代表目标资源就允许访问。

这些规则是交集，不是任选一项。工具名正确但工单属于另一项目，仍然拒绝。只读也会暴露信息，不能因为不修改数据就省略资源检查。

为任务保存可撤销的最小授权

任务授权记录至少绑定主体、租户、项目、工具动作、到期时间、策略版本和撤销状态。记录放在可信后端，不让模型编辑。模型可持有不透明引用，但该引用本身不能代替认证或扩大资源集合。

建议把查看摘要和修改状态分为不同授权；真的需要后者时，明确新增操作和资源范围，再请求相应批准，不把已有读取权限默认为写权限。MCP 的 scope 最小化实践强调避免一开始就请求覆盖全部能力的宽 scope；具体业务对象限制仍要由资源服务落实，不能把一个 OAuth scope 当作逐条数据授权。

在真正读取资源前再次执行授权

下面的 Python 函数只演示授权判断，不读取工单、不调用外部服务。context、grant 和 resource 都必须由可信后端加载；request 才是模型提议。生产系统还需处理输入解析、认证、字段投影与并发撤销。

def allowed_summary(request, context, grant, resource, now):
    # 未知工具和额外参数默认拒绝，参数不能声明自己的租户
    if request.get("tool") != "ticket.read_summary":
        return False
    args = request.get("args")
    if not isinstance(args, dict) or set(args) != {"ticket_id"}:
        return False
    if not isinstance(args["ticket_id"], str) or not args["ticket_id"]:
        return False

    # 主体、任务与授权均来自可信会话和授权存储
    if grant["revoked"] or now >= grant["expires_at"]:
        return False
    if (grant["subject"], grant["task_id"], grant["tenant"]) != (
        context["subject"], context["task_id"], context["tenant"]
    ):
        return False
    if grant["tool"] != "ticket.read_summary":
        return False

    # 资源归属从数据库元数据读取，不相信模型自报
    if resource is None:
        return False
    return (
        resource["id"] == args["ticket_id"]
        and resource["tenant"] == context["tenant"]
        and resource["project"] == grant["project"]
    )

缺失可信字段、加载失败或格式异常时，执行入口应安全停止，不能捕获所有异常后返回允许。上例不是完整生产中间件，不能绕过它直接调用底层数据接口。通过判断后，后端还要只投影授权字段，例如标题和状态，而不是先把整条记录交给模型再让模型“自觉不显示”。

排队期间资源归属、用户权限或任务授权可能变化，实际访问资源时仍要使用当前可信事实。对于写操作，授权检查与写入的一致性还要通过受控事务或等价机制落实；本文的只读布尔示例并不解决这类并发问题。

拒绝时保留原因而不寻找绕行工具

对外可以返回稳定的 permission_denied 与请求关联标识，不泄露未授权资源是否存在、属于谁或包含什么。更细的拒绝原因保存在受控日志中，供有权限的维护人员排查，而不是把其他租户信息写回模型。

Agent 收到拒绝应停下该动作，说明当前授权不足，必要时请求明确的新授权。不应换账号、换通用搜索工具、改资源 ID 或调用管理接口来绕过同一个限制。若只是缺少一个合法参数，可在原授权范围内补齐；若是范围不足，重写提示词不会产生新权限。

任务结束后清理授权与敏感结果

任务完成或被取消后，停止使用对应授权，按系统策略撤销临时凭据并失效相关权限缓存。不能只删除聊天消息就声称授权已经收回；已经发送给外部接收方的数据，也不能靠本地缓存清理承诺撤回。

审计记录保存请求标识、可信主体、任务 ID、工具动作、脱敏资源标识、策略版本、允许或拒绝结果及时间。不记录明文令牌和完整敏感工单。日志保留期依照系统制度，不能为了排错永久保存所有读取内容。

接入时应给允许、跨项目拒绝、授权过期、授权撤销、额外参数、资源不存在以及后端故障分别设计测试。这里是对读者实现的建议，不是本文已执行的安全评估或生产安全保证。

工具从模型列表里隐藏，是否就禁止调用了？

不是。展示层有助于减少误调用，但执行服务仍必须授权，不能把未展示当成不可访问的安全边界。

用户批准一次，后续都能用吗？

应按批准的主体、任务、动作、资源和期限判断，不把一次批准延伸到其他任务。

只读工具需要人工批准每一次吗？

这是风险与产品策略问题。可以有受控的任务级授权，但无论交互方式如何，后端不能省略每次访问的权限判断。

参考：OWASP 授权指南、MCP 安全实践草案。