Faz 实战：AI Agent 访问数据库的安全中间层，五层管道挡住每一次危险操作

你给了 AI 编码 Agent 数据库的访问权限。它很聪明，能帮你写 SQL 查数据、分析业务报表、自动生成 CRUD 接口。但你睡觉的时候，它会不会也执行一条 DROP TABLE 或者把客户的信用卡数据发到某个外部 API？

这听起来像是多虑，但正是今天每个深度使用 AI Agent 的开发者都面临的安全边界问题。

真实场景：数据库安全层在 Agent 架构中的位置

先看几个典型场景：

场景一：你在 Cursor 里开发一个电商后台，Agent 需要用 PostgreSQL 生成销售报表。你给了它 readonly_user 凭证。但 Agent 在执行链路中动态拼接了用户输入，生成了一条 SELECT * FROM users WHERE email = 'admin@example.com' OR 1=1'——SQL 注入通过 Agent 间接打到你的数据库。

场景二：Claude Code 帮你做数据库迁移，你给了它写权限。Agent 在一轮交互中误读了上下文，执行了你没确认的 DELETE FROM orders——因为 Agent 的”删除过期订单”指令在生产表上执行了。

场景三：你在一个 20 个微服务的项目中同时用三个 AI 编码工具，每个都有自己的数据库连接方式。SQLite、PostgreSQL、MongoDB、Elasticsearch——每套工具的认证方式不同，权限配置碎片化，你根本不知道哪个 Agent 能干什么。

这些问题有一个共同的解：在 Agent 和数据库之间加一层安全中间件。Faz 就是为这个场景设计的。

Faz：五层安全管道（Prompt → Database）

Faz 是一个 Python 开发的安全中间层，定位在 AI Agent 和数据库之间。它的架构干净到可以用一张图描述：

Claude Code / Cursor / Codex → Faz (auth · safety · audit) → 14 种数据库

所有查询在到达数据库之前，必须通过五层安全检查：

第 1 层：Prompt Guard（意图检测）

不解析 SQL，直接扫描原始请求中的破坏性意图。"DELETE FROM salaries" 触发告警，但 "show me deleted records" 正常放行。这一层在语义上区分了”操作指令”和”查询意图”。

第 2 层：RBAC Gate（表级权限）

你可以在 faz.yaml 中配置每张表的读写权限：

databases:
  - name: production_db
    type: postgresql
    host: localhost
    database: myapp
    username: agent_user
    password: ${DB_PASSWORD}

permissions:
  postgres:
    baseline: R          # 默认只读
    tables:
      orders: RW         # 订单表可读写
      audit_log: none    # 审计日志禁止访问

权限粒度支持：R（只读），W（只写），RW（读写），RA（读+追加），RWA（读写+更新，不含删除），A（全部含 DDL），none（完全阻止）。

第 3 层：AST Checker（语法级阻断）

解析 SQL 的抽象语法树，硬阻断 DDL 操作——DROP TABLE、ALTER TABLE、TRUNCATE 在语法分析阶段就被拦截，无论 SQL 如何拼接或编码。AST 分析不受字符串大小写、注释干扰的影响，这是正则过滤器做不到的。

第 4 层：Injection Scan（注入检测）

检测 SQL 注入的经典模式：恒真式（1=1）、堆叠查询（; DROP TABLE）、$where 注入、APOC 过程调用（Neo4j）。这一层不依赖黑名单关键词，用上下文敏感的分析判断良性与恶意。

第 5 层：Guardrails（行为护栏）

最后一道防线：行数上限、超时限制、查询重写。防止 Agent 在循环中拉取全表数据导致数据库 OOM，或者用一个没有 LIMIT 的查询把几百 GB 的数据拉到 Agent 的上下文里。

快速上手：5 分钟跑通

安装和配置走的是”先初始化，后交互式配置”的路径：

pip install faz-core
faz init                           # 生成 faz.yaml 和 .faz/ 目录
faz add-database                   # 交互式向导，选择数据库类型并填入连接信息
faz mcp install                    # 自动配置 Claude Desktop + Cursor
faz serve                          # 启动 REST API，监听 localhost:8787

MCP 安装后，Agent 能看到 4 个工具：

执行查询时，Agent 得到的结果包含安全审计信息：

{
  "status": "ok",
  "data": { "columns": ["customer_id", "total"], "rows": [...], "row_count": 42 },
  "safety": { "stages_passed": ["PROMPT_GUARD", "RBAC", "AST", "INJECTION", "GUARDRAILS"] }
}

如果被阻断，返回结构化错误：

{
  "status": "blocked",
  "error": { "stage": "RBAC", "reason": "table 'salaries' requires READ_WRITE, agent has READ_ONLY" }
}

Agent 看到的接口是一致的——无论通过 MCP 还是 REST 连接，同一套工具、同一套安全管道、同一份审计日志。

支持的数据库生态

Faz 支持 14 种数据库，覆盖了主流的关系、文档、搜索、向量和图数据库：

• 关系型：PostgreSQL、MySQL、Oracle
• 文档型：MongoDB、CouchDB
• 搜索引擎：Elasticsearch、OpenSearch
• 向量数据库：Weaviate、Qdrant、Milvus、Pinecone
• 图数据库：Neo4j
• 宽列：Cassandra
• 云：DynamoDB

这意味着你可以用一套安全策略覆盖微服务架构中的所有数据存储，而不需要为每种数据库单独配置权限。

不适合什么场景

Faz 解决的是”Agent 查询数据库时的安全”，不是所有问题的银弹：

• 文件系统安全：如果 Agent 有 Shell 访问权限，Faz 的保护范围不覆盖文件读写。需要配合系统级的 RBAC 或容器隔离。
• 已有数据层的脱敏：Faz 拦截和执行查询，但它不负责对查询结果做 PII 脱敏。如果你需要在返回值送到 Agent 前脱敏，可能需要配合 Gate 之类的数据层脱敏工具。
• 高并发生产查询：Faz 作为中间层会增加毫秒级的延迟。如果数据库本身就在承受每秒数千次的查询，应先在非生产环境验证性能影响。

与同类工具的对比

总结

Faz 填补了一个之前被忽视的安全间隙：AI Agent 获得数据库访问权限后，谁来检查它们的每一次操作。传统思路是给 Agent 一个只读用户就完事了，但现代 AI Agent 的工作流需要读、写甚至跨库联合查询，权限需求远远超过”一个只读账号”。

五层安全管道、原生 MCP 工具、14 种数据库覆盖——Faz 把数据库安全从”信任 Agent 不犯错”变成了”假设 Agent 可能犯错，逐层封锁”。对于任何在生产环境中使用 AI 编码工具并连接了数据库的团队，这是一个值得纳入基础设施的工具。

相关链接

• Faz GitHub 仓库 — Apache-2.0 开源
• Faz 官方文档
• Faz Quickstart 指南
• Faz 五层安全管道详解
• PyPI 包：faz-core