“请只查询当前用户有权访问的数据”是一条有用的提示，但它不是权限系统。真正的数据隔离必须落在身份、接口和查询执行层，且对每一次工具调用都生效。
把模型放在不可信输入链中
自然语言、检索到的文档、工具返回值都有可能带有误导性内容。AI 既可能误解组织范围，也可能受到提示注入。应用可以让模型提出“查询本季度成交机会”的意图，但不能让模型自由决定是否绕过租户或用户限制。
推荐的权限执行顺序
已认证用户（可信 user_id / tenant_id）
→ 意图识别（模型）
→ 工具白名单与参数结构校验（应用）
→ 对象级 / 行级权限判断（服务端）
→ 参数化执行（CRM API 或数据库）
→ 结果裁剪与敏感字段脱敏
→ 返回用户 + 审计记录服务端的 tenant_id、user_id 和授权范围应由可信会话获取，不能采用模型生成的用户标识。工具调用中的筛选参数只能收窄权限，不能扩大权限。
查询示意：先约束授权范围
-- 示例结构，仅说明过滤原则；不是可直接运行的业务 SQL
SELECT customer_id, customer_name, last_followup_at
FROM visible_customers
WHERE tenant_id = :trusted_tenant_id
AND owner_id IN (:authorized_owner_ids)
AND last_followup_at < :cutoff_date
ORDER BY last_followup_at ASC
LIMIT :validated_limit;实际实施时应通过经过审查的查询视图、业务 API 或有严格参数绑定的查询构造器执行。不同数据库对列表参数的绑定语法不同，不能直接把字符串拼接进 SQL。仅靠数据库视图也无法替代多层授权和安全审计。
RBAC 与数据范围是两件事
- RBAC（基于角色的访问控制）解决“能否执行这个功能”：例如销售可以查询客户、普通员工不能导出客户全表。
- 数据范围解决“可以访问哪些记录”：例如仅本人负责、所属团队或经过授权的客户。
- 字段级保护解决“能看到什么细节”：例如可以查看销售统计，但不暴露客户手机号或合同附件。
- 操作级保护解决“可以做什么动作”：写入、批量导出、外发报告应获得更严格的授权。
至少准备这五组越权测试
- 用 A 用户询问 B 用户的客户信息，预期返回拒绝或只返回 A 的可见部分。
- 让模型将 owner_id、tenant_id 改成其他值，检查服务端能否阻断。
- 在搜索结果或外部文档中植入“忽略限制”的文字，验证工具权限不变。
- 测试聚合报表是否通过小样本分组泄露个体敏感信息，必要时设置阈值。
- 测试定时报告的接收人、附件和查询范围是否继承原授权且在执行时重新校验。
上线后的审计应该记录什么
记录请求关联 ID、调用主体、工具名、执行范围、授权决策、耗时和结果数量等必要信息。敏感入参及结果内容应最小化留存，并设置访问控制和保存周期；不要把全部客户资料直接写进普通日志。