AI 开发防泄露清单：10 条可落地的团队实践

在 AI 已经深度进入日常开发的今天，团队效率提升很明显，但新的泄露面也在同步扩大。
很多安全事故不是来自“被黑”，而是来自日常操作：把 token 粘贴进对话、把带敏感信息的日志发给 AI、把 .env 误提交到仓库。

这篇文章整理一份可直接执行的通用工程清单，帮助团队在“用好 AI”的同时，把泄露风险降到可控范围。

1. 不把密钥直接发给 AI

• 不在对话中粘贴 token、API key、.env 全文、生产数据库连接串。
• 发给 AI 前先脱敏：统一替换为 ***REDACTED***。
• 只提供定位问题所需的最小上下文，不贴完整日志。

2. 密钥不进仓库

• .env 仅本地使用，确保 .gitignore 生效。
• 仓库仅保留 .env.example，且示例必须是假值。
• 严禁把真实凭证写入代码、脚本和文档。

3. 最小权限原则

• 每个系统使用独立凭证，不共用管理员密钥。
• 只授予必要 scope，避免全权限 token。
• 开发、测试、生产环境使用不同凭证。

4. 短期凭证与轮换

• 优先使用可过期凭证，而不是长期固定凭证。
• 发现疑似泄露时立即 revoke 并签发新 token。
• 建立定期轮换机制，避免凭证长期不变。

5. 日志与输出脱敏

• 终端输出和错误日志默认视为“可能外发”，必须屏蔽 Authorization、Cookie、token。
• 对运行日志和模型输出落盘目录做权限控制、留存周期和定期清理。

6. 自动化密钥扫描

• 本地提交前执行 secret scan（如 gitleaks）。
• CI 中强制扫描，发现疑似密钥直接阻断合并。
• 对历史提交做周期性扫描，清理旧泄露残留。

7. AI 平台数据策略

• 优先选择支持“数据不用于训练 / 可控保留期”的方案。
• 不向 AI 输入用户隐私、生产数据导出、核心业务密钥。
• 必须输入时先做脱敏和最小化抽样。

8. 运行环境隔离

• 给 AI agent 最小文件系统权限，只开放必要目录。
• 禁止 AI 直接访问生产控制面和高权限密钥。
• 将 AI 实验环境与正式环境隔离。

9. 事件响应流程（建议固化）

1. 发现泄露线索后，立即冻结/撤销相关凭证。
2. 替换新凭证并验证业务恢复。
3. 回溯泄露路径（对话、日志、提交、截图、共享文件）。
4. 清理暴露内容并补充自动化防护规则。

10. 团队落地最小基线（通用）

• 规范：禁止在 AI 对话中粘贴真实密钥和生产数据。
• 仓库：只提交 .env.example，真实配置通过密钥管理系统分发。
• 自动化：本地提交前 + CI 双重 secret scan。
• 运维：所有凭证支持快速轮换，并有应急演练机制。

结语

AI 不是安全例外区。
真正可持续的工程实践，不是“禁止使用 AI”，而是把 AI 纳入和代码、基础设施同等级的安全治理框架。

如果你的团队还没有开始，先从两件最小动作开始：
1）把“禁止粘贴真实密钥到 AI 对话”写进团队规范；
2）在 CI 上线 secret scan 阻断规则。
这两步通常就能拦住大部分可避免的泄露事故。