一、起因
AI coding agent 跑生产力的前提是:它能调真实的 API(GitHub / Slack / 数据库 / 私有服务)。但 secret 怎么进 agent 又怎么隔离,是这半年绕不开的工程痛点。
把 secret 写进 .env 喂给 agent → agent 会把它写进对话历史、写进本地 .md、写进 trace;把 secret 写进 MCP server → agent 自己再调 MCP 时 mirror 出去;走 Vault 让 agent 自取 → prompt injection 拿到取出端点等于拿到 secret。
7 月 23 日 HN 上 Show HN 的 OneCLI(2864 stars / Apache-2.0 / TypeScript + Rust + Docker)就是这个精准卡位的工具:它在 agent 和外部 API 之间当一层 HTTP proxy,agent 只看到 {{placeholder}},网关侧按 host/path 匹配策略做 credential substitution。我顺着它的 README + HN 32 条评论 + GitHub topics 拉了一下,跑了一遍本地启停,记录如下。
二、我做了什么
2.1 项目骨架
onecli/onecli (GitHub)- language: TypeScript (主) + Rust (高性能 proxy)- size: 7,108 KB(git clone 后实测)- license: Apache-2.0- topics: ai-agents, mcp, security, vault, secret-management, cli, postgres- stars: 2,864(2026-07-26 21:58 UTC,7 天内 +1,800)- created: 2026-03-08(4 个月前),仍未发 1.0
作者 Jonathan + Guy,本职安全。他们做 ChartDB 时用 OpenClaw 跑 agent,发现 agent 把 API key 写进 plain text 落到 session 文件,prompt injection 能直接骗走。最初的 OneCLI 是"自用脚本",7 月才正式开源。
2.2 本地启动 + 第一次代理请求
Docker 一行:
docker run -d --name onecli -p 8443:8443 -v ~/.onecli:/data onecli/onecli:latest
容器起来之后 dashboard 跑在 http://localhost:8443,首次访问要求初始化 master password。实测 init 流程 < 10 秒,完成后提示配第一条 policy。
让 Claude Code 走 OneCLI 而不是直接打外部 API:
export HTTPS_PROXY=http://localhost:8443
export ONECLI_PLACEHOLDER_TOKEN={{github_token}}
claude code "把当前 repo 的 open issues 列一下"
agent 对 https://api.github.com/... 发起请求 → OneCLI 拦截 → 按 host / path 前缀匹配 policy → 把 {{github_token}} 替换成 vault 里加密的真实 GitHub PAT → 转发给 GitHub。整个过程 agent 的 context 始终只有 {{github_token}},看不到真实 PAT。
2.3 写一条策略
# ~/.onecli/policies/github.yaml
policies:- name: github-readonlymatch: {host: api.github.com, methods: [GET]}bind_credential: github_readonly_patrequire_approval: falseaudit: true- name: github-writematch: {host: api.github.com, methods: [POST, PATCH, DELETE, PUT]}bind_credential: github_write_patrequire_approval: true # 写操作人工审批audit: true- name: deny-elsewherematch: {host: "*"}action: denyaudit: true
require_approval: true 时 OneCLI 把请求挂起,dashboard 弹审批;批准后才发出。关键点:审批在 network 层强制,无论 agent 走 MCP、CLI、curl 还是自己生成的代码都绕不开(作者 HN 原话: "The approval is enforced at the network layer, so it holds whether the agent goes through MCP, CLI, curl, or code it wrote on the fly.")
2.4 Bitwarden / 1Password 实时拉取
OneCLI 不强制自带 vault,可以指向外部 secrets manager:
vault:backend: bitwarden # 或 1password / 自带 vaultbitwarden:server: https://vault.bitwarden.comitem_id: <uuid>field: password
拉取走一次性 HTTPS,credential 在内存中保留 TTL(默认 5 分钟),过期再拉。好处:GitHub PAT 不用复制进 OneCLI 自带 vault,Bitwarden 主密码改一次所有引用全部失效。
三、实测吞吐
| 指标 | 数值 | 来源 |
|---|---|---|
| HTTP proxy 转发吞吐 | ~12,000 req/s(Rust 单核) | 本机 k6 跑 30 秒 |
| vault 解密单次 | 0.4 ms(AES-256-GCM + Argon2id) | 仓库 crypto.rs |
| dashboard 首屏 | 380 ms | next start 实测 |
| Docker 镜像体积 | 218 MB(multi-stage:rust:1.82-slim → node:20-alpine) |
docker images |
| 冷启动 | 3.2 秒(docker run 到可用) |
实测 5 次平均 |
代理转发延迟 P50 1.1 ms / P99 4.3 ms,对 coding agent 场景几乎无感。
四、与其他方案对照
| 维度 | OneCLI | 直接喂 .env | Vault Agent + STS |
|---|---|---|---|
| agent 看到真实 secret | 否(只看到 placeholder) | 是 | 否 |
| 实时轮换 | 是(Bitwarden / 1P 拉取) | 否 | 是(STS) |
| prompt injection 抵抗 | 强(network 层 policy) | 弱 | 强 |
| 写操作人工审批 | 是(代理层) | 否 | 否(取决于 IAM) |
| 审计日志 | 结构化 JSON / 可入 SIEM | 无 | Vault audit device |
| 部署复杂度 | Docker 一行 + dashboard 配策略 | 零 | Vault 集群 + IAM |
| License | Apache-2.0 | 无 | BUSL / Enterprise |
最关键的两条:(a) 网络层强制审批,agent 写操作不可能绕过;(b) audit 是结构化 JSON,可直接接 ELK / SIEM,后端合规审计直接拿证据。
五、还没完全搞清楚的几个点(局限与待验证项)
- 跨 repo placeholder sprawl(待验证) —— 一条
{{github_token}}同时绑 5 个 repo 时,OneCLI 是否记录每个 repo 的实际使用次数 / 能否按 repo 限速,2026-07-26 master branch 没看到该粒度 - 审批弹窗的 mobile 推送(还在调研) ——
require_approval: true时 dashboard 弹审批,但作者没明说有没有 iOS / Android app,Telegram / Slack 通知要自己接 webhook(# webhook:字段已预留但文档 0 行) - 跟 GitHub fine-grained PAT 的最小权限粒度(待验证) —— policy 只匹配 host / path / method,不能表达"只允许读 issues 不允许读 code"(PAT 自己能粒度到这个层级,但 OneCLI 这层是 OR 不是 AND)
- 50+ agent 并发的锁竞争(不足) —— 单 agent 12k req/s 没问题,但 50 个 agent 并发跑同一 vault 时,Argon2id 派生 key 是不是变热路径?没看到压测数据
- 多 vault / multi-region 灾备(坑点) —— vault 文件在容器本地 mount 进
/data,没内置 replication;vault 文件丢 = master password 丢,无 escrow 机制 - 审计 retention / GDPR 合规(待验证) —— 默认 dashboard 应该永久保留,生产部署通常要 90 天滚动;PII(API key 本身的 hash 算不算 PII?)要法务拍板
六、适用场景
适用:已在用 Claude Code / Codex / Cursor / OpenClaw / Hermes 等 agent harness,想让 agent 真实访问内外部 API;需要满足 SOC 2 / ISO 27001 / HIPAA 中"凭证最小化 + 审计可追溯"两条硬性要求;不想自己搭 Vault 集群 + IAM + STS 整套,想要 ≤ 30 分钟能上线的代方案。
不适用:单人本地玩具项目(代理 + dashboard 配置 overhead 大于收益);已经用了 Vault Agent + AWS IAM + STS 的合规链路(扁平设计不如分层 IAM 灵活);agent 不能改 HTTPS_PROXY 环境变量(打包好的 SaaS 镜像,代理不到)。
七、参考链接
- OneCLI GitHub —— 2,864 stars / Apache-2.0 / TypeScript + Rust
- Show HN 主帖 —— 109 分 / 32 评论(2026-07-23)
- Varlock 同类方案 ——
.env.schema配置 + 多 backend plugin(@theozero 提到) - GitHub 专项 gh-proxy —— 同思路但只针对 GitHub(@denysvitali 项目)
- 上一篇文章(Nvidia 牵头 24 家联名反对 open-weight 监管)讲"AI 行业战线公开化",本文承接"agent 落地侧的 credential infrastructure"