OneCLI：2.8K Star，给 AI Agent 装上网络层安全阀
OneCLI：2.8K Star，给 AI Agent 装上网络层安全阀
你的 AI Agent 正在删邮件，你让它停，它不停。
这不是假设。OneCLI 官网首页就引用了这个真实案例：一个拥有无限邮件权限的 AI Agent 开始删除邮件，用户明确要求停止，它照删不误。
问题不在于模型不够聪明，而在于你把密钥交给了 Agent，就等于把方向盘交给了它。Prompt 里写"不要删除邮件"只是建议，Agent 想不听就不听。
onecli/onecli 给出的解法很直接：不要把密钥交给 Agent。Y Combinator 孵化，2,830+ Star，TypeScript + Rust 混合架构，Apache-2.0 协议。它把自己定位成 "the secret vault for AI agents"--一个介于 Agent 和外部服务之间的网络层凭据网关。
本文提纲
- 核心矛盾：Prompt 是建议，Proxy 是执行
- 工作原理：FAKE_KEY 换 REAL_KEY 的戏法
- 架构拆解：Rust Gateway + Next.js Dashboard
- 四道安全闸门：阻断、限流、审批、隔离
- Vault 集成：密钥不落盘的 Bitwarden 方案
- MCP 与 Agent 生态的契合点
- 部署和上手
核心矛盾：Prompt 是建议，Proxy 是执行
先说清楚 OneCLI 到底解决了什么问题。
现在给 AI Agent 授权的方式基本就两种：要么把 API Key 写进 .env，要么通过 MCP Server 传进去。两种方式都有一个共同前提--Agent 必须拿到真实密钥才能工作。
这就带来一个根本性矛盾：
- 你在 system prompt 里写"只能调用
GET /users，不要调用DELETE /repos" - 这是 prompt，是给 LLM 看的
- LLM 可以听，也可以不听，尤其是被注入攻击或者上下文混乱的时候
OneCLI 的核心论点就一句话："OneCLI policies are enforced at the network layer, outside the agent, outside the LLM." 策略在网络层执行，不在模型里执行。
这意味着不管 LLM 怎么想、怎么被诱导，DELETE /repos 这个请求在网关那里就被硬性拦下了。Prompt 是建议，Proxy 是执行。这是两种完全不同的安全模型。
工作原理：FAKE_KEY 换 REAL_KEY 的戏法
OneCLI 最巧妙的设计在于 Agent 根本不知道自己在用 OneCLI。
具体流程是这样的：
- 你把真实 API 凭据存进 OneCLI（比如
sk-ant-api03-xxxxx） - OneCLI 给 Agent 发一个占位符密钥（比如
FAKE_KEY） - Agent 的
.env里写的是ANTHROPIC_API_KEY=FAKE_KEY - Agent 像往常一样发 HTTP 请求，用的是
FAKE_KEY - 请求经过 OneCLI 网关，网关把
FAKE_KEY替换成真实密钥 - 真实密钥解密后注入到出站请求，转发给目标 API
Agent 全程没碰过真实密钥，它只是"正常发请求"。这种设计的好处是Agent 无需任何改造--不需要 SDK，不需要改代码，不需要知道 OneCLI 存在。
从 Agent 视角看，它就是在调用一个普通的 HTTP API。从目标 API 视角看，请求带着正确的密钥正常到达。OneCLI 是中间那个透明的"换牌手"。
架构拆解：Rust Gateway + Next.js Dashboard
OneCLI 是典型的"性能敏感层用 Rust，业务逻辑层用 TypeScript"的混合架构。
apps/
web/ # Next.js 仪表盘 + API（端口 10254）
gateway/ # Rust 网关（凭据注入，端口 10255）
packages/
db/ # Prisma ORM + 迁移
ui/ # 共享 UI 组件（shadcn/ui）Rust Gateway 是整个系统的核心。看一眼 apps/gateway/src 的模块清单就能理解它的职责边界：
secret_inject.rs/inject.rs：凭据注入逻辑policy.rs/policy_engine.rs：策略引擎，决定请求是放行、拦截还是待审批approval.rs：人工审批工作流budget.rs：预算和限流ca.rs：CA 证书管理，用于 HTTPS 的 MITM 拦截crypto.rs：AES-256-GCM 加解密vault/：外部密码管理器集成default_interceptions.rs：默认拦截规则
这里有个技术细节值得展开：HTTPS 的 MITM 拦截。Agent 调用的 API 绝大多数是 HTTPS，要在网关层替换 header 里的密钥，就必须解密 HTTPS 流量。OneCLI 的做法是网关自带一个 CA（ca.rs），Agent 信任这个 CA 签发的证书，网关就能在中间解密、改包、再加密转发。这是企业级 MITM 代理的标准做法，但用在 AI Agent 治理上算是新场景。
Next.js Dashboard 负责管理面：创建 Agent、配置密钥、设置策略、查看请求日志。它同时也提供网关用来解析"哪个请求该用哪个凭据"的 API。PostgreSQL 存储加密后的凭据和配置，密钥用 SECRET_ENCRYPTION_KEY 加密，默认自动生成。
四道安全闸门：阻断、限流、审批、隔离
OneCLI 不只是"换密钥"，它是一整套 Agent 治理工具。核心是四道闸门：
端点阻断（Endpoint Blocking）。管理员可以在网关层直接封禁某些 API 路径。比如 DELETE /repos、POST /payments、DELETE /emails--这些破坏性操作直接在网关硬拦，不管 Agent 怎么请求都过不去。这是对开头那个"删邮件"案例的直接回应。
按 Agent 限流（Per-Agent Rate Limiting）。给每个 Agent 设置每分钟、每小时、每天的请求上限。官方原话是 "stop runaway loops before they cause damage"--在 Agent 陷入死循环、疯狂调 API 烧钱之前把它掐住。这比事后看账单心疼要强得多。
人工审批（Human Approval Workflow）。敏感操作可以标记为"需要人工审核"。Agent 发起请求后，请求会被挂起，等人在仪表盘里点批准或拒绝后才放行。这适合支付、删除、生产环境部署这类不可逆操作。
项目隔离（Project Scoping）。每个 Agent 只能访问分配给它所在项目的凭据和服务，项目之间不互通。多团队、多项目共用一个 OneCLI 实例时，这是硬性边界。
这四道闸门叠加起来，OneCLI 实际上给 AI Agent 划了一个确定性的安全围栏--不是靠模型自觉，是靠网络层硬执行。
Vault 集成：密钥不落盘的 Bitwarden 方案
OneCLI 有一个相当超前的设计：Vault 集成。它支持对接 Bitwarden（通过 Agent Access SDK），实现密钥完全不落盘。
工作流程：
- 你把 Bitwarden 桌面端和 OneCLI 网关配对（一次性，用配对码）
- Agent 发 HTTPS 请求，本地数据库没有匹配的密钥
- 网关通过加密的 Noise 协议会话问你的 Bitwarden vault 要凭据
- Bitwarden 按域名匹配，通过加密通道返回
- 网关注入凭据（Anthropic 用
x-api-key，其他用Authorization: Bearer） - 凭据在内存里缓存 60 秒，然后丢弃
关键点：凭据从不写入磁盘，从不进入数据库。Bitwarden 是 fallback，本地数据库里存的密钥优先级更高。这个设计意味着 OneCLI 服务器本身不持有任何明文密钥，即使服务器被攻破，攻击者也只能拿到加密后的内存缓存。
架构上 Vault 系统是 provider-agnostic 的，VaultProvider trait 抽象了密码管理器接口，Bitwarden 是第一个实现，未来可以加 1Password 等。这是为生态扩展留的口子。
MCP 与 Agent 生态的契合点
OneCLI 明确覆盖 MCP（Model Context Protocol）工具调用，但它有个挺尖锐的观点："an MCP gateway isn't enough"。
理由是 MCP 只管工具调用这一条路径，但 Agent 的危险操作不止走 MCP。Agent 写的代码里可能直接 curl 调 API，Agent 执行的 CLI 命令可能带凭据，Agent 生成的脚本可能硬编码密钥。OneCLI 的网关层覆盖的是所有出站 HTTP 流量--MCP 调用、curl、CLI、生成的代码，统统拦截。
这其实是两个层面的安全：MCP Gateway 管"工具该不该被调用"，OneCLI 管"请求该不该到达目标"。前者是逻辑层，后者是网络层，两者互补而非替代。
对于已经在用 Claude Code、Codex、各种 Agent 框架的团队，OneCLI 的价值在于：你不需要改 Agent 代码，只要把 Agent 的 HTTP 代理指向 OneCLI 网关，立刻获得凭据隔离、请求审计、端点管控。改造成本接近于零。
部署和上手
最快的方式，一行命令：
curl -fsSL https://onecli.sh/install | sh或者用 Docker：
git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up -d --wait启动后打开 http://localhost:10254 创建 Agent、添加密钥，把 Agent 的 HTTP 代理指向 localhost:10255。
本地模式是单用户、免登录的，不需要 .env 或 NEXTAUTH_SECRET。要多人协作就配置 Google OAuth。所有环境变量都有合理默认值，SECRET_ENCRYPTION_KEY 不设会自动生成。
免费层支持 2 个 Agent，不需要信用卡。已经有一些公司在用，客户列表里有 Docker、MindsDB、Zoho、Coralogix。
参考文档与链接
- GitHub: onecli/onecli - 2.8K Star，TypeScript + Rust，Apache-2.0，Y Combinator
- OneCLI 官网 - 产品介绍和文档
- OneCLI 文档 - 完整使用文档
- Vault 集成文档 - Bitwarden 对接说明
- Bitwarden Agent Access SDK - 密钥不落盘的技术基础
- Model Context Protocol (MCP) - AI 工具扩展协议
你的 Agent 现在用什么方式管密钥？评论区聊聊。还在用
.env硬编码的，该醒醒了。
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
