密钥就像家门钥匙
密钥（API key、密码、令牌）就是你家的门钥匙——谁拿到它，谁就能以你的名义开门、花钱、调数据。所以钥匙该锁在保险柜里，而不是抄在便利贴上到处贴。
可很多人图省事，直接把密钥写进发给模型的提示里，比如“用这个 key=sk-xxxx 去调接口”。问题是：提示会被记录到日志、可能被发给第三方模型服务、也可能在出错信息里被原样打印出来。钥匙就这么从“保险柜”掉到了大马路上。
正确的钥匙保管法
更稳的做法是：密钥永远不进提示。把它放在程序的环境变量或专门的密钥管理服务里，由你的代码在真正要调接口的那一刻才取出来用，整个过程绕开模型。模型只管决定“要不要调这个工具”，具体拿钥匙开门的动作由你的代码完成。
# 反例：密钥被写进了给模型的提示（会进日志、可能外泄）
prompt = f"请用 key={SECRET_KEY} 调用支付接口" # 危险
# 正例：提示里不出现密钥；密钥由代码从环境变量取出，调用动作绕开模型
import os
api_key = os.environ["PAYMENT_API_KEY"] # 钥匙留在代码侧
prompt = "请判断是否需要调用支付接口（不要在意如何鉴权）"
# 模型只输出“要调”，真正带着 api_key 发请求的是下面这行你的代码
# pay_client.charge(amount, api_key=api_key)SSRF：别让它替坏人去敲内网的门
假设你的 Agent 有个工具叫“帮我访问这个网址并把内容拿回来”。坏人会塞给它一个内网地址，比如公司内部才能访问的管理后台或云服务器的“元数据接口”。Agent 在公司服务器上运行，它访问内网畅通无阻，于是替坏人把本来外人碰不到的内部数据取了回来。
这种“诱导服务端去访问它本不该访问的地址”的攻击，叫 SSRF（服务端请求伪造）。危险点在于：请求是从你可信的服务器发出去的，内网防火墙对它放行。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
判断：把 API 密钥直接写进发给模型的提示里很方便，而且只要任务做完密钥就自动消失了，所以是安全的。
答案：否
提示通常会被记录进日志、可能被发给第三方模型服务或在报错中打印，密钥不会“用完即消失”，反而容易外泄。
下面哪个是保管 Agent 所需密钥的更安全做法？
答案：把密钥放在环境变量或密钥管理服务里，调用时由代码取出、过程绕开模型
让密钥始终留在代码侧、不进入提示，是避免凭证经由模型链路外泄的关键。
判断：坏人诱导运行在公司服务器上的 Agent 去访问只有内网才能打开的管理后台，并把内容取回来——这属于 SSRF。
答案：是
SSRF 正是诱导服务端去请求它本不该访问的地址（如内网后台、元数据接口），借可信服务器绕过防火墙。
“诱导服务端去访问它本不该访问的地址（比如内网后台）”这种攻击的英文缩写是 ____（四个字母）。
答案：SSRF
SSRF = Server-Side Request Forgery，服务端请求伪造。
为一个“能根据网址抓取内容”的工具做防护，下面哪个做法最对症 SSRF？
答案：只允许访问白名单内的外部域名，禁止内网网段和云元数据地址
用白名单限制可访问目标、屏蔽内网与元数据地址，能从源头阻断 Agent 被诱导访问内部资源。
判断：既然密钥不该进提示，那让你的代码在真正调接口的那一刻才从环境变量取出密钥、整个鉴权过程不经过模型，是合理的做法。
答案：是
密钥留在代码侧、鉴权绕开模型，正是避免密钥经提示和模型链路外泄的推荐做法。