做一个能查订单的 Agent最麻烦的往往不是把自然语言转成 SQL而是一旦数据库账号交给工具怎样才能不让用户查到不该看的订单。开发到一半你会遇到几个具体问题模型服务 Key 和数据库密码是不是同一种密钥工具参数里要不要带上租户 ID连不上数据库时先看密码还是先看认证方式出问题后怎么从日志里把业务用户和数据库会话对应起来这些问题如果只停留在“数据库密码到底放哪个环境变量”的层面很容易把安全边界放错位置。需要先区分三类凭据再分别看注入、授权、审计和故障排查。先把三类凭据分开模型服务 API Key、工具访问凭据和数据库登录凭据看起来都是一串字符但授权边界不同。模型服务 API Key 只用于服务端请求模型推理证明这个调用方有权请求模型它不应该被拿去连接订单库也不应该进入模型上下文。数据库账号代表某个服务身份可以访问某些表也不应该由模型直接持有。统一存储这些密钥可以但按用途分别授权和分发不能合并。下面这张表概括了三类凭据的典型位置。类型用途典型持有方不能做什么模型服务 API Key调用大模型推理服务服务端配置或密钥管理不用于数据库连接或业务 API 身份工具访问凭据访问内部业务 API、MCP 工具或下游服务受控工具执行服务不直接交给模型或写进提示词数据库登录凭据验证数据库连接身份可访问范围由账号权限决定受控查询服务或后端服务密码等认证秘密不进入模型上下文、工具返回、日志在这个链路里凭据的注入位置是固定的模型服务 Key 只在服务端编排器请求模型时使用数据库账号只在查询工具访问订单库时使用。下面的图给出了大致流向。MCP 官方安全实践里有一条反模式在远程授权链路中MCP 服务器如果接受并未明确签发给自己的令牌不验证受众再原样透传给下游就可能扩大授权范围。这只针对远程授权链路中的令牌透传不是说所有 MCP 服务器都使用同一套 OAuth 流程也不等于任何代理都禁止所有令牌传递。正确做法是服务器验证令牌的受众等必要声明并为下游取得适当授权。同样一串字符不代表能拿去开每道门。把密钥放在哪个框里一个查订单的 Agent大致有四个环节业务用户、Agent 编排与模型、受控查询工具、业务 API 或数据库。密钥只应注入到真正执行访问的那一层。模型服务 API Key 由服务端编排器用于请求模型推理接口不进入模型上下文模型只返回工具调用意图由编排器派发。工具服务从服务端可信上下文获得业务用户身份并读取数据库账号访问数据库。数据库账号不直接暴露给模型或用户。环境变量经常被当成安全边界但它只是交付途径不等于保密隔离。一个在同进程内有任意代码执行能力、或能进入同一终端环境的 Agent可能读取环境变量或挂载的配置文件。例如查询工具运行在容器里数据库密码以 Secret 文件挂载能以服务进程身份执行代码的人也可能读取这份文件。因此应限制该服务能够取得的凭据、数据库权限和网络访问范围。业务代码中的租户过滤能约束正常工具调用但若服务进程已被控制不能指望攻击者仍遵守这段代码还需要数据库侧的有效限权与隔离。小规模本地实验可以用受限配置文件或环境注入起步生产环境则应核验凭据能否撤销、权限是否足够小、访问能否追踪。工具只暴露订单状态以订单查询场景为例受控查询工具可以只接收一个order_id{tool:query_order_status,parameters:{order_id:ORD20260101-1234}}模型只需给出这样的调用参数。服务端在收到该参数后结合已认证上下文补入客户标识和租户标识不需要模型知道这些内部字段。不要让模型传入tenant_id或customer_id也不要把数据库账号、密码或内部 API Key 放进工具参数或工具返回中。这样设计的原因很直接模型不需要知道数据在哪个库、由哪个账号读取它只需要表达“用户想查这个订单状态”。真正决定能不能查的是服务端上下文。身份从服务端来参数化只是第一步SQL 参数化可以防止注入但不能代替授权。即使order_id是参数绑定如果只按order_id查询攻击者或模型幻觉仍可能传入一个不属于当前用户的合法订单号。在同一个租户内还要区分不同客户身份否则同租户不同用户之间仍可能越权。下面以 PostgreSQL 参数绑定写法举例订单查询可以写成SELECTorder_id,status,updated_atFROMordersWHEREtenant_id$1ANDcustomer_id$2ANDorder_id$3;$1、$2来自服务端已认证上下文分别对应租户标识和客户标识$3来自模型工具参数中的order_id。参数绑定用于防止值被解释为 SQL租户与客户条件共同限定当前用户可以读取的订单。客户之间要防止越权租户之间同样要防止越权所以这两层条件不能只留一个。如果业务上存在客服代查应走单独的业务授权和审计路径而不是默认让同租户所有登录用户都能查看该租户下全部订单。PostgreSQL 的 Row Security Policies 可以限行但要注意 superuser、BYPASSRLS 角色以及表所有者通常绕过 RLSFORCE ROW LEVEL SECURITY只处理表所有者绕过不处理前两类。查询服务不应使用这些角色。共享数据库账号只靠current_user无法区分业务用户如果让模型自己填tenant_id或customer_id或自己执行SET任意租户变量只是把身份变成模型可改的输入不构成可信隔离。只读权限也不意味着没有风险只读账号仍可能读取其他租户数据或对全表做大量扫描。数据库权限小到刚好够用给 Agent 的数据库账号不应是管理员账号也不应直接使用内置系统账号。对于订单查询工具通常采用只读账号授权查询状态相关的视图或存储过程。视图通常授予SELECT权限存储过程则授予EXECUTE权限而不是笼统授一个读权限。只读工具场景不代表所有 Agent 永远只能读遇到写任务时应使用独立的受限写工具明确对象、动作和授权是否引入人工审批按风险决定。本文仍然聚焦查订单。最小权限还需要考虑连接来源、最大连接数、语句超时。订单状态查询应建立合适索引并检查执行计划。如果订单状态还需要关联支付或物流表最好通过视图或存储过程把允许的连接关系固定下来避免直接开放跨表查询权限。限制输出行数可以控制返回的数据量但不保证降低扫描、排序或聚合成本。单订单查询唯一约束要能保证一个订单号不会意外匹配多条记录。支持动态短期凭据时使用短期数据库账号到期自动失效。长期密钥不要传入模型上下文、工具返回或日志。即使使用视图或存储过程也要核验其底层策略、security definer以及身份传递方式不能默认它们自带租户隔离。连不上时从连接、认证到存储格式业务账号认证失败时管理员账号正常登录不能证明业务账号正常。我们社区的《内置账号可正常登录手动新建用户全部登录失败》记录过一则 KingbaseES 案例内置system用户可以正常登录手工新建user01等用户全部提示password authentication failed。排查时发现sys_hba.conf要求使用scram-sha-256认证但执行SHOWpassword_encryption;结果为md5。内置账号存储的是 SCRAM 校验信息而新建账号按md5格式存储密码认证要求与存储格式不匹配所以新建用户无法通过认证。修复方式是统一将password_encryption改为scram-sha-256重载并核验然后重置受影响用户密码使其生成相应存储格式复测通过。修改参数本身不会把已存储旧密码自动转为新格式。这类问题可以按从外到内的顺序排查先确认数据库服务端口和网络可达排除连接层问题再确认客户端使用的数据库名、用户名、密码与连接串一致接着查看服务端认证配置与password_encryption参数是否匹配然后由有权人员核对用户实际存储的密码格式是否符合认证要求但不导出完整校验串确认不匹配才重置最后重置业务账号密码并复测观察新连接是否成功。![业务账号认证失败的排查][fig3]排查时不应改用管理员账号绕过否则业务权限会被放大真实问题也被掩盖。轮换、撤销与留痕轮换数据库密码后需要同步更新查询服务的配置让新连接使用新凭据。已有连接和连接池中的旧会话可能继续存在因此还要按业务影响安排连接池重建或受控断开。对于 API Key则要核验调用方已切换新密钥、旧密钥已在服务端撤销以及新请求是否按预期被接受或拒绝。撤销数据库权限时要区分认证与授权。REVOKE SELECT撤销的是对象权限账号仍可能登录确认没有角色继承、PUBLIC等其他授权来源后应检查后续查询是否被拒绝。已经开始的语句和事务如何处理需要按数据库实际行为验证。禁用LOGIN或更换密码主要约束新认证不自动终止已有连接撤销有效的CONNECT权限也不会自动断开现有会话。因此验收应分别检查新连接、池内旧连接的后续查询以及已经开始的操作必要时受控终止会话。日志应包含业务用户、工具名、目标资源、授权结果、请求 ID、数据库角色、耗时或结果行数等元数据。不要把 token、密码、完整敏感结果写入日志。服务层记录业务用户和请求 ID数据库层记录数据库角色和 SQL 指纹二者通过请求标识关联才能形成从业务操作到数据库执行的追踪链。共享数据库账号的数据库日志不能自动识别业务用户必须依靠服务层上下文和关联标识。验收表下面用一张表检查订单查询 Agent 的基本要求。操作应该检查的结果检查查询服务账号的数据库权限只能访问指定对象无无关表读取或建表等权限行范围另由业务授权或行级策略验证查看工具输入参数只有order_id等业务参数tenant_id、customer_id来自服务端上下文模型不可填分别查询同租户其他用户、其他租户的订单号返回空或拒绝不返回他人订单状态撤销 SELECT 权限后用旧会话查询依据数据库行为查询应被拒绝必要时终止旧会话禁用 LOGIN 或轮换密码后发起新连接新连接被拒绝或旧凭据失败轮换数据库密码并重建连接新连接使用新密码成功旧凭据新连接失败查看服务端与数据库日志能看到业务用户、请求 ID、数据库角色和授权结果且无 token、密码或完整订单结果这些措施回答的是 Agent 接数据库时最常见的几个问题模型服务密钥、工具凭据和数据库账号要分开模型不接触数据库账号订单查询靠服务端上下文中的租户标识和客户标识兜底连不上时按连接、认证、存储格式的顺序排查出问题后通过请求 ID 关联服务端和数据库日志。它们不是一次性安全保证而是需要随着实际权限模型和数据库行为持续验证。参考资料[1] OWASP Secrets Management Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html[2] MCP Security Best Practiceshttps://modelcontextprotocol.io/specification/draft/basic/security_best_practices[3] PostgreSQL Row Security Policieshttps://www.postgresql.org/docs/current/ddl-rowsecurity.html
做一个能查订单的 Agent最麻烦的往往不是把自然语言转成 SQL而是一旦数据库账号交给工具怎样才能不让用户查到不该看的订单。开发到一半你会遇到几个具体问题模型服务 Key 和数据库密码是不是同一种密钥工具参数里要不要带上租户 ID连不上数据库时先看密码还是先看认证方式出问题后怎么从日志里把业务用户和数据库会话对应起来这些问题如果只停留在“数据库密码到底放哪个环境变量”的层面很容易把安全边界放错位置。需要先区分三类凭据再分别看注入、授权、审计和故障排查。先把三类凭据分开模型服务 API Key、工具访问凭据和数据库登录凭据看起来都是一串字符但授权边界不同。模型服务 API Key 只用于服务端请求模型推理证明这个调用方有权请求模型它不应该被拿去连接订单库也不应该进入模型上下文。数据库账号代表某个服务身份可以访问某些表也不应该由模型直接持有。统一存储这些密钥可以但按用途分别授权和分发不能合并。下面这张表概括了三类凭据的典型位置。类型用途典型持有方不能做什么模型服务 API Key调用大模型推理服务服务端配置或密钥管理不用于数据库连接或业务 API 身份工具访问凭据访问内部业务 API、MCP 工具或下游服务受控工具执行服务不直接交给模型或写进提示词数据库登录凭据验证数据库连接身份可访问范围由账号权限决定受控查询服务或后端服务密码等认证秘密不进入模型上下文、工具返回、日志在这个链路里凭据的注入位置是固定的模型服务 Key 只在服务端编排器请求模型时使用数据库账号只在查询工具访问订单库时使用。下面的图给出了大致流向。MCP 官方安全实践里有一条反模式在远程授权链路中MCP 服务器如果接受并未明确签发给自己的令牌不验证受众再原样透传给下游就可能扩大授权范围。这只针对远程授权链路中的令牌透传不是说所有 MCP 服务器都使用同一套 OAuth 流程也不等于任何代理都禁止所有令牌传递。正确做法是服务器验证令牌的受众等必要声明并为下游取得适当授权。同样一串字符不代表能拿去开每道门。把密钥放在哪个框里一个查订单的 Agent大致有四个环节业务用户、Agent 编排与模型、受控查询工具、业务 API 或数据库。密钥只应注入到真正执行访问的那一层。模型服务 API Key 由服务端编排器用于请求模型推理接口不进入模型上下文模型只返回工具调用意图由编排器派发。工具服务从服务端可信上下文获得业务用户身份并读取数据库账号访问数据库。数据库账号不直接暴露给模型或用户。环境变量经常被当成安全边界但它只是交付途径不等于保密隔离。一个在同进程内有任意代码执行能力、或能进入同一终端环境的 Agent可能读取环境变量或挂载的配置文件。例如查询工具运行在容器里数据库密码以 Secret 文件挂载能以服务进程身份执行代码的人也可能读取这份文件。因此应限制该服务能够取得的凭据、数据库权限和网络访问范围。业务代码中的租户过滤能约束正常工具调用但若服务进程已被控制不能指望攻击者仍遵守这段代码还需要数据库侧的有效限权与隔离。小规模本地实验可以用受限配置文件或环境注入起步生产环境则应核验凭据能否撤销、权限是否足够小、访问能否追踪。工具只暴露订单状态以订单查询场景为例受控查询工具可以只接收一个order_id{tool:query_order_status,parameters:{order_id:ORD20260101-1234}}模型只需给出这样的调用参数。服务端在收到该参数后结合已认证上下文补入客户标识和租户标识不需要模型知道这些内部字段。不要让模型传入tenant_id或customer_id也不要把数据库账号、密码或内部 API Key 放进工具参数或工具返回中。这样设计的原因很直接模型不需要知道数据在哪个库、由哪个账号读取它只需要表达“用户想查这个订单状态”。真正决定能不能查的是服务端上下文。身份从服务端来参数化只是第一步SQL 参数化可以防止注入但不能代替授权。即使order_id是参数绑定如果只按order_id查询攻击者或模型幻觉仍可能传入一个不属于当前用户的合法订单号。在同一个租户内还要区分不同客户身份否则同租户不同用户之间仍可能越权。下面以 PostgreSQL 参数绑定写法举例订单查询可以写成SELECTorder_id,status,updated_atFROMordersWHEREtenant_id$1ANDcustomer_id$2ANDorder_id$3;$1、$2来自服务端已认证上下文分别对应租户标识和客户标识$3来自模型工具参数中的order_id。参数绑定用于防止值被解释为 SQL租户与客户条件共同限定当前用户可以读取的订单。客户之间要防止越权租户之间同样要防止越权所以这两层条件不能只留一个。如果业务上存在客服代查应走单独的业务授权和审计路径而不是默认让同租户所有登录用户都能查看该租户下全部订单。PostgreSQL 的 Row Security Policies 可以限行但要注意 superuser、BYPASSRLS 角色以及表所有者通常绕过 RLSFORCE ROW LEVEL SECURITY只处理表所有者绕过不处理前两类。查询服务不应使用这些角色。共享数据库账号只靠current_user无法区分业务用户如果让模型自己填tenant_id或customer_id或自己执行SET任意租户变量只是把身份变成模型可改的输入不构成可信隔离。只读权限也不意味着没有风险只读账号仍可能读取其他租户数据或对全表做大量扫描。数据库权限小到刚好够用给 Agent 的数据库账号不应是管理员账号也不应直接使用内置系统账号。对于订单查询工具通常采用只读账号授权查询状态相关的视图或存储过程。视图通常授予SELECT权限存储过程则授予EXECUTE权限而不是笼统授一个读权限。只读工具场景不代表所有 Agent 永远只能读遇到写任务时应使用独立的受限写工具明确对象、动作和授权是否引入人工审批按风险决定。本文仍然聚焦查订单。最小权限还需要考虑连接来源、最大连接数、语句超时。订单状态查询应建立合适索引并检查执行计划。如果订单状态还需要关联支付或物流表最好通过视图或存储过程把允许的连接关系固定下来避免直接开放跨表查询权限。限制输出行数可以控制返回的数据量但不保证降低扫描、排序或聚合成本。单订单查询唯一约束要能保证一个订单号不会意外匹配多条记录。支持动态短期凭据时使用短期数据库账号到期自动失效。长期密钥不要传入模型上下文、工具返回或日志。即使使用视图或存储过程也要核验其底层策略、security definer以及身份传递方式不能默认它们自带租户隔离。连不上时从连接、认证到存储格式业务账号认证失败时管理员账号正常登录不能证明业务账号正常。我们社区的《内置账号可正常登录手动新建用户全部登录失败》记录过一则 KingbaseES 案例内置system用户可以正常登录手工新建user01等用户全部提示password authentication failed。排查时发现sys_hba.conf要求使用scram-sha-256认证但执行SHOWpassword_encryption;结果为md5。内置账号存储的是 SCRAM 校验信息而新建账号按md5格式存储密码认证要求与存储格式不匹配所以新建用户无法通过认证。修复方式是统一将password_encryption改为scram-sha-256重载并核验然后重置受影响用户密码使其生成相应存储格式复测通过。修改参数本身不会把已存储旧密码自动转为新格式。这类问题可以按从外到内的顺序排查先确认数据库服务端口和网络可达排除连接层问题再确认客户端使用的数据库名、用户名、密码与连接串一致接着查看服务端认证配置与password_encryption参数是否匹配然后由有权人员核对用户实际存储的密码格式是否符合认证要求但不导出完整校验串确认不匹配才重置最后重置业务账号密码并复测观察新连接是否成功。![业务账号认证失败的排查][fig3]排查时不应改用管理员账号绕过否则业务权限会被放大真实问题也被掩盖。轮换、撤销与留痕轮换数据库密码后需要同步更新查询服务的配置让新连接使用新凭据。已有连接和连接池中的旧会话可能继续存在因此还要按业务影响安排连接池重建或受控断开。对于 API Key则要核验调用方已切换新密钥、旧密钥已在服务端撤销以及新请求是否按预期被接受或拒绝。撤销数据库权限时要区分认证与授权。REVOKE SELECT撤销的是对象权限账号仍可能登录确认没有角色继承、PUBLIC等其他授权来源后应检查后续查询是否被拒绝。已经开始的语句和事务如何处理需要按数据库实际行为验证。禁用LOGIN或更换密码主要约束新认证不自动终止已有连接撤销有效的CONNECT权限也不会自动断开现有会话。因此验收应分别检查新连接、池内旧连接的后续查询以及已经开始的操作必要时受控终止会话。日志应包含业务用户、工具名、目标资源、授权结果、请求 ID、数据库角色、耗时或结果行数等元数据。不要把 token、密码、完整敏感结果写入日志。服务层记录业务用户和请求 ID数据库层记录数据库角色和 SQL 指纹二者通过请求标识关联才能形成从业务操作到数据库执行的追踪链。共享数据库账号的数据库日志不能自动识别业务用户必须依靠服务层上下文和关联标识。验收表下面用一张表检查订单查询 Agent 的基本要求。操作应该检查的结果检查查询服务账号的数据库权限只能访问指定对象无无关表读取或建表等权限行范围另由业务授权或行级策略验证查看工具输入参数只有order_id等业务参数tenant_id、customer_id来自服务端上下文模型不可填分别查询同租户其他用户、其他租户的订单号返回空或拒绝不返回他人订单状态撤销 SELECT 权限后用旧会话查询依据数据库行为查询应被拒绝必要时终止旧会话禁用 LOGIN 或轮换密码后发起新连接新连接被拒绝或旧凭据失败轮换数据库密码并重建连接新连接使用新密码成功旧凭据新连接失败查看服务端与数据库日志能看到业务用户、请求 ID、数据库角色和授权结果且无 token、密码或完整订单结果这些措施回答的是 Agent 接数据库时最常见的几个问题模型服务密钥、工具凭据和数据库账号要分开模型不接触数据库账号订单查询靠服务端上下文中的租户标识和客户标识兜底连不上时按连接、认证、存储格式的顺序排查出问题后通过请求 ID 关联服务端和数据库日志。它们不是一次性安全保证而是需要随着实际权限模型和数据库行为持续验证。参考资料[1] OWASP Secrets Management Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html[2] MCP Security Best Practiceshttps://modelcontextprotocol.io/specification/draft/basic/security_best_practices[3] PostgreSQL Row Security Policieshttps://www.postgresql.org/docs/current/ddl-rowsecurity.html
 详：)
