别再把 API Key 随手丢进 Prompt 了，这其实是个严重的潜在安全漏洞
最近一个针对 2.7 万条真实 ChatGPT 对话记录的数据集扫描结果非常触目惊心：竟然有 3 个依然有效的 API Key 被直接从对话历史中翻了出来。这意味着即便是在看似私密的对话记录里，只要数据发生了同步、泄露或被用于训练，你的账户权限就处于裸奔状态。
最核心的问题在于，开发者往往低估了 Prompt 数据的流转路径。当你把密钥写在提示词里时，它不仅存在于你的输入框中，还会被记录在平台的 History 数据库里，甚至可能在某些 RAG（检索增强生成）系统的向量数据库中被索引。如果你的 Prompt 是通过 API 调用且开启了日志记录，那么任何能接触到日志的运维人员或第三方插件都能轻易获取你的密钥。
要彻底解决这个问题，最稳健的方案是在 Prompt 层面实现“解耦”。不要在提示词里写死任何敏感信息，而应该使用占位符（Placeholder）。例如，将 sk-xxxx... 替换为 {{API_KEY_PLACEHOLDER}}，然后在代码执行层面通过 .env 环境变量或 AWS Secrets Manager 等专业的密钥管理服务进行动态注入。
但即便在代码层面做了处理，在让 AI 审计代码或分析配置时，AI 仍有可能在输出结果中把敏感信息给“还原”出来。为了防止这种情况，我建议在 Prompt 中构建一套强制性的“脱敏过滤器”。
很多人的做法是简单地告诉 AI “不要泄露密钥”，但这在 LLM 的逻辑中属于“弱约束”，很容易被忽略。真正有效的方法是将脱敏定义为一项必须执行的原子步骤。你可以尝试使用下面这个经过验证的 Prompt 模板：
# Role: 安全敏感型代码审计专家
# Task: 对以下代码/配置进行分析，但必须执行严格的脱敏操作。
# Constraints:
1. 严禁在输出结果中直接显示任何形式的 API Key, Secret, Password 或 Token。
2. 发现敏感信息时，必须将其替换为 `[MASKED_SECRET]`。
3. 如果需要建议如何存储这些密钥，请推荐使用 .env 文件或 Secret Manager。
# Input Data:
{{your_code_or_prompt}}这套逻辑的精妙之处在于它将“脱敏”从一个建议变成了执行约束。通过定义 [MASKED_SECRET] 这个具体的替换目标，AI 在生成 Token 之前会先经过一道掩码过滤，从而在输出端拦截掉敏感字符。
在实际操作中，如果你在处理复杂的 .yaml 配置文件或 .json 密钥对，建议在调用此 Prompt 前，先用简单的正则过滤一遍输入端。这种“输入端脱敏 + 输出端掩码”的双重保障，才能真正避免 API Key 泄露导致的资损或数据泄露事故。
