AI编程助手泄密风险：密钥绕过git进入上下文窗口

原文：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 的情况下进入上下文的几种常见方式。

一个集成测试挂了。断言信息很贴心地 dump 出整个 client 对象，其中包含内联了密码的连接串。你把整段测试输出复制进助手，问"这为什么会失败？"

你问的是断言，发出去的载荷里却带着凭据。

$ env | sort
...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgres://app:...@db.internal:5432/prod
STRIPE_SECRET_KEY=sk_live_...

"这是我的环境，为什么应用找不到配置？"是再正常不过的调试动作。它同时也是一次粘贴就把机器上所有密钥交出去的最快方式。能执行 shell 命令的 agent，只要你放行，它自己也能这么干。

某个 verbose 的 HTTP 客户端会把请求头写进日志，其中一个是 Authorization: Bearer ...。你粘了 200 行日志去求助超时问题，第 143 行是一个还在生效的令牌。

有人在 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）