nao安全机制全解：SQL只读守卫、行级安全与代码沙箱如何保护你的数据

【免费下载链接】nao nao is an open source analytics agent. (1) Create context with nao-core cli, (2) deploy nao chat interface for everyone项目地址https://gitcode.com/gh_mirrors/nao4/nao点击查看免费下载nao 是一款开源数据分析智能体analytics agent它让用户用自然语言就能查询业务数据库、生成图表和报告。但让 AI 连上数据库听起来就让人担心AI 会不会误删数据会不会越权看到别人的工资条它生成的代码会不会执行危险操作nao 的答案是一套纵深防御体系SQL 只读守卫、行级安全策略、代码沙箱。本文带你逐个拆解这三道防线是如何保护你的数据的。第一道防线SQL 只读守卫 ️nao 的 AI 通过execute_sql工具执行查询。默认情况下所有写操作都会被直接拦截只允许SELECT查询通过。只放行 SELECT 语句守卫逻辑位于 sql-filter.ts核心是一个写语句黑名单正则INSERT、UPDATE、DELETE、DROP、CREATE、ALTER、TRUNCATE、GRANT等关键字开头的语句一律拒绝。校验时会先剥离 SQL 注释、再按分号拆分多条语句逐条检查——任何一条带写操作整批拒绝。拦截后的提示也很直白Write SQL operations are disabled. Only SELECT queries are allowed.见 execute-sql.ts。如果团队确实需要写入能力必须在管理面板中手动开启Dangerous write permissions开关默认状态是关闭的。堵住数据库直通函数侧信道 ️这是最容易忽略、却最关键的一道检查。像 DuckDB 这类分析引擎支持postgres_query(...)、mysql_query(...)、sqlite_query(...)这类函数——它们以 SELECT 开头能通过只读关键字检查但实际效果是向另一个服务器发起连接并执行任意 SQL包括写入。nao 维护了一份直通函数黑名单postgres_query、postgres_execute、postgres_scan、mysql_query、sqlite_scan、json_execute_serialized_sql等无条件拦截即使管理员开启了写权限也不例外。代码注释里说得很清楚允许写用户自己的数据绝不意味着允许借此打通到别的服务器。更细致的是检测时会先把单引号字符串字面量打码再匹配防止字符串内容干扰判断同时保留双引号函数名因为 DuckDB 中postgres_query(…)同样是有效调用。数据库层面的第二重保险即使前面的校验器有疏漏数据层还有兜底。查询 nao 自身应用库时readonly-app-db.ts 会SQLite打开PRAGMA query_only ON数据库层面直接拒绝任何写入Postgres用SET TRANSACTION READ ONLY包裹查询事务任何逃逸的写语句在数据库层就被拒绝而且应用库查询只能看到按项目作用域生成的只读视图app-db-views.ts项目 ID 通过参数绑定而非字符串拼接注入每个项目只能看到自己的用量数据。第二道防线行级安全 只读守卫解决了AI 不能改数据行级安全Row-Level Security, RLS解决的是用户只能看到自己该看的数据。敏感表 用户组策略管理员先把标记为敏感的表登记进项目例如employees.salary这类字段所在的表定义在 user-group-row-security.ts。然后按**用户组User Group**配置每张表的访问策略策略含义full全表可见predicate只能看到满足谓词条件的行支持图形化条件组合或手写 SQL 谓词none/blocked完全不可见或带原因地封禁比如销售组可以看到regions EMEA的订单行而财务组可以看全表——同一张表不同人看到的行不同。谓词如何自动注入查询策略配置后nao 不会指望 AI自觉遵守。后端在执行仓库 SQL 前会先把行谓词送到 FastAPI 服务做语法校验与规范化warehouse-sql.service.ts在 CLI 侧row_security_guard.py 用 sqlglot 解析器把 SQL 解析成语法树找出所有基表引用把策略谓词强制注入到查询中——AI 无论写出什么 SQL最终执行的版本都已经带上了行过滤条件。这种事后强制改写比事前口头约定可靠得多安全不依赖模型的行为而是依赖执行管道本身。第三道防线代码沙箱 nao 的 AI 还能编写并运行 Python 代码处理 Excel、PDF、复杂计算。运行不受信的 AI 生成代码业界的标准答案是隔离执行——nao 用的是 execute-sandboxed-code.ts 中的虚拟机级沙箱。AI 代码在隔离 VM 中运行沙箱运行时基于 boxlite每次执行都发生在独立虚拟机内与宿主系统彻底隔离。运行时的可用性检查在 sandbox-runtime.ts 中完成Linux 环境需要/dev/kvm权限不支持时该工具会自动禁用而不是冒险降级。每个用户一个专属盒子沙箱是池化的复用虚拟机以降低成本但每个池化实例都带有ownerKey归属标记——属于某个用户和项目的沙箱其密钥和文件永远不会被分配给其他人。空闲 5 分钟后自动回收防止资源泄漏。密钥脱敏秘密不进模型的眼睛 沙箱内需要用到密钥比如访问第三方 API时密钥以环境变量形式注入 VM绝不写入代码文本。更重要的是反向保护沙箱执行产生的输出在回传给 AI 之前会经过 sandbox-secrets.ts 的redactSecretValues处理把所有出现的密钥值替换成[REDACTED:名称]占位符——即使 AI 自己写的代码不小心把密钥打印了出来它也读不到真正的值。纵深防御总结为什么三道防线缺一不可防线防的是什么关键实现SQL 只读守卫AI 误操作/越权修改数据sql-filter.ts 数据库只读事务行级安全用户看到不该看的行user-group-row-security.ts SQL 谓词注入代码沙箱AI 生成代码逃逸到宿主系统execute-sandboxed-code.ts 密钥脱敏这套设计的精髓在于**不信任任何单一环节**AI 可能说错话所以有 SQL 校验器兜底、校验器可能有 bug所以数据库层强制只读、策略可能配置不全所以行谓词由管道强制注入、代码可能行为失控所以虚拟机隔离。任何一层失效下一层仍在。想深入了解行级安全策略的完整类型定义与规范化逻辑user-group-row-security.tsCLI 侧的 SQL 守卫与谓词注入实现row_security_guard.py沙箱池化与所有权隔离的完整代码execute-sandboxed-code.ts应用库作用域视图生成app-db-views.ts相关测试覆盖了写权限拦截、行安全策略路由、沙箱密钥等场景位于 tests/ 目录可作为行为参考对于新手来说理解 nao 的安全模型只需记住一句话数据安全的责任不在 AI 身上而在那条从自然语言到SQL 执行的管道本身——每一道关卡都假设上一层可能失败。赞分享【免费下载链接】nao nao is an open source analytics agent. (1) Create context with nao-core cli, (2) deploy nao chat interface for everyone项目地址https://gitcode.com/gh_mirrors/nao4/nao点击查看免费下载相关推荐Boop安全机制深度解析沙箱环境如何保护你的数据安全Boop安全机制深度解析沙箱环境如何保护你的数据安全 在当今数字化时代数据安全已成为开发者和普通用户最关心的问题。Boop作为一款脚本化记事本工具其内置的开发工具桌面应用WeChatMsg终极指南微信聊天记录导出与年度聊天报告WeChatMsg终极指南微信聊天记录导出与年度聊天报告 当你要翻出三年前的那条消息时 你大概经历过这种时刻一条重要的聊天记录在微信里怎么都搜不到或者想mirrord 安全机制完全解读如何在连接中保护你的代码mirrord 安全机制完全解读如何在连接中保护你的代码 在云原生开发中如何安全地将本地代码连接到云环境是一个重要挑战。mirrord 通过多层安全机制确保开发工具云原生CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考