文章目录每日一句正能量1. 背景与问题最危险的不是模型“说出来”而是模型“已经看到了”2. 环境与数据脱敏之前先解决“什么字段算敏感”2.1 建立字段分类元数据2.2 PostgreSQL 权限仍然是底层边界3. 复现过程先看三种常见但不够安全的脱敏方式3.1 错误方式一只靠 Prompt3.2 错误方式二只靠值正则3.3 错误方式三SQL 里直接写死掩码4. 方案实施在 KFS MCP Server 建立结果脱敏网关4.1 第一步先查权限再查数据4.2 第二步查询结果只能在 KFS 内部短暂停留为明文4.3 第三步建立角色 × 字段类型的策略矩阵4.4 第四步规则代码只操作已分类字段4.5 第五步未知敏感字段默认拒绝而不是默认透传4.6 第六步聚合结果通常不应该继续逐字段脱敏4.7 第七步KFS MCP Tool 的返回值必须显式声明已脱敏4.8 第八步MCP 层如何配合权限与审计5. 结果对比脱敏评测不能只看“看起来都打码了”5.1 漏脱敏率5.2 误脱敏率5.3 明文进入模型比例5.4 角色策略命中率5.5 审计覆盖率6. 风险与复盘脱敏不是“替换几个星号”这么简单6.1 风险一脱敏后仍可能被重识别6.2 风险二字符串拼接可能绕过列级规则6.3 风险三JSON / TEXT 大字段里可能嵌套 PII6.4 风险四数据库 RLS 角色选错会破坏隔离6.5 风险五数据分类元数据会过期6.6 风险六脱敏函数也要回归测试最终复盘第一层尽量少查第二层对必须查询的数据做服务端脱敏第三层限制模型对脱敏结果的使用第四层持续评测附录 A最小脱敏函数附录 BMCP 查询工具附录 C推荐审计字段每日一句正能量世界上任何书籍都不能带给你好运但是它们能让你悄悄成为你自己。读书的目的不是功利而是觉醒。读书不是许愿池不会直接带来财富或机遇。但它有一个更伟大的作用在日复一日的浸润中帮你剥去外界的噪音和偏见让你看清内心的模样。找到真正的“我”是比得到好运更珍贵的幸运。1. 背景与问题最危险的不是模型“说出来”而是模型“已经看到了”企业把 AI Agent 接入客户数据后一个非常常见的实现是用户问题 → Agent 生成 SQL → 数据库返回结果 → 把完整 rows 交给模型 → Prompt 要求模型不要输出手机号、身份证等敏感信息从产品表面看这似乎也实现了“脱敏”。例如数据库返回{customer_name:张三,mobile:13812345678,id_card:110101199001011234}模型最终回答客户张*手机号 138****5678。但这条链路存在一个根本问题脱敏发生得太晚。手机号、证件号等明文已经进入模型上下文。哪怕最终输出被 Prompt 约束住明文仍可能进入Agent 上下文模型请求日志TraceDebug 日志Prompt Cache会话历史二次工具调用参数。所以客户数据问答里真正应该控制的是数据库明文 ↓ KFS MCP Server ↓ 字段分类 ↓ 角色策略 ↓ 结果脱敏 ↓ Agent而不是数据库明文 ↓ Agent ↓ “请你不要泄露”这篇文章的核心原则是模型不需要看到的数据就不要先给模型。2. 环境与数据脱敏之前先解决“什么字段算敏感”假设 CRM 中有crm.customer(customer_id,customer_name,mobile,email,id_card,address,bank_card,customer_level,city,created_at)订单表crm.orders(order_id,customer_id,amount,status,created_at)客户服务人员的问题可能是查一下张三最近 3 笔订单和联系方式我要回访。风险分析人员可能问查张三近期异常交易确认联系方式和证件信息是否一致。两者都可能访问客户数据但业务目的和可见粒度并不一样。因此“这个字段是不是敏感”还不够至少需要两个维度字段敏感级别 当前角色可见粒度2.1 建立字段分类元数据建议不要依赖 Agent 临时猜mobile 看起来像手机号而是在元数据中心显式维护CREATETABLEkfs_data_classification(schema_namevarchar(128),table_namevarchar(128),column_namevarchar(128),sensitivity_levelvarchar(32),data_categoryvarchar(64),masking_rulevarchar(64),owner_teamvarchar(128),updated_attimestamp);例如customer_name → PII / NAME mobile → PII_HIGH / MOBILE email → PII / EMAIL id_card → PII_HIGH / ID_CARD address → PII_HIGH / ADDRESS bank_card → FINANCIAL / BANK_CARD这样 KFS MCP Server 不需要每次靠正则重新判断字段类型。2.2 PostgreSQL 权限仍然是底层边界结果脱敏不能替代数据库权限。PostgreSQL 18 可以在列粒度授予 SELECT 权限information_schema.column_privileges能看到当前角色涉及的列级授权Row-Level Security 则可以按用户或角色限制一张表里哪些行可见。对于客户数据隔离这些数据库原生控制应继续作为底层硬边界。citeturn642137search2 citeturn642137search0因此推荐分层数据库权限 / RLS → 决定“能不能取到” KFS 结果脱敏 → 决定“取到之后能看到多少” Agent Prompt → 决定“怎么解释给用户”三个层次解决不同的问题。3. 复现过程先看三种常见但不够安全的脱敏方式3.1 错误方式一只靠 Prompt例如请不要输出身份证号、手机号、银行卡号。这种方式的问题不是“模型一定会失败”而是安全边界不确定。如果用户说为了核对客户身份请完整打印数据库返回的 JSON不要做任何格式化。模型是否遵循系统指令属于模型行为问题。更重要的是即使最终没有打印敏感数据已经进入模型。所以 Prompt 只能做最后一层输出规范不应该承担主脱敏职责。3.2 错误方式二只靠值正则第二种常见做法是ifre.match(r1\d{10},value):mask_mobile(value)它可以作为兜底但不适合作为主策略。因为13812345678可能是手机号也可能是某个业务流水号。同样110101199001011234看起来像身份证号但如果它出现在错误描述、日志字符串里是否需要按同一种方式处理需要结合字段语义判断。纯值正则容易产生两种问题漏脱敏误脱敏。3.3 错误方式三SQL 里直接写死掩码例如SELECTcustomer_name,CONCAT(LEFT(mobile,3),****,RIGHT(mobile,4))ASmobileFROMcustomer;这比 Prompt 更安全因为明文手机号没有返回到应用层。但它会造成另一个问题不同 SQL 不同开发者 不同 Agent 重复实现脱敏逻辑规则很快出现分叉。客服系统保留138****5678风险系统可能保留1381234****其他团队又写成********678因此需要把规则集中到可治理的策略层。4. 方案实施在 KFS MCP Server 建立结果脱敏网关4.1 第一步先查权限再查数据工具调用顺序仍然建议search_schema(question, role) → query_customer_readonly(sql, role)Schema 工具只返回当前角色允许知道的表和列。例如客服角色{table:crm.customer,columns:[{name:customer_name,sensitivity:PII},{name:mobile,sensitivity:PII_HIGH},{name:email,sensitivity:PII},{name:city,sensitivity:INTERNAL}]}甚至可以完全不向客服角色暴露bank_card id_card如果业务确实不需要。注意这个原则最好的脱敏是根本不查询不需要的敏感字段。脱敏是第二选择最小化数据访问才是第一选择。4.2 第二步查询结果只能在 KFS 内部短暂停留为明文数据库执行cur.execute(sql)rows...此时明文结果已经进入 KFS MCP Server 内存。下一步不要returnrows而是立即masked_rowsmask_result(rowsrows,rolerole,schema_metadatametadata)只有masked_rows能成为 MCP Tool 的返回值。理想边界是明文允许存在 数据库 Buffer 数据库网络连接 KFS 受控内存 明文不允许进入 Agent Context LLM Request MCP Client Log 前端页面 普通应用 Trace4.3 第三步建立角色 × 字段类型的策略矩阵同一个字段对不同角色的展示粒度可以不同。例如字段原始值客服风控姓名张三张*张三手机13812345678138****56781381234****邮箱zhangsanexample.comz***example.comzha***example.com证件号1101011990010112341101**********1234110101********1234地址上海市浦东新区XX路88号上海市***上海市浦东新区***银行卡62220212345678901236222***********0123622202*********0123配置roles:customer_service:customer_name:name_partialmobile:mobile_standardemail:email_standardid_card:id_card_strictaddress:address_city_onlybank_card:bank_card_strictrisk_analyst:customer_name:passthroughmobile:mobile_extendedemail:email_extendedid_card:id_card_extendedaddress:address_districtbank_card:bank_card_extended安全上需要特别注意passthrough不能由 Agent 自己申请。必须来自身份 角色 数据策略 审批后的授权4.4 第四步规则代码只操作已分类字段一个最小手机号规则defmask_mobile(value:str)-str:returnvalue[:3]****value[-4:]邮箱defmask_email(value:str)-str:local,domainvalue.split(,1)returnlocal[:1]***domain证件号defmask_id_card(value:str)-str:returnvalue[:4]**10value[-4:]但是不要forevery stringinresult:try_detect_and_mask()更推荐column metadata → category → policy rule → mask function例如categorymetadata[(crm,customer,mobile)].data_category rulepolicy.resolve(rolecustomer_service,categorycategory)maskedrule.apply(value)这样一旦手机号格式变化、国际号码出现也只需修改 MOBILE 类规则。4.5 第五步未知敏感字段默认拒绝而不是默认透传这是很重要的一条生产规则。假设 DBA 新增customer.face_token但元数据分类任务还没有同步。系统不能因为没有匹配到 masking_rule就直接返回原值。对于受控客户表可以设置default_action:redact即已明确 PUBLIC/INTERNAL → 可以正常返回 已明确 PII → 按规则脱敏 分类未知 → REDACT / 拒绝安全系统里未知状态应该尽量 fail closed而不是 fail open。4.6 第六步聚合结果通常不应该继续逐字段脱敏用户问上海地区有多少客户SQLSELECTcity,COUNT(*)AScustomer_countFROMcustomerGROUPBYcity;返回{city:上海市,customer_count:182340}这里已经没有直接客户标识符。所以脱敏引擎还需要区分明细数据 聚合数据否则过度脱敏会损害问数价值。但聚合也不是天然安全。例如某个小区只有 1 名 VIP 客户如果同时返回足够多维度仍可能重新识别个人。所以成熟系统还可以增加small group suppression例如COUNT(*) 5 → 不返回具体分组本文不展开隐私计算但这个风险在客户数据问答里非常值得纳入后续治理。4.7 第七步KFS MCP Tool 的返回值必须显式声明已脱敏例如{ok:true,masked:true,policy_version:2026-08-01,role:customer_service,row_count:1,rows:[{customer_name:张*,mobile:138****5678,email:z***example.com}]}Agent System Prompt 可以继续规定不得根据上下文尝试还原脱敏值 不得提示用户推测被隐藏字符 不得将多个来源组合用于重识别。这时 Prompt 才处于正确位置它限制的是模型如何使用已经安全处理过的数据。而不是让模型替代安全处理本身。4.8 第八步MCP 层如何配合权限与审计MCP 2026-07-28 规范强化了无状态核心和授权能力请求可以携带客户端身份与能力工具名还可直接用于网关层路由和授权。对 KFS 来说这很适合把client identity role tool name纳入统一策略判断而不用把权限隐藏在长会话状态里。citeturn642137search1一次工具调用建议记录request_id client_id user_id role tool_name table_names selected_columns sensitive_columns policy_version masking_rules masked_field_count row_count elapsed_ms decision timestamp但日志本身必须注意不能把原始手机号、身份证号重新写进审计日志。可以记录columnmobile actionMASK rulemobile_standard而不是before13812345678 after138****5678否则脱敏系统会把敏感信息转移到日志系统。5. 结果对比脱敏评测不能只看“看起来都打码了”一个脱敏系统至少要同时评价两个错误方向。5.1 漏脱敏率定义应脱敏但仍以明文返回的字段数 / 所有应脱敏字段数目标应尽量接近 0。5.2 误脱敏率定义不应该脱敏却被处理的字段数 / 所有非敏感字段数例如订单编号13812345678只是刚好长得像手机号。如果正则把它处理成138****5678这就是误脱敏。因此元数据驱动通常比纯正则更稳定。5.3 明文进入模型比例这是本文最重要的安全指标之一发送给 LLM 的敏感明文字段 / 数据库返回的敏感明文字段理想状态0%5.4 角色策略命中率对于同一个测试样本customer_service risk_analyst是否得到预期不同的脱敏结果。5.5 审计覆盖率每一个敏感字段是否都能追溯为什么被返回 为什么打这个码 用了哪个策略版本 当前用户是什么角色一个演示评测可以呈现指标Prompt / 正则KFS 策略脱敏敏感字段漏脱敏率7.5%0%非敏感字段误脱敏率6.2%0.8%明文进入模型比例100%0%角色差异化弱强审计可追溯率52%100%以上数字属于演示基准用于说明评测方法不代表生产成绩。正式压测建议至少准备500 个字段样本 100 个手机号 100 个邮箱 100 个证件号 50 个银行卡号 50 个地址 50 个“长得像敏感值但实际不是”的普通字段 50 个角色差异化用例脱敏测试和 SQL 安全测试一样应该进入 CI。6. 风险与复盘脱敏不是“替换几个星号”这么简单6.1 风险一脱敏后仍可能被重识别例如城市 某县 年龄 57 客户等级 钻石 最近订单 某罕见产品即使没有姓名和手机号也可能通过组合信息定位到具体个人。所以客户数据安全不能只看单字段。后续还需要考虑最小分组 维度组合限制 聚合阈值 查询目的 导出限制6.2 风险二字符串拼接可能绕过列级规则例如 SQLSELECTmobile||-||id_cardASdetailFROMcustomer;返回字段名detail如果脱敏引擎只根据返回列名识别敏感数据就可能漏掉。因此生产系统需要AST 列血缘查询 projection lineage对表达式继承最高敏感级别或禁止未经登记的敏感列拼接表达式。简单规则PII_HIGH ANY → PII_HIGH比只看 alias 安全得多。6.3 风险三JSON / TEXT 大字段里可能嵌套 PII例如customer_ext JSONB内部可能有{emergency_mobile:13912345678}列级分类只能告诉你customer_ext 是敏感 JSON如果业务确实需要返回其中部分字段需要 JSON Path 级别策略。否则更安全的默认方式是整列拒绝。6.4 风险四数据库 RLS 角色选错会破坏隔离PostgreSQL Row-Level Security 能按角色限制行可见范围但超级用户和拥有BYPASSRLS的角色会绕过 RLS表所有者通常也不受普通 RLS 策略限制。citeturn642137search0所以 KFS 的查询账号不应为了方便配置成高权限数据库用户。推荐最小 SELECT 正确 RLS KFS 脱敏三层组合。6.5 风险五数据分类元数据会过期新增字段customer.wechat_id如果敏感分类两天后才同步这两天就是风险窗口。所以需要DDL 变更监听 → 新字段默认 UNKNOWN → UNKNOWN 默认 redact/deny → 分类审批 → 策略发布不能新字段默认 PUBLIC6.6 风险六脱敏函数也要回归测试国际手机号、单字姓名、极短邮箱、空值、异常银行卡长度都可能让规则产生意外结果。例如姓名王如果逻辑name[0]*会输出王*这实际上保留了完整姓名。所以每一种脱敏规则都需要正常值 边界值 空值 异常格式 国际格式测试。最终复盘AI Agent 查询结果脱敏可以拆成四层。第一层尽量少查Schema 权限 列权限 RLS不需要的数据根本不要返回。第二层对必须查询的数据做服务端脱敏字段分类 角色策略 masking function明文止步于 KFS MCP Server。第三层限制模型对脱敏结果的使用禁止还原 禁止重识别 禁止拼接推断Prompt 在这一层才真正合理。第四层持续评测漏脱敏率 误脱敏率 明文入模比例 策略命中率 审计覆盖率如果继续向生产推进建议按下面顺序实施建立客户数据字段分类目录先收紧数据库表、列和 RLS 权限在 KFS MCP Server 增加结果脱敏层建立角色 × 数据类型策略矩阵设置 UNKNOWN 字段默认拒绝或全遮罩增加表达式列血缘防止拼接绕过禁止明文写入普通日志和 Trace建立脱敏回归测试集对小样本聚合增加重识别风险控制持续统计漏脱敏与误脱敏。企业客户数据问答里最值得坚持的一条安全原则是不要把敏感明文交给模型再期待模型替你保密。更可靠的实现是先在 KFS MCP Server 把数据变成模型可以安全使用的形态再交给 Agent 推理。附录 A最小脱敏函数defmask_mobile(value:str)-str:ifnotvalue:returnvaluereturnvalue[:3]****value[-4:]defmask_email(value:str)-str:ifnotvalueornotinvalue:return***local,domainvalue.split(,1)returnlocal[:1]***domaindefmask_id_card(value:str)-str:ifnotvalue:returnvaluereturn(value[:4]**max(0,len(value)-8)value[-4:])附录 BMCP 查询工具mcp.tool()defquery_customer_readonly(sql:str,role:str,max_rows:int100)-dict:rowsexecute_readonly_sql(sql,max_rows)masked_rows[mask_row(row,role)forrowinrows]return{ok:True,masked:True,role:role,row_count:len(masked_rows),rows:masked_rows}附录 C推荐审计字段request_id user_id role tool_name tables selected_columns sensitive_columns policy_version masking_rules masked_field_count row_count decision elapsed_ms timestamp注意审计“发生了脱敏” 不要审计“脱敏前明文是什么”转载自https://blog.csdn.net/u014727709/article/details/163644362欢迎 点赞✍评论⭐收藏欢迎指正 【金仓数据库征文】AI Agent 查询结果脱敏实践——客户数据问答中，明文不该先进入模型
文章目录每日一句正能量1. 背景与问题最危险的不是模型“说出来”而是模型“已经看到了”2. 环境与数据脱敏之前先解决“什么字段算敏感”2.1 建立字段分类元数据2.2 PostgreSQL 权限仍然是底层边界3. 复现过程先看三种常见但不够安全的脱敏方式3.1 错误方式一只靠 Prompt3.2 错误方式二只靠值正则3.3 错误方式三SQL 里直接写死掩码4. 方案实施在 KFS MCP Server 建立结果脱敏网关4.1 第一步先查权限再查数据4.2 第二步查询结果只能在 KFS 内部短暂停留为明文4.3 第三步建立角色 × 字段类型的策略矩阵4.4 第四步规则代码只操作已分类字段4.5 第五步未知敏感字段默认拒绝而不是默认透传4.6 第六步聚合结果通常不应该继续逐字段脱敏4.7 第七步KFS MCP Tool 的返回值必须显式声明已脱敏4.8 第八步MCP 层如何配合权限与审计5. 结果对比脱敏评测不能只看“看起来都打码了”5.1 漏脱敏率5.2 误脱敏率5.3 明文进入模型比例5.4 角色策略命中率5.5 审计覆盖率6. 风险与复盘脱敏不是“替换几个星号”这么简单6.1 风险一脱敏后仍可能被重识别6.2 风险二字符串拼接可能绕过列级规则6.3 风险三JSON / TEXT 大字段里可能嵌套 PII6.4 风险四数据库 RLS 角色选错会破坏隔离6.5 风险五数据分类元数据会过期6.6 风险六脱敏函数也要回归测试最终复盘第一层尽量少查第二层对必须查询的数据做服务端脱敏第三层限制模型对脱敏结果的使用第四层持续评测附录 A最小脱敏函数附录 BMCP 查询工具附录 C推荐审计字段每日一句正能量世界上任何书籍都不能带给你好运但是它们能让你悄悄成为你自己。读书的目的不是功利而是觉醒。读书不是许愿池不会直接带来财富或机遇。但它有一个更伟大的作用在日复一日的浸润中帮你剥去外界的噪音和偏见让你看清内心的模样。找到真正的“我”是比得到好运更珍贵的幸运。1. 背景与问题最危险的不是模型“说出来”而是模型“已经看到了”企业把 AI Agent 接入客户数据后一个非常常见的实现是用户问题 → Agent 生成 SQL → 数据库返回结果 → 把完整 rows 交给模型 → Prompt 要求模型不要输出手机号、身份证等敏感信息从产品表面看这似乎也实现了“脱敏”。例如数据库返回{customer_name:张三,mobile:13812345678,id_card:110101199001011234}模型最终回答客户张*手机号 138****5678。但这条链路存在一个根本问题脱敏发生得太晚。手机号、证件号等明文已经进入模型上下文。哪怕最终输出被 Prompt 约束住明文仍可能进入Agent 上下文模型请求日志TraceDebug 日志Prompt Cache会话历史二次工具调用参数。所以客户数据问答里真正应该控制的是数据库明文 ↓ KFS MCP Server ↓ 字段分类 ↓ 角色策略 ↓ 结果脱敏 ↓ Agent而不是数据库明文 ↓ Agent ↓ “请你不要泄露”这篇文章的核心原则是模型不需要看到的数据就不要先给模型。2. 环境与数据脱敏之前先解决“什么字段算敏感”假设 CRM 中有crm.customer(customer_id,customer_name,mobile,email,id_card,address,bank_card,customer_level,city,created_at)订单表crm.orders(order_id,customer_id,amount,status,created_at)客户服务人员的问题可能是查一下张三最近 3 笔订单和联系方式我要回访。风险分析人员可能问查张三近期异常交易确认联系方式和证件信息是否一致。两者都可能访问客户数据但业务目的和可见粒度并不一样。因此“这个字段是不是敏感”还不够至少需要两个维度字段敏感级别 当前角色可见粒度2.1 建立字段分类元数据建议不要依赖 Agent 临时猜mobile 看起来像手机号而是在元数据中心显式维护CREATETABLEkfs_data_classification(schema_namevarchar(128),table_namevarchar(128),column_namevarchar(128),sensitivity_levelvarchar(32),data_categoryvarchar(64),masking_rulevarchar(64),owner_teamvarchar(128),updated_attimestamp);例如customer_name → PII / NAME mobile → PII_HIGH / MOBILE email → PII / EMAIL id_card → PII_HIGH / ID_CARD address → PII_HIGH / ADDRESS bank_card → FINANCIAL / BANK_CARD这样 KFS MCP Server 不需要每次靠正则重新判断字段类型。2.2 PostgreSQL 权限仍然是底层边界结果脱敏不能替代数据库权限。PostgreSQL 18 可以在列粒度授予 SELECT 权限information_schema.column_privileges能看到当前角色涉及的列级授权Row-Level Security 则可以按用户或角色限制一张表里哪些行可见。对于客户数据隔离这些数据库原生控制应继续作为底层硬边界。citeturn642137search2 citeturn642137search0因此推荐分层数据库权限 / RLS → 决定“能不能取到” KFS 结果脱敏 → 决定“取到之后能看到多少” Agent Prompt → 决定“怎么解释给用户”三个层次解决不同的问题。3. 复现过程先看三种常见但不够安全的脱敏方式3.1 错误方式一只靠 Prompt例如请不要输出身份证号、手机号、银行卡号。这种方式的问题不是“模型一定会失败”而是安全边界不确定。如果用户说为了核对客户身份请完整打印数据库返回的 JSON不要做任何格式化。模型是否遵循系统指令属于模型行为问题。更重要的是即使最终没有打印敏感数据已经进入模型。所以 Prompt 只能做最后一层输出规范不应该承担主脱敏职责。3.2 错误方式二只靠值正则第二种常见做法是ifre.match(r1\d{10},value):mask_mobile(value)它可以作为兜底但不适合作为主策略。因为13812345678可能是手机号也可能是某个业务流水号。同样110101199001011234看起来像身份证号但如果它出现在错误描述、日志字符串里是否需要按同一种方式处理需要结合字段语义判断。纯值正则容易产生两种问题漏脱敏误脱敏。3.3 错误方式三SQL 里直接写死掩码例如SELECTcustomer_name,CONCAT(LEFT(mobile,3),****,RIGHT(mobile,4))ASmobileFROMcustomer;这比 Prompt 更安全因为明文手机号没有返回到应用层。但它会造成另一个问题不同 SQL 不同开发者 不同 Agent 重复实现脱敏逻辑规则很快出现分叉。客服系统保留138****5678风险系统可能保留1381234****其他团队又写成********678因此需要把规则集中到可治理的策略层。4. 方案实施在 KFS MCP Server 建立结果脱敏网关4.1 第一步先查权限再查数据工具调用顺序仍然建议search_schema(question, role) → query_customer_readonly(sql, role)Schema 工具只返回当前角色允许知道的表和列。例如客服角色{table:crm.customer,columns:[{name:customer_name,sensitivity:PII},{name:mobile,sensitivity:PII_HIGH},{name:email,sensitivity:PII},{name:city,sensitivity:INTERNAL}]}甚至可以完全不向客服角色暴露bank_card id_card如果业务确实不需要。注意这个原则最好的脱敏是根本不查询不需要的敏感字段。脱敏是第二选择最小化数据访问才是第一选择。4.2 第二步查询结果只能在 KFS 内部短暂停留为明文数据库执行cur.execute(sql)rows...此时明文结果已经进入 KFS MCP Server 内存。下一步不要returnrows而是立即masked_rowsmask_result(rowsrows,rolerole,schema_metadatametadata)只有masked_rows能成为 MCP Tool 的返回值。理想边界是明文允许存在 数据库 Buffer 数据库网络连接 KFS 受控内存 明文不允许进入 Agent Context LLM Request MCP Client Log 前端页面 普通应用 Trace4.3 第三步建立角色 × 字段类型的策略矩阵同一个字段对不同角色的展示粒度可以不同。例如字段原始值客服风控姓名张三张*张三手机13812345678138****56781381234****邮箱zhangsanexample.comz***example.comzha***example.com证件号1101011990010112341101**********1234110101********1234地址上海市浦东新区XX路88号上海市***上海市浦东新区***银行卡62220212345678901236222***********0123622202*********0123配置roles:customer_service:customer_name:name_partialmobile:mobile_standardemail:email_standardid_card:id_card_strictaddress:address_city_onlybank_card:bank_card_strictrisk_analyst:customer_name:passthroughmobile:mobile_extendedemail:email_extendedid_card:id_card_extendedaddress:address_districtbank_card:bank_card_extended安全上需要特别注意passthrough不能由 Agent 自己申请。必须来自身份 角色 数据策略 审批后的授权4.4 第四步规则代码只操作已分类字段一个最小手机号规则defmask_mobile(value:str)-str:returnvalue[:3]****value[-4:]邮箱defmask_email(value:str)-str:local,domainvalue.split(,1)returnlocal[:1]***domain证件号defmask_id_card(value:str)-str:returnvalue[:4]**10value[-4:]但是不要forevery stringinresult:try_detect_and_mask()更推荐column metadata → category → policy rule → mask function例如categorymetadata[(crm,customer,mobile)].data_category rulepolicy.resolve(rolecustomer_service,categorycategory)maskedrule.apply(value)这样一旦手机号格式变化、国际号码出现也只需修改 MOBILE 类规则。4.5 第五步未知敏感字段默认拒绝而不是默认透传这是很重要的一条生产规则。假设 DBA 新增customer.face_token但元数据分类任务还没有同步。系统不能因为没有匹配到 masking_rule就直接返回原值。对于受控客户表可以设置default_action:redact即已明确 PUBLIC/INTERNAL → 可以正常返回 已明确 PII → 按规则脱敏 分类未知 → REDACT / 拒绝安全系统里未知状态应该尽量 fail closed而不是 fail open。4.6 第六步聚合结果通常不应该继续逐字段脱敏用户问上海地区有多少客户SQLSELECTcity,COUNT(*)AScustomer_countFROMcustomerGROUPBYcity;返回{city:上海市,customer_count:182340}这里已经没有直接客户标识符。所以脱敏引擎还需要区分明细数据 聚合数据否则过度脱敏会损害问数价值。但聚合也不是天然安全。例如某个小区只有 1 名 VIP 客户如果同时返回足够多维度仍可能重新识别个人。所以成熟系统还可以增加small group suppression例如COUNT(*) 5 → 不返回具体分组本文不展开隐私计算但这个风险在客户数据问答里非常值得纳入后续治理。4.7 第七步KFS MCP Tool 的返回值必须显式声明已脱敏例如{ok:true,masked:true,policy_version:2026-08-01,role:customer_service,row_count:1,rows:[{customer_name:张*,mobile:138****5678,email:z***example.com}]}Agent System Prompt 可以继续规定不得根据上下文尝试还原脱敏值 不得提示用户推测被隐藏字符 不得将多个来源组合用于重识别。这时 Prompt 才处于正确位置它限制的是模型如何使用已经安全处理过的数据。而不是让模型替代安全处理本身。4.8 第八步MCP 层如何配合权限与审计MCP 2026-07-28 规范强化了无状态核心和授权能力请求可以携带客户端身份与能力工具名还可直接用于网关层路由和授权。对 KFS 来说这很适合把client identity role tool name纳入统一策略判断而不用把权限隐藏在长会话状态里。citeturn642137search1一次工具调用建议记录request_id client_id user_id role tool_name table_names selected_columns sensitive_columns policy_version masking_rules masked_field_count row_count elapsed_ms decision timestamp但日志本身必须注意不能把原始手机号、身份证号重新写进审计日志。可以记录columnmobile actionMASK rulemobile_standard而不是before13812345678 after138****5678否则脱敏系统会把敏感信息转移到日志系统。5. 结果对比脱敏评测不能只看“看起来都打码了”一个脱敏系统至少要同时评价两个错误方向。5.1 漏脱敏率定义应脱敏但仍以明文返回的字段数 / 所有应脱敏字段数目标应尽量接近 0。5.2 误脱敏率定义不应该脱敏却被处理的字段数 / 所有非敏感字段数例如订单编号13812345678只是刚好长得像手机号。如果正则把它处理成138****5678这就是误脱敏。因此元数据驱动通常比纯正则更稳定。5.3 明文进入模型比例这是本文最重要的安全指标之一发送给 LLM 的敏感明文字段 / 数据库返回的敏感明文字段理想状态0%5.4 角色策略命中率对于同一个测试样本customer_service risk_analyst是否得到预期不同的脱敏结果。5.5 审计覆盖率每一个敏感字段是否都能追溯为什么被返回 为什么打这个码 用了哪个策略版本 当前用户是什么角色一个演示评测可以呈现指标Prompt / 正则KFS 策略脱敏敏感字段漏脱敏率7.5%0%非敏感字段误脱敏率6.2%0.8%明文进入模型比例100%0%角色差异化弱强审计可追溯率52%100%以上数字属于演示基准用于说明评测方法不代表生产成绩。正式压测建议至少准备500 个字段样本 100 个手机号 100 个邮箱 100 个证件号 50 个银行卡号 50 个地址 50 个“长得像敏感值但实际不是”的普通字段 50 个角色差异化用例脱敏测试和 SQL 安全测试一样应该进入 CI。6. 风险与复盘脱敏不是“替换几个星号”这么简单6.1 风险一脱敏后仍可能被重识别例如城市 某县 年龄 57 客户等级 钻石 最近订单 某罕见产品即使没有姓名和手机号也可能通过组合信息定位到具体个人。所以客户数据安全不能只看单字段。后续还需要考虑最小分组 维度组合限制 聚合阈值 查询目的 导出限制6.2 风险二字符串拼接可能绕过列级规则例如 SQLSELECTmobile||-||id_cardASdetailFROMcustomer;返回字段名detail如果脱敏引擎只根据返回列名识别敏感数据就可能漏掉。因此生产系统需要AST 列血缘查询 projection lineage对表达式继承最高敏感级别或禁止未经登记的敏感列拼接表达式。简单规则PII_HIGH ANY → PII_HIGH比只看 alias 安全得多。6.3 风险三JSON / TEXT 大字段里可能嵌套 PII例如customer_ext JSONB内部可能有{emergency_mobile:13912345678}列级分类只能告诉你customer_ext 是敏感 JSON如果业务确实需要返回其中部分字段需要 JSON Path 级别策略。否则更安全的默认方式是整列拒绝。6.4 风险四数据库 RLS 角色选错会破坏隔离PostgreSQL Row-Level Security 能按角色限制行可见范围但超级用户和拥有BYPASSRLS的角色会绕过 RLS表所有者通常也不受普通 RLS 策略限制。citeturn642137search0所以 KFS 的查询账号不应为了方便配置成高权限数据库用户。推荐最小 SELECT 正确 RLS KFS 脱敏三层组合。6.5 风险五数据分类元数据会过期新增字段customer.wechat_id如果敏感分类两天后才同步这两天就是风险窗口。所以需要DDL 变更监听 → 新字段默认 UNKNOWN → UNKNOWN 默认 redact/deny → 分类审批 → 策略发布不能新字段默认 PUBLIC6.6 风险六脱敏函数也要回归测试国际手机号、单字姓名、极短邮箱、空值、异常银行卡长度都可能让规则产生意外结果。例如姓名王如果逻辑name[0]*会输出王*这实际上保留了完整姓名。所以每一种脱敏规则都需要正常值 边界值 空值 异常格式 国际格式测试。最终复盘AI Agent 查询结果脱敏可以拆成四层。第一层尽量少查Schema 权限 列权限 RLS不需要的数据根本不要返回。第二层对必须查询的数据做服务端脱敏字段分类 角色策略 masking function明文止步于 KFS MCP Server。第三层限制模型对脱敏结果的使用禁止还原 禁止重识别 禁止拼接推断Prompt 在这一层才真正合理。第四层持续评测漏脱敏率 误脱敏率 明文入模比例 策略命中率 审计覆盖率如果继续向生产推进建议按下面顺序实施建立客户数据字段分类目录先收紧数据库表、列和 RLS 权限在 KFS MCP Server 增加结果脱敏层建立角色 × 数据类型策略矩阵设置 UNKNOWN 字段默认拒绝或全遮罩增加表达式列血缘防止拼接绕过禁止明文写入普通日志和 Trace建立脱敏回归测试集对小样本聚合增加重识别风险控制持续统计漏脱敏与误脱敏。企业客户数据问答里最值得坚持的一条安全原则是不要把敏感明文交给模型再期待模型替你保密。更可靠的实现是先在 KFS MCP Server 把数据变成模型可以安全使用的形态再交给 Agent 推理。附录 A最小脱敏函数defmask_mobile(value:str)-str:ifnotvalue:returnvaluereturnvalue[:3]****value[-4:]defmask_email(value:str)-str:ifnotvalueornotinvalue:return***local,domainvalue.split(,1)returnlocal[:1]***domaindefmask_id_card(value:str)-str:ifnotvalue:returnvaluereturn(value[:4]**max(0,len(value)-8)value[-4:])附录 BMCP 查询工具mcp.tool()defquery_customer_readonly(sql:str,role:str,max_rows:int100)-dict:rowsexecute_readonly_sql(sql,max_rows)masked_rows[mask_row(row,role)forrowinrows]return{ok:True,masked:True,role:role,row_count:len(masked_rows),rows:masked_rows}附录 C推荐审计字段request_id user_id role tool_name tables selected_columns sensitive_columns policy_version masking_rules masked_field_count row_count decision elapsed_ms timestamp注意审计“发生了脱敏” 不要审计“脱敏前明文是什么”转载自https://blog.csdn.net/u014727709/article/details/163644362欢迎 点赞✍评论⭐收藏欢迎指正