原文：https://dev.to/cyclopt_dimitrisk/your-secrets-dont-need-a-git-commit-to-leak-into-an-ai-tool-be2（作者 @cyclopt_dimitrisk）
我们大多数人早就被训练出"不要把密钥提交进仓库"的条件反射。pre-commit 钩子、CI 里的密钥扫描、.env 写进 .gitignore。这些都很好，它们覆盖了仓库。
但它们覆盖不了上下文窗口。
缺口：仓库不再是边界
当你和 AI 编程助手一起工作时，离开你机器的不只是你正在编辑的那个文件。还包括你粘贴进去的任何内容、插件自行判定为相关的任何内容，以及 agent 在"帮忙"过程中读到的任何内容。安全边界现在包含了编辑器扩展、聊天历史、任何遥测数据，以及这段上下文在去往模型和返回途中经过的每一个服务。
密钥扫描器盯着 commit。而在典型配置里，没有任何东西盯着你晚上六点部署失败时粘贴进聊天面板的内容。
以下是密钥在完全不碰 git 的情况下进入上下文的几种常见方式。
1. 打印出自己配置的失败测试
一个集成测试挂了。断言信息很贴心地 dump 出整个 client 对象，其中包含内联了密码的连接串。你把整段测试输出复制进助手，问"这为什么会失败？"
你问的是断言，发出去的载荷里却带着凭据。
2. 环境变量导出
$ env | sort ... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgres://app:...@db.internal:5432/prod STRIPE_SECRET_KEY=sk_live_...
"这是我的环境，为什么应用找不到配置？"是再正常不过的调试动作。它同时也是一次粘贴就把机器上所有密钥交出去的最快方式。能执行 shell 命令的 agent，只要你放行，它自己也能这么干。
3. 日志记得太多
某个 verbose 的 HTTP 客户端会把请求头写进日志，其中一个是 Authorization: Bearer ...。你粘了 200 行日志去求助超时问题，第 143 行是一个还在生效的令牌。
4. 复制来的代码片段
有人在 Slack 里分享了一个"能跑的例子"，密钥还留在里面。你把它粘进助手做适配。现在它同时存在于两个你无法控制的系统里，而不是一个。
（以上是示例场景，不是具体事件；不过只要你曾在压力下调试过东西，大概率至少见过其中一种。）
真正有用的做法
- 尽量减少发送内容。 粘相关的十行，而不是整份日志。问错误本身，而不是问环境。
- 粘贴前先脱敏。 把令牌、连接串和请求头遮掉。写一个小 shell 函数或编辑器片段来清洗明显的模式，很值得。
- 给凭据收窄权限。 如果开发密钥真的泄露了，它也应该只能碰开发环境。短时效、最小权限的密钥能缩小爆炸半径。
- 弄清你的工具怎么处理数据。 保留什么、保留多久、是否用于训练、插件会自动发送什么、遥测发往哪里。这些通常是各自独立的设置与独立的策略，一个"隐私"开关很少能全部回答。
- 限制 agent 能读什么。 如果你的助手能打开文件、执行命令，就把
.env、凭据文件和密钥存储挡在它够不着的地方。
如果已经发生了
删掉聊天消息不叫补救。你不知道在按下删除之前有哪些内容被记录、缓存或转发过。当成一次普通的暴露事件来处理：轮换凭据、吊销旧的、查访问日志看有没有被使用。
换个视角
密钥管理过去是版本控制的问题。有 AI 工具参与之后，它变成了数据流的问题：任何进入模型上下文的东西，某种意义上都已经离开了你的控制。
最安全的密钥，是从来没有进入过上下文的那个。
你们团队现在怎么处理这件事？有没有什么工具在检查进入 AI 助手的内容，还是全靠开发者的习惯？
原文：https://dev.to/cyclopt_dimitrisk/your-secrets-dont-need-a-git-commit-to-leak-into-an-ai-tool-be2（作者 @cyclopt_dimitrisk）
