密钥在页面里不可见，并不代表它不会被送到错误的接收端。Langfuse在10月24日发布的4.70.0版本中，修复了Webhook与PostHog集成的一条边界：修改目标地址时，不能继续默默沿用此前存下的敏感凭据。风险不在于界面直接显示明文，而在于有写权限的人改变目的地后，下一次外发可能把旧秘密带过去。

快速看点：一，Webhook换URL后，保留秘密请求头却把值留空，会被服务器拒绝；二，如果提交的请求头集合完全为空，旧秘密头会被移除，而非悄悄跟随新地址；三，PostHog目标变化必须重新提供项目API密钥，不能只靠前端隐藏字段来保护已有凭据。

“只写不读”还需要限制秘密被用在哪里

企业AI平台通常会把提示词变更、任务事件或运行记录发送到外部系统。为了减少明文暴露，配置页可能只显示掩码，留空则代表保留原值。这种设计方便日常修改，却隐含了一个前提：原来的凭据仍然只服务于原来的接收端，而不是可以与任意新地址重新组合。

Langfuse此次修复前，Webhook修改URL可能保留已有秘密请求头，PostHog更换目标也可能保留已存项目密钥。有相关写权限的用户因此可能改变接收端，让旧凭据随下一次投递到达新的位置。这是权限与凭据使用范围之间的关系，不是任何未登录访客都能读取全部密钥，也不是所有AI平台都有同一问题。

修复于10月23日合入，次日进入4.70.0正式版本。它与此前的评分导出来历字段、评测逐项比较及自托管加密模式属于不同事件：前者关注记录关联或运行条件，本次关注“目标改变以后，旧秘密是否仍可被继续使用”。不能因版本相邻就把几个功能的安全保证相互替代。

留空、重填与移除，是三种不同的更新

服务器先比较新旧目的地，再处理请求头。如果URL已变，而请求仍包含一个已有秘密头、却把值留空，更新会收到错误，不能把空字符串解释为无条件复用。重新提供秘密值后可以继续配置，但这并不自动保证该值属于新接收端；操作者仍需确认目标、凭据权限及审批是否正确。

另一条路径更容易被误读：如果请求头集合完全为空，修复会保留普通头，但跳过旧秘密头。也就是说，删除所有行再保存与保留秘密行但不填值，不是同一行为；前者可能成功更新地址，却不再带上原来的秘密凭据。旧自动化如果依赖这些头，后续认证失败也需要被监控，而不能只检查保存是否成功。

目的地比较使用标准URL解析后的完整地址，并非只比较域名。域名大小写或根路径的规范化差异可以被视为同一地址；实际路径等内容改变仍可能触发重新确认。因此，同一个域名下换接口，也不能一概认为可以沿用秘密。部署方更不应把这条校验当成任意网络出口的白名单。

后端拦截之外，还要验证已有自动化

PostHog更新同样在服务器检查：已有集成的目标地址变化时，如果未提供新项目密钥，就拒绝保存；目标不变时，空值仍可保留已有加密密钥。代码还保留集成写权限与地址有效性检查。这里保护的是特定配置更新路径，不等于取消了权限管理、接收端验证或日常审计。

回归测试覆盖了换地址留空被拒绝、完全不提交头时移除秘密、重新输入后接受，以及地址未变时继续保留等分支。PostHog测试还检查拒绝后旧地址未被改写。本文检查了代码和测试定义，没有在生产环境执行攻击或运行上游整套测试，也没有证据把风险描述成已经发生的客户泄露事件。

小编判断：凭据保护不能止步于加密存储

这次改动提醒实施团队，把“能否看到密钥”与“能让系统把密钥用到哪里”分开审查。升级验证应覆盖目的地变化、留空、删除、重填及失败回执，而不只是确认页面仍显示掩码。涉及环境迁移、供应商切换或Webhook接收端调整时，目标与秘密应作为一组受控配置。

边界也必须说清：此次不会自动轮换已经存下的秘密，也不改变Langfuse自带Webhook签名密钥的处理，更不替代对历史外发记录的检查。如果团队怀疑此前配置曾被异常改动，应按自身流程核查并决定是否轮换。安全配置保存成功只是一步，真正的交付验收还要确认信息和权限最终到达了谁。