只要 AI agent 开始动真格，它迟早要访问 Git 仓库、MCP 服务、云 API、内部后台或第三方系统。很多系统的第一反应很直接：把 token 放进环境变量，然后让 agent 在需要时去读。
这套做法的问题不在“能不能跑起来”，而在于它默认接受了一个危险前提：生成出来的代码、prompt 注入内容、第三方工具和模型自身，都不会碰这些凭证。这个前提在真实系统里几乎站不住。
更稳的方式不是“把 token 藏深一点”，而是做 credential delegation：凭证属于系统，不属于 agent；agent 只能提交一个受控动作请求，由 vault proxy 代它完成认证与调用。建议先结合 AI agent 数据脱敏实践、AI agent 安全与权限边界、AI agent Tool Registry 治理 和 AI agent Policy Engine 规则分层 一起看。
Secrets 不该跟着 agent 一起进沙箱
最危险的做法，是把下面这些东西都放进同一环境：
- 可执行代码
- 生成中的草稿
- 可读写文件系统
- 长期有效凭证
这样一来，任何一个 prompt injection、工具越权或生成代码自检脚本，都可能顺着运行环境把 token 带出去。问题不在模型是不是“恶意”，而在系统根本没设计边界。
更稳的做法：凭证随资源走，agent 只拿到能力，不拿到秘密
一个可执行的最小模型通常包含三层：
| 层级 | 负责什么 |
|---|---|
| vault | 存放真实凭证、轮转密钥、吊销与审计 |
| proxy | 根据 session 或 run 的受控身份代发请求 |
| agent | 提交动作意图，例如 clone、push、call tool |
这意味着 agent 知道“我可以对 repo A 执行 push”，但它不知道 push 用的 token 长什么样。
例如 Git 场景里，更稳的做法是：在 sandbox provisioning 时把远端凭证注入到 git remote，agent 只能执行 git push，却拿不到裸 token。MCP 场景里，则由代理层根据 sessionId 去 vault 取对应 OAuth 凭证，再代发给外部系统。
失败案例：排查脚本打印了环境变量，结果把内部 token 带进日志
一次常见事故发生在调试阶段。团队让 agent 在 sandbox 里运行诊断脚本，脚本为了排查配置问题打印了大量环境变量，CI 日志随后被观测平台完整采集。最后导致的不是代码错误，而是内部 token 出现在了日志系统里。
这个事故说明了一个经常被低估的事实：就算没有恶意 prompt injection，只要 token 进了执行环境，它就迟早会遇到“被脚本误打出来”“被工具上报出去”或“被异常堆栈带出”的风险。
真正的修复动作通常是：
- 长期 token 不进入 sandbox
- sandbox 只拿到一次性或作用域极小的 delegated capability
- 所有对外动作都走 proxy，并在 proxy 层打审计日志
凭证代理要解决的不只是安全，还有解释性
很多系统把 credential delegation 理解成“别泄露 token”。这当然重要，但还有一个同样关键的收益：可解释。
当一次外部动作发生时，系统最好能回答：
- 是哪个 run 发起的
- 用的是哪类能力，而不是哪串秘钥
- 动作是否经过 policy 审批
- 凭证 scope 是否匹配当时的权限边界
如果你只能知道“某个 token 调了某个 API”，而不知道“哪次 agent 任务在什么规则下触发了这次调用”，那仍然很难做追责与回滚。
Credential Delegation Checklist
- 长期凭证是否保存在 vault，而不是执行环境
- agent 是否只拿到 capability，而不是裸 token
- Git、MCP、第三方 API 是否都经过 proxy 层中转
- 代理层是否按 session/run 做审计记录
- 凭证 scope 是否足够细，而不是全能 token
- 异常日志、诊断脚本和工具结果是否不会输出真实密钥
- 权限吊销或轮转后，旧会话是否能被及时收紧
这件事真正保护的是什么
Credential delegation 保护的，不只是秘钥本身，而是系统的信任模型。只要 token 还跟着 agent 一起在沙箱里跑，任何关于“权限边界”“最小授权”“可审计调用”的承诺都会被打折。把秘密留在系统，把动作能力交给 agent，才是更接近生产级的做法。
延伸阅读：
