技术 · 熟练
你自建的那个 AI 网关，是最大的入口
一把上游钥匙，别配一个低权限用户
自建网关（自托管的模型代理）的好处在「一个入口管所有模型」，代价也在这里：全公司、全自动化的上游密钥都躺在这一层。2026-10 披露的两处缺陷正好打在这一点上 —— 低权限的网关用户能摸到管理面，另一处能顺着网关把上游密钥取走。这一页做四道闸：摸清谁能进来 · 把「网关自己的钥匙」和「上游的钥匙」分开 · 把自主浏览与工具调用当不可信执行 · 让轮换成为常规动作，而不是事故后的补救。
方法 · 一图看懂
1
先摸清入口 — 谁有账号、谁能进管理面、哪些自动化任务在用同一把 key
2
两类缺陷 — 越权触达管理面 · 顺着网关取走上游密钥
3
双钥匙分层 — 网关的访问凭据与上游供应商的 key 不放在同一处、不同权限面走不同入口
4
不可信执行 — 自主浏览与工具调用按外部不可信输入对待，别当成内部可信调用
5
轮换写进日历 — 生命周期固定化；泄露之后唯一能确定的是「它已经在别处了」
原理 · 为什么有效
网关把「分散的钥匙」换成了「集中的钥匙」，风险的性质也随之从「谁的 key 泄露」变成「这一层有没有被穿透」。它同时叠着三个角色：身份系统（谁能用哪个模型）· 密钥保管箱（上游 key 全在这）· 执行入口（agent 的工具调用从这里出去）。三者挤在一个进程里，任何一处配置松一点，另外两处的边界会一起失效。
所以打补丁只是止血：结构性动作是分层 —— 网关自己的访问凭据与上游供应商的密钥不放在同一处、管理面与调用面走不同入口、给自动化任务的 key 单独一套并且只开它需要的模型。
最后一条最容易被跳过：轮换不是出事才做，而是把密钥的生命周期写进日历。因为一旦泄露，你唯一能确定的事就是它已经在别处了 —— 这时候能做的只剩「换掉」和「查日志」，而这两件事都取决于你之前有没有留痕。
适用场景
适用：自建或自托管过模型网关（团队共用一把上游 key）· 给自动化任务分发过 key · 让 agent 直接调工具与浏览网页的人。
⛔ 不适用：只在自己机器上直连官方 API、没有任何中间层的人 —— 那要管的是账户与配额，不是网关暴露面。
⚠️ 前提：能拿到网关的版本号与配置入口。拿不到就别谈加固，先补这两样。
自测 · 5 问
我能说出谁有网关账号吗？其中几个能进管理面？
网关用的那套上游密钥，是不是和某个人本机上的密钥是同一把？
给自动化任务发的那把 key，能调的模型是不是只有它需要的那几个？
网关版本号是多少？上一次升级是什么时候？
如果今天这把上游 key 泄露，我要改几处配置、花多久？
怎么上手 · 验证步骤
先做一件五分钟能做完的事：把网关版本号写下来，对照上游修没修过那两处问题（低权限触达管理面 · 顺带取走上游密钥），没修就升级。
然后做第二件事：把密钥拆成两套 —— 「谁能用网关」的凭据，与「网关去调上游」的密钥，分别存放、分别轮换，且只有网关进程读得到后者。
第三件：给自动化任务单发一把 key，只开它需要的模型，并在日志里能按这把 key 追到每一次调用。三件事做完，再去看 agent 的工具权限 —— 顺序别反，先把门锁上，再谈谁能进屋。
自检动作：把网关的配置读一遍，回答一个问题 —— 如果现在有人拿到一个「只能调模型」的低权限账号，他能看到多少个其他账号的名字、能改哪些设置？答得出具体数字，说明你摸过这层；答不出，说明这层还是黑箱。