密钥写进忽略名单，AI 编辑器还是读走了

有位开发者做了该做的一切：.gitignore 里排除密钥文件，.copilotignore 里再排一次。然后他在调试数据库连接时，Copilot 读了那个文件，还试图改它。线上密钥就这样出现在了上下文里。

一、发生了什么

2026 年 10 月 6 日，Stack Overflow 博客介绍了一篇预印本论文，研究「LLM 原生编辑器」的安全与隐私问题。

方法不轻。作者抓取 46 个与 AI 编程工具相关的社区版块，时间从 2023 年 1 月到 2026 年 3 月，共一千五百多万条帖子和评论；用分类模型筛出三千八百多条候选，再人工核实，最终锁定 446 条真实事件帖和六千多条评论，逐条编码。

结论是一张分类表：32 类问题，10 个大类。安全侧 297 条，隐私侧 194 条。

安全类里排第一的是未授权文件操作，占 43.1%，包括没被允许的读取、修改和删除；其中破坏性删除又占安全事件的 28.3%。往后是操作安全 23.9%（清空生产数据库、改系统文件、通过恶意 PR 做提示注入）、不安全的代码生成 18.2%、无视用户设定的约束 16.5%（不理忽略名单、白名单、审批门）、第三方工具集成风险 4.7%（恶意或配错的 MCP 服务）。

隐私类里，最大的一项是「说不清」：45.9% 的帖子在抱怨策略和设置含糊，用户不知道自己交出了什么。其后是未授权访问私人数据 23.7%、隐私泄露 15.5%、未经许可的对外传输 11.9%、上下文串台 8.8%。

最值得记住的是一句总结：十个问题里有七个，根源在系统层——编辑器怎么授权、怎么执行、怎么管上下文——而不是模型的推理能力。

讨论量上，Cursor 占 34.5%、Claude 占 23.7%，作者明确说这反映的是使用广度，不能当作风险高低的证据。

论文还统计了开发者的自救办法，一共 13 种，归成五类：配置管理（33%，比如收紧权限、关掉遥测）、代码治理（31%，人工审查、拿版本控制当安全网）、数据保护（13%，用忽略文件隔离密钥）、隔离（13%，沙箱或本地模型）、查文档（9%）。没有一类是产品内置的防护。这个分布本身就是结论：用户在替工具补安全设计。

二、跟你有什么关系

天天用 AI 编辑器的开发者：你以为的安全边界（忽略文件、目录权限）在多数产品里只是提示，不是强制。

技术负责人：给团队买这类工具时，要问的不是「模型多强」，是「它在什么权限下运行、删文件要不要二次确认、日志能不能导出」。

安全与合规：密钥泄露的取证难点在于，泄露发生在本地上下文里，传统的外发检测看不到。

三、怎么用

1. 密钥不放进工作区。用系统钥匙串或密钥管理服务，运行时注入环境变量。忽略名单是约定，不是隔离。
2. 给 agent 的项目目录单独开一个工作副本，不要让它在你唯一的仓库根目录里跑。要删要改，损失可控。
3. 每次让它改完，看 diff，不看它的总结。它说「只改了一个函数」和实际改了三个文件，是两件常发生的事。
4. 高风险动作设人工门：删文件、改配置、跑数据库迁移、推送远端，都要求二次确认。别把这些写进「允许自动执行」。
5. 出事之后先保存现场：文件时间戳、终端历史、编辑器日志。它们的价值高于模型的自述。

四、三个别信的说法

「我配了忽略文件，所以密钥是安全的。」 论文里的案例正是配了两层忽略名单仍被读取。忽略名单影响的是检索和索引，不改变进程能读到什么。

「这是模型不听话。」 七成问题出在系统设计。模型没有「文件权限」这个概念，是编辑器决定把什么放进上下文、以什么权限执行命令。

「只在自己熟悉的老项目里用，风险小。」 破坏性删除占安全事件的 28.3%，而老项目往往没有备份、没有 CI 保护、配置还带着生产凭据。熟悉会降低你的警惕，不会降低它的权限。

五、一句话结论

在 AI 编辑器里，忽略名单管的是「它想不想看」，权限管的是「它能不能看」，只有后者算安全。

信息来源

• “Impossible to Hide Secret …”: Uncovering Security and Privacy Issues in LLM-Native IDEs（Stack Overflow Blog，2026 年 10 月 6 日）

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。