AI编码助手的日志也会泄密：先划清明文边界
内容提要
阿里云提出AI日志三层保护方案：采集端脱敏、入库前治理、入库后加密。核心原则是明文边界优先，脱敏、对称加密、信封加密各适用于不同场景。Pilot默认不脱敏，规则难以覆盖全部秘密。建议在源端处理密钥，分离原始库与分析库，并控制留存与权限。
延伸解读
明文边界：日志治理的第一道设计题
文章提出，AI可观测性的首要问题不是记录多少，而是明文最远允许走到哪里。只有先划定这条边界，脱敏、加密和留存策略才不会互相冲突。对开发者而言，这意味着提示词、工具参数和模型回复都应纳入数据分类，而非继续当作普通调试文本。
三种保护方式并非强弱排名
脱敏适合电话、邮箱、Token等可稳定匹配且排障仍需可读的字段；对称加密适合单一安全域内需要恢复的完整请求；信封加密则把数据密钥与主密钥分开，采集侧只有公钥，能加密却不能解密。三者对应不同场景，选择取决于字段用途与访问范围。
默认不脱敏与规则覆盖的局限
阿里云方案中，Pilot的脱敏默认关闭，需管理员显式启用。规则匹配无法识别所有秘密，例如业务自定义令牌、被拆分的凭证或自然语言中的机密设计。文章来自产品提供方，未公开独立误报率、漏报率和性能数据，因此应视作架构参考，而非自动解决泄密的证明。
从日志盘点开始的落地动作
文章建议随机抽取20条代理工具日志，检查是否出现密钥、连接串、源码或个人信息；给每类字段标注必须检索、仅统计、必要时恢复或禁止采集；能在源端处理的秘密不要等入库后再脱敏；分离原始库与分析库并设置不同权限与留存时间；用自定义测试令牌验证规则命中情况。
Q&A
AI编码助手的日志为什么会成为泄密风险？
因为AI代理在排查问题时可能读取.env、数据库连接串或内部代码，并将这些内容连同终端输出写入工具日志。日志随后经OTLP进入共享平台，甚至被复制到测试分析环境，即使模型服务不保存输入，秘密也已沿可观测链路扩散。
阿里云提出的AI日志三层保护方案具体是哪三层？
第一层是在主机或开发者设备采集时处理；第二层是在写入日志库前由入口处理器统一治理；第三层是对已经入库的数据做转换并生成受保护的数据集。
脱敏、对称加密和信封加密分别适合什么场景？
脱敏适合电话、邮箱、Token等能稳定匹配且日常排障仍需大致可读的字段；对称加密适合单一安全域内、以后确实需要恢复的完整请求；信封加密用随机数据密钥加密正文，再用公钥加密数据密钥，把采集者与解密者权限分开，适合需要职责分离的场景。
LoongSuite Pilot的脱敏功能有什么关键限制？
Pilot的脱敏默认关闭，需要管理员显式启用。规则匹配也不可能识别所有秘密，例如业务自定义令牌、被拆分的凭证或自然语言中的机密设计。文章来自产品提供方，没有公开独立误报率、漏报率和性能数据，应视作架构参考而非自动解决泄密的证明。
团队今天可以做哪些日志盘点来降低泄密风险？
随机抽取20条代理工具日志，检查是否出现密钥、连接串、源码或个人信息；给每类字段标注必须检索、仅统计、必要时恢复或禁止采集；能在源端处理的秘密不要等入库后再脱敏；把原始库和分析库分开，设置不同权限与留存时间；用自定义测试令牌验证规则能否命中，并定期检查漏报与误报。
为什么说日志越全不等于治理越好？
收集无法说明用途、没有删除期限且无人负责解密审批的原文，只是在把一次局部泄密变成可长期检索的组织风险。更稳妥的做法是缩短明文路径，再扩大检测规则，最后才是延长审计留存。
