为什么开发测试通过，上线仍出现越界读取
假设企业把售后记录接到 AI 助手，要求华东团队只查询自己负责的记录。开发人员用一个受限制的测试账号验证，确实看不到华南资料，于是认为权限验收完成。正式服务上线后使用了另一套数据库连接身份，结果可能与测试不同。这是假设的验收风险，不是已经发生的客户事故。
FDE 在业务现场需要核对的是实际请求经过哪个连接池、最终以哪个数据库角色执行，而不只是页面登录了谁。员工身份、应用权限和数据库身份之间如果没有可追踪的映射，单独一张查询截图很难证明上线后的访问范围。本文聚焦这个身份差异，不重复讨论知识片段切分或答案缓存权限。
先核对官方机制，再确定测试身份
PostgreSQL 18 官方文档说明：超级用户及具有 BYPASSRLS 属性的角色会绕过行级安全；表所有者通常也会绕过，但可通过 FORCE ROW LEVEL SECURITY 使其受策略约束。启用行级安全而没有策略时，普通访问采用默认拒绝。
这意味着“策略已经建立”和“当前连接受到策略约束”是两件需要分别核验的事。上述内容是官方机制；下文的角色清单、测试矩阵与交接方法是编辑提出的工程建议，不是数据库强制要求，也不是已经完成的部署成果。
把连接角色写进交付清单
建议为在线问答、批量导入、定时汇总、人工维护分别列出连接入口、数据库角色、可访问表以及角色切换方式。清单只记录角色名称与用途，不记录密码。由数据库负责人确认每个角色是否具有特殊属性、是否拥有目标表，以及应用是否会在会话内切换身份。
若一个服务同时承担建表迁移和在线查询，应解释为何共用身份，并在测试中覆盖其真实权限。不要为了赶验收临时更换受限账号做演示，随后仍用高权限身份上线。确需维护权限的任务应有独立操作说明，不能让一份读权限验收报告替所有任务背书。
让读写反例与业务范围一一对应
在隔离环境准备两组可辨认的测试记录，例如甲组与乙组，各自有独立归属标识。以正式服务拟使用的连接角色运行与应用一致的查询路径，验证允许记录能读、禁止记录不能读。只检查零结果并不充分：如果所有记录都不可见，也可能是配置错误，而不是隔离正确。
若应用支持写入，还应分别测试新增、修改既有记录及修改归属字段。为每个动作写清预期业务结果，记录请求编号、角色、测试数据归属和返回状态。测试数据与真实客户信息分开，失败时能够重现具体动作，而不是只留下“权限正常”的总评。
通过应用入口再验一次身份映射
数据库层测试完成后，仍需从 AI 服务实际接口重复关键用例，核对日志中的请求编号与数据库执行身份。这样可以发现应用是否走了另一套连接配置、后台作业是否使用不同角色，以及交付清单是否漏掉导出或汇总入口。
验收记录建议保留环境、数据库版本、角色属性核验时间、策略版本和测试结论。日志应足够定位问题，同时避免复制整份客户查询内容。若系统尚不能追踪实际执行身份，应把这个缺口列为待补证据，不能因为聊天窗口没有显示越界信息就判定整条读取链通过。
权限变更以后，重新跑哪些检查
建议把角色属性、表所有权、策略和连接配置的变化列为复验触发条件。测试矩阵可以保持简短，但至少要包含允许读取、禁止读取以及实际存在的写入路径。每次变化后记录版本与结果，便于判断问题来自业务范围调整还是部署配置偏差。
业务负责人确认数据范围，数据库负责人确认角色与策略，交付工程师确认应用实际路径，三方证据应能对应同一版本。验收标准是各项预期结果都有可复查记录；未覆盖的后台入口明确列出，不以一句“已配置 RLS”替代剩余工作。
适用边界与上线决定
这套方法适用于通过 PostgreSQL 访问关系数据、并由团队掌握角色与应用配置的企业 AI 项目。它不直接证明向量检索、附件下载、结果缓存或第三方工具也完成了授权控制；这些路径需要各自的证据。
如反例测试出现越界，建议先收窄有问题的应用入口，再由负责人定位身份或策略差异，并在修正后复验。是否上线应依据已覆盖的业务范围与未解决缺口决定，而不是依据演示时回答是否流畅。对交付团队而言，真实服务身份与可重现的反例，才让权限承诺能够被检查。
要点总结
- 还需核对连接角色、策略适用范围和查询路径，并以实际服务身份进行反例测试。
- 管理员测试不能代表业务服务的权限表现，应覆盖真实连接身份与角色切换后的身份。
- 本文只讨论关系数据库角色与行级策略验收；向量库、缓存、附件与导出仍需分别验证。
参考来源说明
官方机制与编辑提出的验收流程分别表述。文中业务场景为假设，无客户效果或生产测试承诺。