AI Agent 凭证网关怎么用：别把密钥塞进上下文
Agent 调 API、装依赖、推代码时最怕密钥进 prompt。本文讲凭证网关思路（以开源 OneCLI 为例）、适用边界，以及不装网关时的最低防护。
企业里落地 Agent，顾虑常常不是“会不会写代码”，而是凭证：一旦工具调用带着长效 token，agent 被诱导或日志外泄，密钥一起走。开源项目 OneCLI 的定位很清楚——credential gateway + vault：让 agent 能访问服务，却不把明文 key 暴露给模型上下文。本文讲清思路和落地顺序；是否采用 OneCLI 本身可替换为同类网关。
问题不在“Agent 太聪明”，在密钥出现在哪一层
常见错误姿势：
- 把
OPENAI_API_KEY、云厂商 AK/SK、GitHub PAT 写进系统提示或仓库.env再让 agent 通读。 - 让 agent 直接
echo $KEY或把密钥贴进 shell 历史。 - 用高权限 PAT 做日常 agent 自动化，出问题无法收敛爆炸半径。
相关风险与权限审计，可对照 AI 代理 GitHub 权限安全 与 自主运行风险防护。
凭证网关在架构上做什么
网关模式通常具备三层：
- Vault：密钥存放在网关侧，不进模型上下文。
- 代理调用：agent 申请“替我调某 API”，网关注入凭证完成请求，只把业务响应回给 agent。
- 策略：按工具、环境、时间限制可调用的目标，拒绝高危动作。
对模型来说，它看到的是“调用支付查询工具成功/失败”，而不是完整的 Bearer token。这和“把密钥加密后再塞进 prompt”不是一回事——后者模型仍可能见到密文或解密路径。
什么时候值得上网关
- 多个 agent / 多台机器共用一套云资源，又不想复制密钥。
- 需要审计：谁在什么时候用了哪类凭证。
- 密钥轮换频繁，不想改遍所有 prompt 与脚本。
个人本机、只用短时 gh 设备登录、从不让 agent 碰生产密钥——可以先用更轻的约束，不必一上来上完整网关。
不装网关时的最低防护清单
- 最小权限 token：仓库级 fine-grained PAT，只开必要 scope，设过期。
- 环境隔离：生产密钥不进开发 agent 会话；用独立 profile。
- 禁止回显：hooks / 规则明确禁止打印 env 中的
*KEY*、*SECRET*。 - 密钥扫描：CI 跑 gitleaks / trufflehog；agent 提交前先扫。
- 中转与隐私：若走中转 API，先读清数据路径，参见 中转 API 会不会泄露代码。
落地顺序（可复用）
- 列出 agent 真正需要的外部系统（GitHub、云、数据库、Slack…）。
- 每个系统单独凭证，禁止“万能 root key”。
- 能网关就网关；不能则短时凭证 + 人工审批高危工具。
- 演练一次“密钥疑似泄露”：轮换、吊销、查审计日志。
OneCLI 这类项目适合作为“网关怎么工作”的参考实现；上线前仍要看其威胁模型、加密存储方式和你公司的合规要求，不要因为 star 高就默认生产可用。
常见问题
网关会不会变成新的单点风险？
会。网关自身要加固、备份与访问控制。收益是把风险从“每个会话都可能漏 key”收拢到“守住一个受控组件”。
Agent 看不到 key，还能调试失败请求吗？
应返回脱敏错误（状态码、错误类型、request id），而不是完整 Authorization 头。调试信息够定位即可。
这和 MCP 是什么关系？
MCP 解决工具协议与发现；凭证网关解决密钥存放与注入。可以叠用：MCP 工具背后的实际 HTTP 调用走网关。