让 Agent 查业务数据库，怎样限制为只读查询

让 Agent 查业务数据库，不能只在提示词里写“禁止修改数据”。应由数据库角色、受限视图与查询适配层共同限制能力，模型只提出允许的查询意图。本文用 PostgreSQL 合成数据说明最小只读设计，附件提供隔离实验材料；没有在你的数据库执行，也不建议拿生产管理员账号直接试探写入拒绝。

先决定业务真正需要哪些结果

“帮我查订单”应进一步明确为当前组织最近一段时间的订单状态、合计或交期，不自动开放客户电话、利润与内部备注。先建立可查询字段与业务指标字典，确认数量、金额、日期和状态含义。聚合结果也可能泄露信息，例如只有一位客户的分组金额，因此只读不等于没有数据风险，查询范围仍需要按请求人的授权约束。

优先设计少量参数化查询工具，例如按订单号查状态、按日期汇总允许组织的销售额。模型选择工具与参数，服务端校验日期区间、组织范围和结果上限，数据库执行固定查询。对于必须生成 SQL 的场景，再讨论语法解析、允许语句、表列白名单与资源限制。仅检查字符串是否以 SELECT 开头不足以建立安全边界，不能当作只读保证。

数据库权限必须独立生效

PostgreSQL GRANT 官方文档区分查询、插入、更新等权限，可据此为专用角色只授予需要的查询访问。附件建立合成表和不含敏感字段的视图，让测试角色只读取视图，而非整个业务表。管理员初始化与 Agent 运行身份分离，运行角色不应是表所有者、超级用户或可切换到高权限角色的成员。

同时检查继承角色、PUBLIC 默认权限、函数执行权限和新增对象权限，避免当前表只读而其他路径仍可写。视图限制列，不自动证明所有行都已按用户隔离；需要行级约束时，可评估PostgreSQL 行安全策略，并注意所有者等身份的特殊行为。不能把一个有权看到全组织的服务账户简单包装成所有用户共用的无差别查询口。

用三条合成记录建立可见范围

下载只读角色与拒绝测试材料。其中三个订单分属演示东区与西区，包含业务状态和内部备注，视图只暴露东区订单的非敏感列。管理员在新建隔离数据库中初始化；随后使用专用角色查询，预期只返回两条获准记录，不能查到备注。附件使用示范角色与固定范围，生产中多组织身份传播需要单独设计，不应照搬一个静态过滤条件。

查询适配层还要限制返回条数、分页和执行时长。用户要求“导出所有历史订单”时，应先检查权限和成本，必要时转为经过批准的导出任务，不让聊天查询占满数据库。参数采用驱动支持的参数化绑定，不把用户文本拼入 SQL。错误响应中不要直接返回连接字符串、数据库内部结构或完整查询参数，业务端展示受控的失败原因与追踪号。

拒绝写入要实际验证

附件给出查询、更新拒绝和直接访问源表拒绝三类任务。测试时逐条运行，失败后按数据库会话状态结束或回滚，再继续下一项，记录错误与结果不变的证据。测试应使用专用只读角色，不能以管理员执行成功后解释“正式用户应该会被拦住”。也应检查新会话、连接池复用和角色切换，避免上一请求遗留的身份影响下一用户。

可以把只读事务作为附加保护。PostgreSQL SET TRANSACTION 文档说明只读模式对写语句的限制，并明确它是高层概念，不能阻止所有磁盘写入。事务配置不能替代最小权限，更不能证明模型永远无法产生副作用。对危险函数、扩展与跨库访问，应由数据库管理员结合目标环境审查。

查询结果的交付也要受控

返回模型的数据应只含完成当前问题所需字段，引用或下载链接继续校验权限。缓存按身份与范围隔离，员工撤权后不能从旧缓存获得原结果。用户要求把结果发送给其他人或写回业务系统时，属于新的动作，需要单独校验接收范围与写权限，并由有权限的人确认，不能从“允许查”推导出“允许发”和“允许改”。

合成演练使用固定东区视图，是为了让可见集合易于检查。真实多租户系统不能靠用户提供一个地区参数就切换范围，身份与组织必须来自服务端验证。数据库连接复用时要测试从高权限用户切到低权限用户的连续请求，确认角色、会话变量和临时结果没有残留。还应安排无结果与超大时间窗样例，检查系统不会为了回答问题而自动扩大查询条件；需要扩大范围时必须回到业务权限与明确授权。

验收保留建表材料、角色权限、预期可见集合、拒绝样例和资源上限验证。若目标版、代理或连接池导致角色隔离无法证明，先停留在固定报表接口，不开放任意 SQL。隔离样例通过只代表基础设计可检查，生产数据分级、性能与备份访问仍需分别验收。更多背景见流程自动化专题和平台能力边界，系统接入可查看集成服务。通过定制咨询提供脱敏表结构、需要回答的问题和角色范围，可评估最小查询工具。