深度报告
-
OneCLI 是一个面向 AI Agent 的开源凭证网关，由 Y Combinator 2026 夏季批次孵化，在 GitHub 上已获得超过 2,800 星标。它解决的是 Agent 时代最棘手的安防问题之一：Agent 要调用外部 API，但直接交密钥给 Agent 无异于把保险柜密码贴在门上。OneCLI 的解法是在 Agent 和目标服务之间插入一个透明代理网关，真实凭证加密存储于网关内，Agent 只持有占位符令牌，请求发出瞬间才由网关完成「假密钥→真密钥」的替换。 截至报告撰写时，项目下载量已超过 32 万次，并被 NanoClaw 选为默认凭证层。
-
OneCLI 由 Guy Ben Aharon 和 Jonathan Fishner 联合创立。两位创始人的背景集中在安全工程领域：Guy 曾是 Argon（后被 Aqua Security 收购）的首位工程师，Jonathan 在 Axis Security（后被 HPE 收购）从事零信任网络访问工作，均来自以色列军事情报部门。在此之前，两人曾共同开发开源数据库工具 ChartDB（GitHub 20,000+ 星标）。 创立动机来自亲身经历：他们在为 ChartDB 构建 Agent 编排层时，始终找不到一种安全的方式给自主 Agent 分发凭证。团队调研发现，几乎所有使用 Agent 的团队要么把 API Key 硬编码到 .env 文件中，要么临时拼凑代理方案。2026 年 7 月，项目正式开源并登上 Hacker News「Show HN」，迅速获得社区关注。Y Combinator 在 2026 年 7 月 23 日通过官方 X 账号公开推广 OneCLI，将其定义为「让 AI Agent 在不存储密码的情况下做真正的工作」的基础设施层。 OneCLI 采用 Apache-2.0 许可证，目前仍处于早期快速迭代阶段（v1.42.0+），但已有 Docker、MindsDB、Zoho、Coralogix 等公司开始使用。
-
OneCLI 的核心工作流程分为三步。第一步，运营者将真实的 API 凭据存入 OneCLI 的加密保险库；第二步，为每个 Agent 发放占位符密钥（如 FAKE_KEY），Agent 在发出 HTTP 请求时使用这些假密钥；第三步，OneCLI 网关拦截请求，根据主机和路径匹配规则，在请求离开网关前完成凭证的解密和替换，最后将携带真实凭证的请求转发给目标服务。整个过程中，Agent 从未在任何环节接触真实密钥。 技术栈上，OneCLI 由三层构成。Rust 编写的高性能 HTTP 网关负责拦截出站请求并注入凭证，Agent 通过 Proxy-Authorization 头携带访问令牌完成身份认证。Next.js 构建的 Web 仪表盘用于管理 Agent、密钥和权限，网关通过仪表盘暴露的 API 动态解析每次请求该注入哪些凭据。凭证存储层采用 AES-256-GCM 加密，密钥只在请求发生时才解密，解密后严格按主机和路径模式匹配后以请求头或 URL 参数的形式注入。 部署极为简单，一条命令即可启动：docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli 启动后访问 http://localhost:10254 创建 Agent、添加密钥，然后将 Agent 的 HTTP 代理指向 localhost:10255。Agent 框架无需任何代码修改——只要支持设置 HTTPS_PROXY 环境变量即可接入。这包括 Claude Code、Codex、Cursor、Cline 以及 OpenClaw、NanoClaw、LangChain、CrewAI 等主流框架。 OneCLI 还提供 onecli CLI 命令行工具，让 Agent 能通过 Shell 命令自主管理自己的身份和密钥——Agent 编排器可以在一个脚本中创建新 Agent、分配凭证、配置规则，无需人工操作仪表盘。 本地模式支持单用户免登录运行，无需配置 NEXTAUTH_SECRET。团队协作可以启用 Google OAuth 认证。所有环境变量都有合理默认值，SECRET_ENCRYPTION_KEY 不设置时会自动生成。
-
OneCLI 目前完全免费开源（Apache-2.0），免费层支持最多 2 个 Agent，无需信用卡。项目团队目前是 Y Combinator 孵化的创业公司，尚未公布正式商业版本的具体定价方案。可以预见的商业路径包括：企业版的多 Agent 支持、高级策略引擎、组织级身份提供商集成以及托管云服务。
-
社区对 OneCLI 的总体评价积极，尤其在 Agent 安全社区中反响热烈。Hacker News 讨论帖中有开发者指出，凭证代理方案这类方案并非全新（如 Fly.io 的 Tokenizer、BuzzFeed SSO 代理等），但专为 AI Agent 场景量身定制的实现确实降低了落地门槛。也有开发者分享了使用 HashiCorp Vault 配合脚本实现类似效果的方案，但承认 OneCLI 的「开箱即用」体验更好。 Y Combinator 官方账号推广的演示视频展示了 Claude Code 通过 OneCLI 网关调用 GitHub API 的完整流程——Agent 全程只持有 FAKE_KEY，真实 PAT 在请求发出瞬间由网关注入。 中文社区的评价以建设性为主。博客园上有开发者对 OneCLI 进行了实测，认为其「改造成本接近于零」，但对于已经在运行生产环境 Agent 的团队，需要特别注意网关的 HTTPS 证书管理和网络隔离。也有评论指出，集中化管理凭证也意味着集中化了风险——如果 OneCLI 服务器被攻破，攻击者将获得一个极为有价值的目标。
-
OneCLI 获得了多个权威来源的正面报道。Y Combinator 的公开推广被视为行业信号——加速器认为 Agent 安全基础设施是一个独立的、值得重点布局的赛道。The Agent Times、World AI 360 等媒体均进行了报道，普遍认为 OneCLI 的设计模式——将凭证隔离在 Agent 内存之外——有望成为 Agent 架构的标准安全层。 从竞品格局来看，OneCLI 面临的主要竞争来自两类方案。一类是传统密钥管理工具（HashiCorp Vault、AWS Secrets Manager、1Password），这些工具解决的是存储问题，但不解决注入问题——Agent 拿到密钥后仍然存在泄露风险。另一类是新兴的 Agent 框架（如 MCP 协议），但 MCP 工具定义会消耗 Agent 的上下文窗口，且每个 MCP 服务器各自处理认证，缺乏统一的凭证管理。OneCLI 的差异化定位正是在这两类方案之间找到了空白地带：既解决存储，又解决注入，同时不消耗 Agent 的上下文窗口。
-
OneCLI 并非没有风险。核心问题在于 MITM CA 模型——网关需要持有 CA 密钥来为任意目标签发证书，这意味着在共享或多租户机器上，权限提升漏洞可能暴露 CA 密钥。部署时需要在 Docker 容器隔离和网络命名空间上格外谨慎。 项目虽然迭代速度快、社区增长迅猛，但仍处于 v1.x 阶段，API 和配置格式可能随版本升级发生变化。对于需要长期稳定性保障的企业，建议将 OneCLI 作为可评估的方案进行原型验证，同时保留传统凭证管理作为回退方案。 还有一个不可忽视的问题是集中化信任——把凭证集中在一个网关管理，虽然提升了运维效率，但也意味着网关本身成为单点爆破目标。运营者需要对该网关进行额外加固，包括但不限于：限制仪表盘访问 IP、启用审计日志外部存储、定期轮换加密密钥。
-
OneCLI 最适合两类团队。第一类是正在运行编码 Agent（Claude Code、Codex、Cursor）的开发和运维团队，这些 Agent 需要频繁调用 GitHub、Slack、Jira 等外部 API，每一行输出都可能包含密钥。第二类是构建多 Agent 协作系统的团队，需要统一管理和审计所有 Agent 的 API 访问。 不适合的场景包括：仅运行在完全隔离网络中的 Agent、已有成熟 HashiCorp Vault 部署且不愿增加额外基础设施的团队，以及需要严格合规审计（如 SOC 2 Type II）的对标企业。对于后者，建议等 OneCLI 完成第三方安全审计后再考虑生产级部署。
-
OneCLI 精准命中了 AI Agent 普及过程中的一个真实痛点——凭证安全——并提供了一个工程上优雅且实用的解法。它的核心判断是「Agent 连密钥都不该碰」，并将这一原则贯彻到了架构层面。在 Agent 从玩具走向生产力的关键转折期，OneCLI 有望成为 Agent 基础设施的安全标配。但它的真正价值，要等到完成第三方审计并发布稳定版 2.0 之后才能被充分验证。
用户评论
-
2hyqkek—试了一下 OneCLI，把 Claude Code 的密钥管理问题彻底解决了。之前每次都要在 .env 里塞各种 API Key，现在一条 docker 命令跑起来，Agent 完全不知道真实密钥，安全感提升太多了。 -
珊瑚37—有人拿它和 HashiCorp Vault 比，我觉得定位不一样。Vault 太重了，一个小团队搞 Agent 开发，OneCLI 一键部署真的省心。 -
RGonzales_Plus—Rust 写的 HTTP 网关，性能确实稳。我测了一下延迟，加了 OneCLI 代理之后几乎没感觉到额外开销，比用 Vault 每次去取密钥快太多了。 -
王月珍—看到 YC 官方号推了 OneCLI，去了解了一下。思路确实好——不是不让 Agent 调用 API，而是让 Agent 连密钥都不该碰。这个设计哲学我认可。 -
FrankHicksIII—Hacker News 上有人质疑说这东西不就是个 auth proxy 吗，确实类似方案以前也有。但专为 Agent 场景做了优化，开箱即用，这就够了。 -
AnnGray—部署是简单，docker run 一行就能跑起来。但有一个坑：需要自己处理自签证书的问题，Agent 容器里不信任 CA 证书的话 HTTPS 流量就过不了。 -
流年472—OneCLI 的做法让我想起了之前看的一个真实案例：某大厂的安全负责人给 Agent 授权后，Agent 开始疯狂删邮件。要是当时有一层网关策略限制，可能就只删几封而不是全部了。 -
8j0wz—用 OneCLI 配合 NanoClaw 试了一下，体验很丝滑。Agent 完全不知道密钥的存在，想泄露都没办法。对安全敏感的团队来说，这个组合拳值得一试。 -
HaroldStephensIII—已在我的 Cursor 工作流里集成了 OneCLI，给 GitHub、OpenAI 和 Slack 的 API 都配置好了。配置过程很直观，Web 面板左管理 Agent 和密钥，权限粒度够细。 -
AshleyOrtiz—唯一的顾虑是集中化风险。所有密钥都走 OneCLI 网关，万一这个网关被攻破就全完了。虽然加密存储做得好，但在生产环境我对单点故障还是有些担心。 -
康明_1—对比了几款凭证管理工具，OneCLI 对个人开发者最友好。Authsome 虽然零基础设施，但没有审计；Vault 又太重。OneCLI 好在中间档位。 -
Isabella.Morgan—还能对接 Bitwarden 这点挺香，密钥不需要存在 OneCLI 本地数据库里，直接从 Bitwarden 拉取。对于已经在用密码管理器的团队来说迁移成本很低。 -
KeithStewartJr—看了一下代码，Rust 网关那层写得挺扎实的。AES-256-GCM 静态加密，请求时才解密，设计上没有明显短板。期待他们后续加审批流和监控规则。 -
Jacqueline.Adams—虽然 OneCLI 能防止密钥泄露，但它挡不住授权后的 Agent 乱搞。Agent 有权限调 Stripe API 就能随便扣费，这个问题还需要审批流来解决，光靠网关不够。 -
Laura_MooreIII—从 Show HN 关注的，到现在 2800+ star 了，增长确实快。说明这个痛点真的戳中很多人。Apache-2.0 协议＋YC 背书，值得关注。 -
7wnel5q—部署了 OneCLI 之后有个意外收获：审计日志太好用了。以前 Agent 调了什么 API、什么时候调的完全不可见，现在一目了然，排查问题效率高很多。 -
EHughesIII—Gateway + Dashboard + 加密存储三件套的架构很清晰。Rust 网关的性能不是问题，Next.js 面板操作也顺手。就是文档有些地方写得太简略，新手可能要多摸索一下。 -
smallpeacock198—跟着博客园那篇实测文章走了一遍，本地部署花了不到十分钟。用 Claude Code 调 GitHub API，全程只看见 FAKE_KEY。这个透明替换确实有点黑科技的感觉。 -
Brian.Martinez168—对我这种做 AI Agent 开发的来说，OneCLI 解决了最头疼的问题——每次 demo 前都得检查 .env 文件有没有被不小心 commit 上去。现在不用担心了。 -
Web_3Wave—目前还处于 1.x 阶段，API 变化可能比较频繁。生产环境用的话建议锁定版本，不然升级后配置格式变了就麻烦了。 -
purplepanda996—把 OneCLI 接入到我们团队的多 Agent 系统里了，三个项目各自隔离密钥和策略。这种项目级隔离设计很实用，不同客户的数据不会串。 -
许桂强—我就想知道它什么时候支持 1Password 集成，现在只有 Bitwarden 有点局限。团队里用 1Password 的人挺多的，希望能加上。 -
DianeMitchell_Plus60—Docker 一行命令就搭起来了，确实方便。不过我试了一下 Node.js 的 Agent，HTTP_PROXY 环境变量在 Node 旧版本上支持不太好，得用 22+ 才行。 -
LoganRodriguez_20234—好评。之前做过一个实验，普通 Prompt Injection 攻击从环境变量里把 OpenAI Key 骗出来了。用了 OneCLI 之后再试同样的攻击，Agent 手里根本没有 Key，想泄露也泄露不了。 -
OMpow—策略引擎的设计不错，可以为每个 Agent 单独配 allow/block 规则和速率限制。这个比简单的密钥管理要深入得多，算是在网络层做了权限管控。 -
云烟737—PostgreSQL 依赖是个门槛，个人开发为了跑它还得装个数据库有点 overkill。好在他们说有 PGlite 嵌入式版本，不用单独搭数据库，期待正式支持。 -
AfraRomkes—和团队的 DevOps 聊了一下，他觉得 OneCLI 的 MITM 代理方案对信创环境来说有合规风险。自签证书在等保审计里不一定被认可，建议留意这个点。 -
WLopezX736—The Agent Times 那篇分析文章写得好，点出了关键问题：OneCLI 解决了密钥泄露，但解决不了 Agent 滥用授权。不过瑕不掩瑜，至少先把最要命的问题解决了。 -
goldendog167—开了个 Issue 问关于审批流的问题，开发者回复很快，说已经在 roadmap 上了。Y Combinator 押注的项目，迭代速度应该不会慢。 -
星辰_14—看了 karpathy 转发的关于 CLI 和 Agent 的观点，再来看 OneCLI 的设计，确实契合。CLI 是 Agent 的原生接口，在 CLI 层做凭据管理比在应用层做更底层、更通用。