面向 AI agent 的 SQL 防护栏 — 在执行前阻断破坏性查询
面向 AI agent 的 SQL 防护栏会在危险语句（DROP、TRUNCATE、缺少 WHERE 的批量 DELETE/UPDATE、全表扫描，大批量数据查询等）到达你的 MySQL、PostgreSQL 或 Cloudflare D1 之前将其拦截。FutrixData 把静态规则匹配与预检查 EXPLAIN 探针结合 — 同一个 SELECT 在有索引的查找上是低风险，在执行计划显示大范围扫描（如查询 10 万条数据）时则是中风险。
AI 场景下"SQL 防护栏"的含义
数据库权限回答的是"谁可以连接、谁可以读写"。agent 引入了更细的问题：在同一个连接下，不同语句承载着差异巨大的风险。SELECT * FROM orders WHERE id = 1001 是点查；SELECT * FROM orders 则是一次客户数据导出。防护栏正是用来区分二者的中间层。
四类风险
- 破坏性操作。
DROP TABLE、TRUNCATE、缺WHERE的DELETE/UPDATE— 默认阻断。 - 大范围查询。全表扫描、缺失索引、估算扫描行数过大、深度连接 — 由预执行
EXPLAIN探针升级风险。 - DDL。
ALTER、CREATE、删除索引 — 视目标表给出 warn 或要求审批。 - 权限变更。
GRANT、REVOKE— 直接阻断。
两层评估：静态规则 + 预执行 EXPLAIN
静态规则捕获显而易见的情况（缺 WHERE、目标表为 audit_logs 等）。探针捕获解析器无法判断的情况：查询是否真的命中了索引。FutrixData 在以下情况下升级风险：
- 没有命中任何索引。
- 扫描行数超过配置阈值。
- Explain 计划不可获取或不可校验。
- MySQL：全表扫描、临时表、filesort、相关子查询、昂贵连接。
- PostgreSQL：顺序扫描、深层子计划、大结果集排序。
- D1：
SCAN阶段、视图展开后的基表扫描。
探针只提升风险，不会把已被判为高风险的操作降级。
内置 MySQL / PostgreSQL / D1 规则
| 语句 | 默认动作 |
|---|---|
SELECT、SHOW、DESCRIBE、EXPLAIN | allow |
INSERT、REPLACE、UPDATE … WHERE、DELETE … WHERE | warn |
缺 WHERE 的 UPDATE / DELETE | block |
CREATE、ALTER | warn |
DROP、TRUNCATE、GRANT、REVOKE | block |
用户规则凭借更精确的作用域与更高的优先级覆盖内置规则。例如：默认对 UPDATE 给 warn，但禁止生产环境 orders 上的任何 DELETE。
信任模式
每个数据源的信任模式决定可编程入口（agent、MCP、Skill、CLI）能自动执行什么。
| 模式 | 行为 |
|---|---|
| Approval | 每次执行均需人工确认。 |
| Cautious | 默认。仅低风险语句自动执行。 |
| Trusted | 低与中风险自动执行；高风险仍需确认。 |
| Danger | 所有操作自动执行，包括通常会被阻断的操作。仅推荐用于一次性的测试数据。 |
审批是如何工作的
当 agent 命中 require_approval 结果时，代理返回结构化响应，描述命中的规则与已解析的语句。调用方必须以 approve: true 重新发起请求。审批在入口层校验 — agent 无法直接把 approve: true 塞进任意调用以绕过拦截。
示例
// agent 尝试：
DELETE FROM users;
// FutrixData 响应：
{
"ok": false,
"risk": "block",
"rule": "sql.delete_without_where",
"reason": "DELETE without WHERE clause on table users",
"data_source": "prod-postgres",
"audit_id": "audit_01HQ7M..."
}// 调用方重发：
{
"statement": "DELETE FROM users WHERE last_login < now() - interval '5 years'",
"approve": true,
"approval_reason": "scheduled GDPR purge, ticket OPS-2189"
}常见问题
在 SQL 数据源上 FutrixData 默认阻断什么？
DROP、TRUNCATE、GRANT、REVOKE，以及缺 WHERE 的 UPDATE/DELETE。其他默认 allow（读）或 warn（写 / DDL），是否需要审批由信任模式决定。
会对合法查询产生误报吗？
静态规则刻意做得很窄 — 仅针对破坏性操作与缺 WHERE 的模式。预执行 EXPLAIN 探针是更精细的一层；阈值（最大扫描行数、最大连接数）按数据源可配置（特定的小表由于优化器可能使用Seq Scan，可以设置全表扫描行数豁免）
可以覆盖一次阻断吗？
可以 — 对于 warn / require_approval，调用方可以以 approve: true 与一个会写入审计日志的理由重新提交。硬 block 规则（例如生产环境的 DROP）需要修改配置而非按调用临时覆盖；这是设计如此。
只支持 ORM 还是也支持原生 SQL？
原生 SQL。FutrixData 直接解析 MySQL、PostgreSQL 与 D1 语法以提取命令类型、目标表、是否有 WHERE、连接与子查询。会发出原生 SQL 的 ORM 也被透明地覆盖。
MySQL 与 PostgreSQL 处理有何不同？
静态规则集相同。探针不同：MySQL 检查全表扫描、临时表、filesort、相关子查询与连接行估算；PostgreSQL 检查顺序扫描、连接数、子计划与大结果集排序；D1 检查 SCAN 与 SEARCH，并校验视图展开后的基表扫描。
预执行 EXPLAIN 会增加延迟吗？
会 — 通常会在真正查询之前多一次到数据库的往返。对点查只是几毫秒；对 explain 不通过的查询，节省的延迟远大于探针本身的开销。
在你自己的数据库上试用 FutrixData
免费桌面应用支持 macOS、Windows、Linux。生产环境部署可选自托管 Enterprise Edition。