如何防止AI编程导致敏感信息泄露?

把整段代码丢进 AI 对话框之前，很多人其实已经下意识做了一件事：默认“这次只是让它帮忙改逻辑，应该不会出事”。敏感信息泄露，往往就卡在这种松弛里——密钥、令牌、生产配置、内部业务说明，一旦作为上下文送出去，就不再只是“本地仓库里的私货”，而变成了你未必能完全控制去向的材料。

先分清什么能进提示

AI 编程真正危险的，不是它写错一行判断，而是你把本不该外传的东西当成了“方便它理解项目的背景”。仓库里的凭据、个人数据、生产环境配置和内部业务资料，都不该直接塞进提示。哪怕某次生成结果里看起来没有复述这些内容，也不能把“暂时没爆”当成隔离措施。

更稳妥的做法是按敏感程度做简单分类：通用业务逻辑可以正常辅助；涉及身份、权限、核心规则或内部数据结构的，尽量缩小发送范围，改用脱敏示例，或由人用文字描述接口约束。生产凭据则始终与代码、提示分离，继续走既有的权限体系，而不是“为了让 AI 跑通先贴一下”。

权限别跟着“方便”一起放大

泄露不只发生在粘贴框里。给 AI 辅助账号、仓库访问权、自动化执行权时，最小必要原则同样适用：能读代码，不等于能合并、发布、改配置或碰生产数据。尤其是那些能自动改文件、跑命令、提交变更的代理式工具，作用范围要收紧，并保留可追踪的操作记录。否则一次误授权，敏感面会被工具链路放大，而不只是某段提示词。

审查时也不要只盯代码风格。核对变更范围里有没有顺手改掉配置和权限；依赖项是否来路清楚；认证相关改动是否扩大了字段暴露或令牌范围。自动检查能扫掉一部分明显问题，但“该不该让 AI 看见这些材料”“这次合并是否把秘密带进了共享分支”，仍然要人拍板。

测试和回滚看起来像质量流程，其实也在挡泄露的后路：变更要可识别、可恢复，出问题能退回上一可用状态，而不是发现密钥已经写进日志或示例配置后才开始翻历史。小团队不必上复杂审批，但至少要在合并前问清：上下文清过没有，账号权限是否过宽，有没有把内部资料当示例留下。

AI 能缩短写代码的时间，却不会替你承担“谁看见了什么”的责任。你更愿意为了效率多贴一点上下文，还是为了可控多花两分钟做脱敏和权限裁剪？这个选择，往往比模型本身更能决定敏感信息会不会被悄悄带出门。