提示与密钥为什么分离
系统提示词属于文案资产，会经历评审、导出、分享与版本对比；密钥属于凭证，泄露即等于交出权限。二者生命周期不同，所以分开管理：提示按“可能被看到”来写，不放内部地址、账号与密钥；密钥由密钥管理服务或环境变量在运行时注入，权限收敛到最小范围，并具备轮换与吊销能力。
基本信息
| 原则 | 提示只描述任务，不放凭证与内部拓扑 |
|---|---|
| 注入方式 | 密钥管理服务或环境变量，优先使用短时凭证 |
| 权限 | 按服务与用途单独授权，只读优先 |
| 轮换 | 计划轮换与应急轮换两条路径都要预演 |
| 审计 | 密钥读取与使用留痕，异常调用可告警 |
典型使用场景
- 上线前自查：把提示词当成即将公开的文档读一遍，确认没有可被利用的信息
- 接入内部接口：调用层从密钥源取凭证，提示里只写调用订单查询接口这类描述
- 轮换演练：模拟密钥泄露，走一遍吊销、换发、验证流程并记录耗时
- 多环境共用服务：每个环境独立密钥，避免测试凭证能操作生产数据
- 审计告警：密钥被非预期服务读取时能定位到调用方
正例与反例对照
正例与反例对照
反例：提示词内直接写内部接口密钥与内网地址
正例：提示只描述任务目标，凭证在调用层注入
[secrets]
internal_api_key: ${SECRETS_STORE:internal_api_key} # 运行时注入，不落文件
scope: 只读、仅限本服务、有效期 15 分钟
rotation: 计划轮换 90 天；泄露时应急轮换按小时推进信息类型与处理方式
| 信息类型 | 处理方式 | 原因 |
|---|---|---|
| 接口密钥 | 密钥管理注入 | 泄露可直接被调用，必须可轮换 |
| 内网地址与拓扑 | 不写进提示 | 缩小攻击面，减少被探测的面 |
| 账号与口令 | 禁止出现 | 提示可能出现在输出、日志与导出文件中 |
| 业务规则口径 | 可写进提示 | 属于文案资产，需要版本化管理 |
系统提示要按可能被用户套出、可能被日志留存的假设设计。把不可外泄的内容放进提示，等于把风险交给模型的自制力。