AI 数据库代理：面向 AI agent 与数据库的统一网关

什么是 AI 数据库连接代理？

AI 数据库代理是一项中介所有 AI agent 数据库调用的服务，取代了每个 agent 各自持有数据库连接密钥的模式。它接收查询（SQL、Mongo、Redis 命令、Elasticsearch DSL、ChromaDB），按策略评估，再到真实数据库上执行，并将处理后的结果返回给 agent。

数据库代理承担了数据库本身无法表达的控制项：

• 采用每个 agent 独立身份取代共享数据库凭证，支持独立 agent 的身份吊销与审计归属。
• 查询防护栏在执行前（而非执行后）将语句分类为低／中／高风险。
• agent 结果路径上的字段级脱敏 — 在结果行返回给 MCP / Skill / CLI 调用方之前，敏感字段会被替换为稳定的、由密钥派生的假名化 哈希值。
• 本地哈希链审计日志（内置 audit verify CLI），用于回答"哪个 agent 在什么时候做了什么、为什么被允许"。仅本地校验 — 范围请见 trust 与 limitations。

为什么 AI agent 需要代理

把原始连接密钥交给 LLM，配置很快 — 后悔也很快。在生产环境中会出现五类风险：

1. 破坏性查询。agent 会幻觉。一项"清理过期记录"的任务可能在无人察觉的情况下变成 DELETE FROM users。
2. 凭证泄露。连接字符串最终会出现在提示词、日志、追踪导出中 — 然后进入别人的训练数据。
3. PII 被发送至第三方模型。客户姓名、卡号、生物特征数据被序列化进提示词，发送给 agent 使用的任意 LLM。
4. 没有审计轨迹。"是 agent 干的"无法让你的事件复盘或合规审查者满意。你需要"谁、做了什么、何时、为什么被允许" — 写在事后可以核验的位置。
5. 每个 agent 都拥有过大的操作权限。agent 继承开发者的凭证 — 通常是对所有表的读写权限。当聊天机器人能 TRUNCATE/DELETE 时，最小权限原则便形同虚设。
6. 每个 agent 都拥有过小的操作权限。如果每个 agent 的权限又很小，那 agent 执行任务束手束脚又很难完全自动化。

FutrixData 如何实现代理

所有数据库操作都流经单一执行管理器。在数据库适配器执行之前，静态规则与数据库专属探针会先评估它。

完整流程：

1. agent 通过 MCP、Skill、CLI 发送查询。
2. FutrixData 解析数据源、解析语句，并匹配静态规则。
3. 对 SQL、MongoDB 与 D1，执行预先 EXPLAIN 探针，检查扫描行数、索引使用与连接。/ 对于 ElasticSearch、ChromaDB、DynamoDB 、Redis会执行静态的Risk Engine 风险检测。
4. 合并后的风险等级（allow / warn / require_approval / block）与每个数据源的信任模式（Approval / Cautious / Trusted / Danger）协调。
5. 数据库适配器执行查询，结果按字段脱敏，并写入审计条目。

CLI、MCP、Skill 与应用内 AI Chat 共享同一服务层策略 — 它们不会出现行为分歧。

FutrixData 在代理层强制执行的内容

支持的数据库

FutrixData 通过单一接口为 MySQL、PostgreSQL、MongoDB、Redis、Elasticsearch、ChromaDB、DynamoDB 与 Cloudflare D1 提供代理。每种数据库类型都有各自的解析器、规则集和探针 — Redis 不会被当作"换了字符串的 SQL"来处理。