人工智能 数据服务的权限边界

模型工具调用能方便地查询数据和执行操作，也可能把超出任务范围的数据带进上下文。权限设计应按调用者、数据集和动作拆分，模型不能因为“需要回答问题”而获得底层服务的通配权限。

最小权限原则

为每个工具定义允许的动作、资源范围和最大返回量；服务端再次校验，而不是相信提示词。密钥放在受控配置中，日志只记录请求标识、工具名和错误类别，不记录令牌和原始数据。

func Authorize(subject, action, resource string) error {
    if !policy.Allows(subject, action, resource) {
        return ErrForbidden
    }
    return nil
}

依赖扫描和密钥扫描是补充，不是权限控制。将它们放入本地提交检查和 CI，同时保留人工复核：新增网络出口、写操作和跨租户查询应明确审批。发生异常时先撤销或缩小凭证权限，再定位来源。

让拒绝行为也可排查

权限被拒绝时，调用方需要知道是参数不完整、资源不在授权范围内，还是当前动作本来就不允许；但返回信息不能顺手暴露资源是否存在。服务端可以把这两件事分开：对外给稳定的拒绝结果，对内用请求标识关联审计日志。审计记录至少包含主体、工具、动作、资源类型、决策结果和策略版本，敏感字段只存脱敏后的摘要。

测试不能只覆盖“有权限”的路径。要专门构造越权资源、过期凭证、超出返回上限和重复提交等输入，并确认拒绝后没有产生部分写入。权限规则变更时，先用只记录不拦截的方式观察命中情况，再逐步启用；这种节奏比一次性收紧更容易发现遗漏的合法调用。

继续把问题说具体

讨论数据服务的权限边界时，我更关心模型输出落到真实动作之前经历了什么。提示词、检索结果、工具参数和权限信息很容易在同一条链路里混在一起；只要其中一项来源不清，后面的“智能判断”就不该直接触发写入、调用或发布。最小权限原则、让拒绝行为也可排查中的架构应明确哪些内容只是建议，哪些内容才具备执行资格。

把模型放在可撤回的位置会轻松很多。让它负责生成候选、归类或解释，把决定性检查交给固定规则和明确的业务状态；工具调用前检查目标、参数和当前阶段，工具返回后再确认结果是否符合预期。这样即使模型重复请求、输出缺字段或误解上下文，也不会把错误一路放大。

排查时保留必要的上下文即可：输入摘要、选择的工具、参数校验结果、执行结果和拒绝原因。日志不是越多越好，关键是能把一次动作从请求还原到结果，同时避免把不该保存的原始内容散落在多处。对于需要人工批准的动作，界面和记录都应说明批准的是哪一个具体变化。

这类系统没有一劳永逸的“安全提示词”。每增加一种工具或数据来源，都要重新检查它能读什么、能改什么、失败时停在哪里。把这件事写成短而明确的规则，比在结尾堆砌宏大的治理口号更有价值。

容易漏掉的细节

数据服务的权限判断不能只放在页面按钮上。一次看似普通的查询，可能经过缓存、批处理或导出接口；每一层都要知道调用者是谁、请求的对象是什么、当前操作是查看还是修改。否则前端拦住了直接操作，旁路接口仍可能把数据带出去。

拒绝访问时也别只返回笼统的失败。对调用方给出足够的可处理信息，例如缺少哪类授权或对象不存在；内部记录则关联请求标识和规则命中原因。两种信息分开，既便于排查，也避免把权限结构暴露给不该知道的人。