文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程3.1 无权限模型的问题3.2 Prompt限制无法解决越权4. 方案实施4.1 KFS MCP Server作为权限入口4.2 建立角色映射4.3 Schema级过滤4.4 SQL执行前检查4.5 数据行隔离4.6 工具调用示例5. 结果对比越权拦截率正常通过率审计完整性6. 风险与复盘风险一角色设计过粗风险二只限制表不限制数据行风险三权限配置变化不同步风险四日志泄露总结附录测试用例示例每日一句正能量有些东西你越抓得紧流失得越快不如顺其自然。握紧一把沙沙粒从指缝流走松开手反而能捧住更多。无论是感情、名利还是机会过度的执念会扭曲我们的行为导致动作变形反而加速失去。顺其自然不是躺平放弃而是尽力之后的不强求是一种从容的智慧。1. 背景与问题企业引入 AI Agent 查询数据库后最大的安全风险之一不是 SQL 写错而是 SQL 正确但查询了“不该看的数据”。传统系统中用户权限通常绑定在业务应用页面用户登录 → 菜单权限 → 页面按钮 → 后端接口但 AI Agent 改变了访问模式自然语言问题 → Agent理解 → 自动生成SQL → 调用数据库工具 → 返回答案用户不再点击固定页面而是通过语言表达需求。例如销售人员输入“查询华东区域客户订单情况”模型可能生成SELECT*FROMcustomer_order;SQL语法正确但如果销售部门只能查看自己的区域这就是越权查询。因此企业问数需要建立身份 角色 数据域 工具权限 SQL约束 审计的完整权限模型。2. 环境与数据示例环境PostgreSQL业务库KFS MCP ServerAI Agent问数助手数据包含customer(customer_id,customer_name,region,sales_owner)orders(order_id,customer_id,amount,department)finance_cost(product_id,cost_amount)组织结构销售部 客服部 财务部 运营部不同部门具有不同数据范围。例如销售只能看自己的客户财务可以查看成本客服只能查看服务相关信息3. 复现过程3.1 无权限模型的问题简单实现mcp.tool()defquery(sql):returndatabase.execute(sql)任何用户调用{tool:query,sql:select * from finance_cost}都会执行。问题Agent不知道用户身份SQL没有数据范围数据库账号权限过大。3.2 Prompt限制无法解决越权有人会尝试不要查询用户无权限数据但是Prompt不是安全边界。模型可能理解错误被复杂问题诱导忘记上下文约束。权限必须由服务端控制。4. 方案实施4.1 KFS MCP Server作为权限入口所有查询必须经过Agent ↓ KFS MCP Server ↓ 权限判断 ↓ SQL执行不能让Agent直接连接数据库。4.2 建立角色映射用户身份{user:zhangsan,department:sales,role:sales_manager}映射roles:sales_manager:tables:-customer-ordersrow_filter:region:user.regionfinance:tables:-finance_cost-orders4.3 Schema级过滤Schema检索阶段就过滤销售用户返回customer orders隐藏finance_cost salary这样Agent生成SQL时就减少越权机会。4.4 SQL执行前检查KFS MCP Server增加defcheck_permission(sql,role):tablesparse_tables(sql)allowedpolicy[role][tables]fortintables:iftnotinallowed:returnFalsereturnTrue生产环境建议结合SQL AST解析表血缘行级过滤。4.5 数据行隔离例如销售只能查询自己的区域自动增加ANDregion华东而不是让模型自己生成。核心原则用户不能控制权限条件 权限条件由系统注入4.6 工具调用示例Agent调用{name:query_readonly,arguments:{question:查询我的客户订单,user:zhangsan,role:sales_manager}}KFS处理1. 获取身份 2. 查询角色 3. 获取允许Schema 4. 生成SQL 5. 注入数据范围 6. 执行 7. 审计5. 结果对比权限模型效果不能只看查询成功率。重点指标越权拦截率测试1000条越权请求统计成功阻断数量正常通过率避免安全全部拒绝审计完整性记录用户 角色 SQL 数据表 决策结果 时间示例指标改造前改造后越权SQL拦截率82%99.5%错误授权率5.1%0.2%审计覆盖率60%100%6. 风险与复盘风险一角色设计过粗例如销售全部客户实际可能需要销售区域 销售团队 个人客户权限模型必须支持层级。风险二只限制表不限制数据行允许select*fromorders但没有departmentuser.department仍然存在泄露风险。风险三权限配置变化不同步新增表customer_sensitive如果默认开放会产生风险。建议未知资源默认拒绝风险四日志泄露审计不要记录身份证号码 手机号明文只记录访问字段 策略结果 规则版本总结AI Agent权限安全不能依靠模型自觉而需要建立服务端控制链身份认证 → 角色映射 → Schema过滤 → SQL检查 → 行级隔离 → 工具执行 → 审计评估KFS MCP Server的核心价值是把AI Agent从“直接访问数据库”变成“经过权限治理的数据访问代理”。未来企业问数系统真正可靠的标准不是“AI能查多少数据”而是“AI只能查它应该看到的数据”。附录测试用例示例[{role:sales,sql:select * from orders,expect:allow_with_filter},{role:sales,sql:select * from finance_cost,expect:deny},{role:finance,sql:select * from finance_cost,expect:allow}]转载自https://blog.csdn.net/u014727709/article/details/163644447欢迎 点赞✍评论⭐收藏欢迎指正 【金仓数据库征文】AI Agent防止越权查询的权限模型——多部门数据问答中的隔离设计
文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程3.1 无权限模型的问题3.2 Prompt限制无法解决越权4. 方案实施4.1 KFS MCP Server作为权限入口4.2 建立角色映射4.3 Schema级过滤4.4 SQL执行前检查4.5 数据行隔离4.6 工具调用示例5. 结果对比越权拦截率正常通过率审计完整性6. 风险与复盘风险一角色设计过粗风险二只限制表不限制数据行风险三权限配置变化不同步风险四日志泄露总结附录测试用例示例每日一句正能量有些东西你越抓得紧流失得越快不如顺其自然。握紧一把沙沙粒从指缝流走松开手反而能捧住更多。无论是感情、名利还是机会过度的执念会扭曲我们的行为导致动作变形反而加速失去。顺其自然不是躺平放弃而是尽力之后的不强求是一种从容的智慧。1. 背景与问题企业引入 AI Agent 查询数据库后最大的安全风险之一不是 SQL 写错而是 SQL 正确但查询了“不该看的数据”。传统系统中用户权限通常绑定在业务应用页面用户登录 → 菜单权限 → 页面按钮 → 后端接口但 AI Agent 改变了访问模式自然语言问题 → Agent理解 → 自动生成SQL → 调用数据库工具 → 返回答案用户不再点击固定页面而是通过语言表达需求。例如销售人员输入“查询华东区域客户订单情况”模型可能生成SELECT*FROMcustomer_order;SQL语法正确但如果销售部门只能查看自己的区域这就是越权查询。因此企业问数需要建立身份 角色 数据域 工具权限 SQL约束 审计的完整权限模型。2. 环境与数据示例环境PostgreSQL业务库KFS MCP ServerAI Agent问数助手数据包含customer(customer_id,customer_name,region,sales_owner)orders(order_id,customer_id,amount,department)finance_cost(product_id,cost_amount)组织结构销售部 客服部 财务部 运营部不同部门具有不同数据范围。例如销售只能看自己的客户财务可以查看成本客服只能查看服务相关信息3. 复现过程3.1 无权限模型的问题简单实现mcp.tool()defquery(sql):returndatabase.execute(sql)任何用户调用{tool:query,sql:select * from finance_cost}都会执行。问题Agent不知道用户身份SQL没有数据范围数据库账号权限过大。3.2 Prompt限制无法解决越权有人会尝试不要查询用户无权限数据但是Prompt不是安全边界。模型可能理解错误被复杂问题诱导忘记上下文约束。权限必须由服务端控制。4. 方案实施4.1 KFS MCP Server作为权限入口所有查询必须经过Agent ↓ KFS MCP Server ↓ 权限判断 ↓ SQL执行不能让Agent直接连接数据库。4.2 建立角色映射用户身份{user:zhangsan,department:sales,role:sales_manager}映射roles:sales_manager:tables:-customer-ordersrow_filter:region:user.regionfinance:tables:-finance_cost-orders4.3 Schema级过滤Schema检索阶段就过滤销售用户返回customer orders隐藏finance_cost salary这样Agent生成SQL时就减少越权机会。4.4 SQL执行前检查KFS MCP Server增加defcheck_permission(sql,role):tablesparse_tables(sql)allowedpolicy[role][tables]fortintables:iftnotinallowed:returnFalsereturnTrue生产环境建议结合SQL AST解析表血缘行级过滤。4.5 数据行隔离例如销售只能查询自己的区域自动增加ANDregion华东而不是让模型自己生成。核心原则用户不能控制权限条件 权限条件由系统注入4.6 工具调用示例Agent调用{name:query_readonly,arguments:{question:查询我的客户订单,user:zhangsan,role:sales_manager}}KFS处理1. 获取身份 2. 查询角色 3. 获取允许Schema 4. 生成SQL 5. 注入数据范围 6. 执行 7. 审计5. 结果对比权限模型效果不能只看查询成功率。重点指标越权拦截率测试1000条越权请求统计成功阻断数量正常通过率避免安全全部拒绝审计完整性记录用户 角色 SQL 数据表 决策结果 时间示例指标改造前改造后越权SQL拦截率82%99.5%错误授权率5.1%0.2%审计覆盖率60%100%6. 风险与复盘风险一角色设计过粗例如销售全部客户实际可能需要销售区域 销售团队 个人客户权限模型必须支持层级。风险二只限制表不限制数据行允许select*fromorders但没有departmentuser.department仍然存在泄露风险。风险三权限配置变化不同步新增表customer_sensitive如果默认开放会产生风险。建议未知资源默认拒绝风险四日志泄露审计不要记录身份证号码 手机号明文只记录访问字段 策略结果 规则版本总结AI Agent权限安全不能依靠模型自觉而需要建立服务端控制链身份认证 → 角色映射 → Schema过滤 → SQL检查 → 行级隔离 → 工具执行 → 审计评估KFS MCP Server的核心价值是把AI Agent从“直接访问数据库”变成“经过权限治理的数据访问代理”。未来企业问数系统真正可靠的标准不是“AI能查多少数据”而是“AI只能查它应该看到的数据”。附录测试用例示例[{role:sales,sql:select * from orders,expect:allow_with_filter},{role:sales,sql:select * from finance_cost,expect:deny},{role:finance,sql:select * from finance_cost,expect:allow}]转载自https://blog.csdn.net/u014727709/article/details/163644447欢迎 点赞✍评论⭐收藏欢迎指正