Agent 项目遇到数据安全问题怎么办？手把手教你面试回答

我们在开发 Agent 项目时，尤其是在做“文本转SQL”或“AI 辅助代码执行”功能时，常常会深刻体会到：在大模型（LLM）面前，必须贯彻“零信任（Zero Trust）”原则。 永远不要假设 AI 生成的内容是安全的，它既可能产生幻觉（Bugs），也可能被提示词注入（Attack）。

针对具体的 SQL 注入/删库风险 和 文件越权访问，我总结了一套 “三层防御体系”：

第一层：输入与生成阶段的“降维打击” (Prompt & Protocol)

拒绝直接 Text-to-SQL：
因为让 AI 直接生成 SQL 是非常危险的，因为 SQL 的语法太灵活，很难完全正则过滤。所以我们可以采用这样一种方案：Text-to-DSL (领域特定语言) 或 Text-to-JSON。

比如，不让 AI 生成 SELECT * FROM users WHERE age > 18，而是让 AI 生成 JSON 指令：

{ "action": "query", "target": "users", "filters": [{"field": "age", "op": "gt", "val": 18}] }

然后由后端代码（Java）解析这个 JSON，拼接成 SQL 或调用 ORM。这样，控制权回到了严谨的代码逻辑手中，彻底杜绝了 SQL 注入。

第二层：执行阶段的“硬核隔离” (Execution Sandbox & Analysis)

如果业务必须让 AI 生成复杂 SQL（比如做 BI 报表）或执行代码，我们可以实施以下硬限制：

1. SQL 语法树（AST）分析与拦截：

   • 在 SQL 执行前，引入 JSqlParser 或 Druid SQL Parser。
   • 解析 SQL 结构：解析出 AI 生成 SQL 的 AST（抽象语法树）。
   • 白名单策略：检查 AST 的根节点，必须是 SelectStatement。一旦发现 Drop, Delete, Update, Truncate 或 Alter 等写操作 Token，直接抛异常拒绝执行。
   • 全表扫描拦截：分析 Where 条件，如果没有索引列或 limit 限制，禁止执行，防止 AI 写出慢 SQL 拖垮数据库。

2. 数据库层面的“最小权限原则” (Least Privilege)：

   专门为 Agent 创建一个 只读数据库账号 (readonly_user)，该账号在数据库层面被 REVOKE 掉了所有的 DML (Insert/Update/Delete) 和 DDL 权限。即使应用层防御失效，AI 真的把 DROP TABLE 发给了数据库，数据库也会直接报错 “Permission denied”。

3. 文件访问的路径归一化与沙箱：

   • 防路径穿越：AI 如果生成 ../../etc/passwd，Java 的 File 类直接读取是危险的。必须使用 Path.normalize() 清洗路径，并校验清洗后的路径是否以 “白名单目录”（如 /data/app/safe_zone/）开头。
   • 沙箱环境 (Sandbox)：
     如果 Agent 需要运行 Python 或 Shell 脚本来处理文件，绝对不能在 Java 主进程中运行 Runtime.exec()，我们可以使用 Docker 或 Firecracker MicroVM 启动一个临时的、断网的容器来运行这段代码。用完即丢弃。这样即便 AI 执行了 rm -rf /，也只是删除了一个临时容器，主服务器毫发无损。

第三层：业务兜底与审计 (Human-in-the-Loop)

1. 敏感操作的“人机协同”：

   对于涉及资金、配置修改或大量数据导出的操作，AI 只能生成“建议”，必须在前端弹窗，由拥有权限的管理员点击“确认”后，携带管理员的 Token 才能真正执行。

2. 全链路审计与熔断：

   所有的 AI 生成 SQL 和执行结果都必须异步写入审计日志（ELK）。

   • 设置 熔断机制：如果检测到 Agent 在短时间内连续触发 SQL 解析错误或权限拒绝（可能是正在遭受 Prompt 注入攻击），系统自动切断该 Agent 的执行权限并报警。

总结

简单来说就是：不信 AI（AST 解析校验）、不给权限（数据库只读）、关进笼子（Docker 沙箱）。

通过这套组合拳，即使 AI 被攻击者诱导生成了恶意代码，系统也能像 Seata 的 AT 模式 回滚事务一样，确保核心数据资产的绝对安全。