Database Security Framework

数据库安全框架

针对自主AI代理的生产测试数据库安全架构——行级安全、语句类型白名单、列级写权限和50多个表的最小权限强制。

______________________________________________________________________

问题

当AI代理需要访问数据库时，问题不是 *是否* 授予它——它是 *哪些表、哪些列、哪些操作、有哪些约束*.

大多数人工智能数据库集成分为两个阵营：完全访问（危险）或无访问（无用）。两者均未投入生产。管理财务工作流程、合规性检查和内容操作的自主代理需要广泛阅读，但需要手术式写作。它需要对数十个表进行SELECT访问，但需要对四个表进行INSERT权限。它需要在三个特定的表上具有DELETE功能，并且只能使用WHERE子句。

该框架在50多个表的PostgreSQL模式中解决了这个问题，该模式在14个版本中不断发展，没有发生任何数据丢失事件。它在数据库层实现了深度防御：每个表的行级安全性，每个查询的语句类型阻止，每次写入的列级白名单，以及每个结果集的输出限制。

最困难的部分不是技术实现。它正在发现缺少了什么。安全审计发现，在一个从其他角度来看都很安全的系统中，有8个实际错误隐藏在生产环境中——5个表没有RLS，3个视图有安全定义暴露。

______________________________________________________________________

建筑

┌─────────────────────────────────────────────────┐
│                 Agent Request                     │
└──────────────────────┬──────────────────────────┘
                       │
        ┌──────────────▼──────────────┐
        │    Input Router (Layer 0)    │
        │  MCP vs Webhook detection    │
        │  Defensive type-checking     │
        └──────────────┬──────────────┘
                       │
          ┌────────────▼────────────┐
          │  Operation Classifier    │
          │  READ path / WRITE path  │
          └─────┬──────────┬────────┘
                │          │
    ┌───────────▼───┐  ┌───▼───────────┐
    │  Safe SQL      │  │  Safe DB       │
    │  Query         │  │  Write         │
    │                │  │                │
    │  • SELECT only │  │  • Table       │
    │  • 7 blocked   │  │    whitelist   │
    │    statements  │  │  • Column      │
    │  • 50-row      │  │    whitelist   │
    │    output cap  │  │  • WHERE req   │
    │                │  │    on DELETE   │
    └───────┬───────┘  └───────┬───────┘
            │                  │
    ┌───────▼──────────────────▼───────┐
    │     PostgreSQL + Row-Level        │
    │         Security (RLS)            │
    │                                   │
    │  • RLS on all production tables   │
    │  • Service role policies          │
    │  • 4 namespaces (haios_, aos_,    │
    │    tgt_, mi_)                     │
    │  • Audit columns on all tables    │
    └───────────────────────────────────┘

组件

输入路由器（第0层） --框架级防御路由，检测请求是否通过MCP到达 execute_workflow 或webhook curl，通过不同的结构注入有效载荷(chatInput 对比 body.query).在执行任何数据库操作之前，类型检查这两种格式。这个bug在应用层是不可见的，只能通过跟踪跨框架边界的调用路径来诊断。

安全SQL查询（读取路径） --Webhook触发了只读服务。块7语句类型（INSERT、UPDATE、DELETE、DROP、ALTER、TRUNCATE、CREATE）。强制50行输出限制。返回具有行数和元数据的结构化结果。

安全数据库写入（写入路径） --Webhook触发了具有每表权限的写入服务：

• 插入白名单： 4个具有定义的允许列的特定表
• 更新白名单： 6个具有列级限制的表
• 删除： 仅限于3个表，强制WHERE子句要求
• 每次写入在执行前都会根据白名单进行验证

行级安全 --RLS已在所有生产表上启用。受控代理访问的服务角色策略。安全审计方法，系统地检查每个表和视图是否存在策略漏洞。

架构治理 --14次仅添加迁移（v1→ v7.14），带有强制性的7步变更清单：

1. 在架构主控中记录更改
2. 验证向后兼容性
3. 写入迁移SQL（仅限加法）
4. 隔离测试
5. 执行迁移
6. 验证数据完整性
7. 更新依赖文档

______________________________________________________________________

关键洞察

安全审计发现架构图遗漏了什么。

从每个设计文档来看，该系统看起来都很安全。RLS已“启用”。访问控制“到位”。但系统审计——检查每个表、每个视图、每个策略——发现了8个真正的错误：

• 5个表完全缺少行级安全性(api_costs, system_flags, compliance_checks, prohibited_products, health_checks)
• 使用SECURITY DEFINER的3个视图（以创建者权限而不是调用者权限执行）

这些不是理论上的漏洞。它们是一个已经运行了几个月的系统中的生产缺口。修复花了几分钟时间。找到它们需要一种方法来质疑“启用”在单个表级别的实际含义。

同样的模式出现在框架层。间歇性查询失败并非源于SQL或应用程序逻辑，而是源于MCP和webhook协议注入请求体的方式之间不可见的差异。除了两个框架相交的那一层，这个bug在每一层都是看不见的。

课程： “安全”不是二进制状态。这是一个要求逐个表、逐个视图、逐个调用路径验证的声明。

______________________________________________________________________

结果

______________________________________________________________________

框架级Bug

值得特别指出的是：输入路由问题。

n8n的MCP execute_workflow 和webhook curl 通过不同的有效载荷结构注入请求体。MCP发送 chatInput 在一条路上。Webhooks发送 body.query 在另一个。两者都到达同一个工作流节点。

结果：间歇性的数据库查询失败随机出现。有时查询有效，有时返回空结果。应用程序逻辑正确。SQL是正确的。只有当 *调用方法已更改* --除了两个框架之间的边界之外，每一层都看不见的东西。

修复方法：防御性输入路由类型检查两种格式。

$input.first().json.body?.query || $input.first().json.chatInput || ''

此模式在所有3个实用程序工作流中都是标准化的 --因为如果它发生过一次，那么它就会发生在两个相同系统相遇的任何地方。

______________________________________________________________________

为何重要

自治代理的最小权限访问控制与任何基础设施的最小权限权限访问控制是相同的问题。问题是相同的：哪些身份可以访问哪些资源，在哪个操作级别，附加什么条件。这里的答案恰好是关于人工智能代理和PostgreSQL模式的，但模式（按表分配、按列限制、对破坏性操作要求WHERE子句）是应用于新型主体的标准企业安全模型。

审计方法是可转移的部分。“RLS已启用”是一种设计声明。它是否真的在每个表、每个视图、每个调用路径上都启用了——这是一个验证问题。发现的8个错误不在设计中。他们处于架构所说的和生产系统所做的之间的差距。这种差距是每一个真正的安全失败的地方。找到它的方法是系统的、逐表的、检查实际状态而不是记录意图的方法，适用于任何“有保障”是索赔而不是衡量的系统。

______________________________________________________________________

构建于

• 数据库： Supabase（PostgreSQL+pgvector）
• 安全： 行级安全、服务角色策略
• 自动化： n8n（由webhook触发的服务）
• 协议： 模型上下文协议（MCP）
• 会议： 约50次迭代模式演化和安全强化

部分 HAIOS --自2024年10月以来，人工智能操作系统已投入生产。

______________________________________________________________________

许可证

麻省理工学院

作者

乔丹·韦克斯曼 —

14年的运营领导经验——自2025年以来构建人工智能基础设施。十字路口是护城河。