登录：确认用户与组织
授权：解析角色、项目和数据范围
查询：只生成允许的字段与过滤
执行：数据层再次强制权限
输出：图表、导出和日志保持同一边界
先给结论：权限应在数据执行层再次生效
在提示词里写“不要查看其他区域”不是可靠的安全边界。模型可能误解指令，工具调用也可能绕过文本约束。更稳妥的方式是由身份系统确认用户，在授权层计算数据范围，并在数据库、语义层或查询代理执行时强制过滤。
输出侧同样要受控：图表、明细、下载、缓存和对话历史都不能扩大原查询的权限。安全是一条端到端链路，而不是聊天框前的一句规则。
角色权限和数据权限解决不同问题
角色权限决定谁能创建数据源、管理成员、发布智能体或查看用量；行权限决定可见哪些门店、区域或客户；列权限决定是否能看到手机号、成本、薪资等敏感字段。三类权限应分开建模。
测试时准备至少三种身份：总部、区域、门店。让三者提出相同问题，比较结果范围、明细、导出和缓存。再切换用户，确认上一身份的上下文不会泄露。
查询生成前后都要校验
生成前，系统只向模型暴露被授权的表、字段、指标和业务文档，减少越权候选；生成后，对 SQL 或查询计划做字段、表、函数和过滤校验；执行时再由数据层强制策略。多层校验能够降低单点失误。
AskTable.ai 已确认存在组织、角色、项目和数据范围能力。具体是否对接某个企业的 IAM、行列权限系统或审计平台，需要在集成设计中确认，不能从通用能力推断。
缓存、日志和导出是常见遗漏
即使查询本身安全，跨用户共享缓存、包含敏感值的日志、生成后的 Excel 和截图仍可能造成泄露。缓存键应包含身份与授权范围；日志应脱敏并限定访问；导出链接应有权限与有效期。
员工停用、角色变化或项目转移后，应验证旧会话、收藏报告、分享链接和计划任务是否同步失效。权限撤销测试往往比首次授权更能暴露问题。
一套可执行的安全验收
建立正常访问、越权尝试、提示注入、跨会话、导出、撤权六组测试。每次记录身份、策略版本、查询计划、返回范围和审计事件。高风险数据默认采用最小权限，并设置人工复核。
行列权限可以减少暴露面，但不能替代数据分类、访问审批和合规制度。最终责任仍需要安全、数据和业务负责人共同确认。