让 AI 写的 SQL 先过一道闸：用 Vericto Proxy 保护 PostgreSQL 与 MySQL
把数据库账号交给 AI Agent，最让人担心的往往不是它不会写查询，而是它写对了语法、却做错了事：漏掉 WHERE 的 DELETE、误删表，或把不该读取的敏感列带出数据库。数据库权限能限制“谁能访问什么”，却未必能判断“这条具体语句是否应该执行”。Vericto Proxy 的思路是在应用和数据库之间增加一个透明 SQL 代理，在请求抵达数据库之前解析并按规则放行或拦截。
它处在什么位置
Vericto Proxy 是 Rust 实现的数据库线协议代理。客户端仍使用原来的数据库驱动，连接目标改为代理；代理解析 SQL AST、执行规则检查，再将允许的语句转发到上游数据库。README 当前列出 PostgreSQL 与 MySQL 两种线协议，需在部署时选择其一。其他数据库可以通过项目提供的 HTTP API、CLI 或 MCP 做评估，但不属于这个线代理支持范围。
这不是让模型“更谨慎”的提示词方案，而是把检查放在执行边界。项目文档展示的内置规则包括无条件 DELETE/UPDATE、DROP、TRUNCATE、部分 SQL 注入模式等。低严重度发现（例如没有 LIMIT 的 SELECT）默认可能记录并转发，不能把它理解成所有可疑 SQL 都会自动阻断。
用一次可丢弃的 Postgres 环境试跑
仓库 README 提供了 Docker 演示：启动临时 PostgreSQL，再让代理连接它。下面保留最小部署配置的关键形态；生产环境应使用自己的网络、凭据和受控镜像版本，不要照搬演示密码。
docker run --rm \ -e UPSTREAM_HOST=db \ -p 5433:5433 \ vericto/vericto-proxy:4.15.2
UPSTREAM_HOST 指向代理容器可访问的真实数据库主机。PostgreSQL 默认上游端口为 5432，代理监听 5433；MySQL 模式则需设置 VERICTO_WIRE_PROTOCOL=mysql，默认上游和监听端口分别为 3306、3307。实际部署时还需在同一容器网络中配置数据库服务，并根据官方配置文档处理 TLS、健康检查和日志等事项。上面的单条命令仅说明代理容器的基本参数，不是可独立运行的完整 Compose 配置。
应用侧通常只需把连接串中的主机和端口指向代理。比如原本连接 db:5432，可改为代理服务名及 5433。先在隔离测试库验证驱动兼容性、事务行为和错误处理，再逐步接入真实工作负载。
从拦截到敏感列策略
README 的示例展示了无 WHERE 的 DELETE FROM users 被代理阻止，而限定 WHERE id = 42 的语句可以通过。这种做法将危险操作转换为数据库客户端可识别的原生协议错误，应用无需解析一套全新的返回格式。不过业务仍需做好失败处理：记录被拒绝的操作、向调用者返回明确错误，并避免 Agent 在收到错误后不断重试同一条危险语句。
更细的敏感列策略需要控制平面配置。项目文档描述了 block、flag、mask 三种处理：阻止查询、原样放行并记录，或改写查询使结果列被遮罩。策略可按数据库用户配置；因此为 Agent 分配独立数据库账号，比让多个服务共用管理员账号更容易建立清晰边界。控制平面策略与内置规则并非同一层配置，部署前要按官方文档确认所用方案及其计划要求。
适用边界与上线检查
代理不能替代数据库最小权限、备份、迁移审批和审计。README 明确提到，敏感列标签和 Agent 表/列 allowlist 等能力依赖控制平面及相应计划；自托管并不意味着所有策略功能都无需外部配置。项目自述采用 FSL-1.1-ALv2：允许自托管和生产使用，但对将其作为竞争性商业服务提供有约束；每个版本在发布两年后转为 Apache-2.0。因此它是 source-available，不应简单称为当前已完全开放的 Apache 项目。正式采用前应阅读仓库中的许可说明，并让法务评估具体用途。
建议按以下顺序试点：先用一次性测试库验证阻断行为；再用专用、低权限数据库账号接入非关键工作负载；随后观测误拦截和漏报，再考虑配置敏感列策略。尤其要在升级代理版本或切换 PostgreSQL/MySQL 模式时重新执行集成测试。安全代理只有在规则、账号权限、运行监控和恢复方案共同生效时，才是可靠的防护层。
相关链接