防止API Key泄露到大模型：从前端拦截到熵值分析

把包含生产环境数据库URI或AWS密钥的日志直接粘贴给Claude或ChatGPT，这种操作在开发圈太普遍了。很多公司靠网络层DLP（数据丢失防护）来把关，但实测发现这根本没用：要么得做侵入式的TLS解密导致延迟暴增，要么开发人员直接开手机热点绕过公司防火墙。真正的拦截应该发生在“意图产生”的瞬间，也就是浏览器DOM层。

要实现一个高效的本地拦截机制，不能只靠单一手段，得把正则匹配和熵值分析结合起来，且单次检测耗时必须控制在50ms以内，否则输入框会有明显的卡顿感。

一、高置信度正则匹配

对于有固定前缀和长度的凭证（比如GitHub Token或AWS Key），正则匹配是最快且最准的。这类凭证有明显的结构特征，误报率极低。

// 针对常见服务商的凭证识别正则
const SECRET_PATTERNS = {
  awsAccessKey: /^AKIA[0-9A-Z]{16}$/,
  githubPat: /^ghp_[a-zA-Z0-9]{36}$/,
  slackToken: /^xox[baprs]-[0-9a-zA-Z]{10,48}$/,
  stripeKey: /^sk_live_[0-9a-zA-Z]{24,}$/
};

function checkStructuredSecret(input) {
  for (const [provider, pattern] of Object.entries(SECRET_PATTERNS)) {
    if (pattern.test(input)) {
      return { detected: true, type: provider };
    }
  }
  return { detected: false };
}

二、应对随机字符串的香农熵（Shannon Entropy）分析

正则搞不定所有的密钥，尤其是那些没有固定前缀的随机UUID或自定义Secret。这时候需要引入信息论中的“熵”概念。简单来说，随机程度越高（字符分布越均匀）的字符串，越可能是密钥而非普通英文单词。

一个典型的英文句子熵值通常在3-4之间，而一个随机生成的API Key熵值往往会超过4.5。

// 计算字符串熵值的实操代码
function calculateEntropy(str) {
  const len = str.length;
  const frequencies = {};
  
  for (let i = 0; i < len; i++) {
    const char = str[i];
    frequencies[char] = (frequencies[char] || 0) + 1;
  }
  
  let entropy = 0;
  for (const char in frequencies) {
    const p = frequencies[char] / len;
    entropy -= p * Math.log2(p);
  }
  return entropy;
}

// 判定逻辑：长度 > 16 且 熵值 > 4.3 判定为高风险
const isHighEntropy = (text) => text.length > 16 && calculateEntropy(text) > 4.3;

三、实操部署建议与踩坑细节

在实际部署这种拦截工作流时，有几个关键点需要注意，否则会被开发同事吐槽：

• 拦截时机： 不要在 onChange 事件里同步运行复杂正则，建议用 requestIdleCallback 或者对输入内容做 300ms 的防抖处理，避免打字时页面卡死。
• 误报处理： 熵值分析会把长得像密钥的 Base64 编码字符串也抓出来。建议增加一个白名单机制，或者在检测到高熵字符串时，弹出轻量级的提示框（Toast）让用户确认，而不是强制拦截发送。
• 性能开销： 如果一次性粘贴了上万行的日志，正则遍历会导致浏览器主线程阻塞。建议对输入文本进行分片处理，每片最大 2KB，超过部分异步检测。

总结来看，想要在AI Agent时代保证数据安全，不能指望一个简单的防火墙，必须把安全检测前移到客户端。通过 正则(快速筛查) -> 熵值(深度检测) -> 异步提醒 这一套组合拳，可以在不破坏开发体验的前提下，有效拦截绝大多数的敏感信息外泄。