Cloak 实战：隔离 AI Agent 的 API 密钥，让模型看得见用不着
给 Claude Code、Cursor 或 Codex 配一个 API key 的时候，你有没有想过：这个密钥现在不光你在用，模型也能「看到」它？
你输入 OPENAI_API_KEY=sk-xxx，Agent 拿到后不仅能调用 API，还可能在某个 Prompt Injection 攻击下把密钥吐出去。更不要说你退出对话后，密钥还躺在 Provider 的日志里。
这不是理论风险。Reddit 和 HN 上已经有不少人反馈 AI 编程工具意外泄露了 API key。如果你的 Agent 有访问 Stripe、AWS 或 GitHub Token 的权限，一个 Prompt Injection 就能让攻击者用你的密钥在后台干大事。
Cloak（cloakward/cloak） 就是来解决这个问题的。它是一个开源的本地密钥保险库，让你把 API 密钥存在加密仓库里，Agent 能调用但读不到明文字符串。密钥值从头到尾不进入模型上下文。
装好 Cloak 只需要 10 秒
Cloak 用 Rust 编写，提供 macOS（arm64/x64）和 Linux（x64 glibc）的二进制。安装很简单：
brew install cloakward/cloak/cloak
没有 Homebrew 的环境，可以从 GitHub Releases 下载预编译二进制。
安装后立即初始化：
cloak setup
这条命令会创建加密保险库、启动后台守护进程（cloakd），并自动检测你机器上已安装的 AI 客户端——Claude Desktop、Claude Code、Cursor、Windsurf、Zed、Continue.dev 和 Codex 都能自动连接上。
初始化后，把现有的环境变量导进去：
cloak import .env
或者逐个添加密钥：
cloak add OPENAI_API_KEY cloak add ANTHROPIC_API_KEY cloak add GITHUB_TOKEN
用策略控制权限，告别「全有或全无」
导入的密钥默认处于禁用状态。你需要手动授权每个密钥能访问哪些域名：
cloak allow OPENAI_API_KEY api.openai.com cloak allow ANTHROPIC_API_KEY api.anthropic.com cloak allow GITHUB_TOKEN api.github.com
查看当前策略：
cloak policy
这样设计的好处很明显：即使一个 Agent 被诱导调用了你的 Stripe 密钥，如果该密钥只允许访问 api.stripe.com，它对其他 URL 的请求会自动被拒绝。权限粒度是「密钥 × 域名」级别，不是粗暴的「全开或全关」。
策略也可以写在 policy.toml 文件中，方便版本控制和复查。
实战：用 Stripe 密钥测试支付流程
结合 Cloak 的场景非常直观。假设你要让 Agent 帮忙测试 Stripe 支付流程——传统做法是把 STRIPE_SECRET_KEY 放进 .env 或直接粘贴到 Agent 的配置里。
用 Cloak 的做法：
cloak add STRIPE_SECRET_KEY cloak allow STRIPE_SECRET_KEY api.stripe.com
然后对你的 Agent 说：
你：帮我测试一下 checkout。创建一个 $50 的 Stripe PaymentIntent，用 pm_card_visa 支付，确认成功。
Agent 内部的流程是这样走的：
- Agent 决定调用
proxy_authenticated_http_request工具 - Cloak 的 MCP 服务拦截到调用，从加密保险库取出
STRIPE_SECRET_KEY - Cloak 把密钥附加到请求头，发送到
api.stripe.com - Stripe 返回结果
- Cloak 返回结果给 Agent，密钥全程未进入模型上下文
输出看起来像这样：
proxy_authenticated_http_request → POST https://api.stripe.com/v1/payment_intents
Status 200
{
"id": "pi_3ThFkTKCZ65x2cgg0rzmsrj3",
"amount": 5000,
"amount_received": 5000,
"currency": "usd",
"livemode": false
}
一笔 $50 的支付成功了。但授权它的 STRIPE_SECRET_KEY（有能力退款每笔支付、清空账户的敏感凭证）从头到尾都没出现在 Agent 或模型的日志里。
架构拆解：三个组件各司其职
Cloak 由三个组件组成：
| 组件 | 职责 |
|---|---|
| cloak（CLI） | 用户管理密钥、配置策略的前端工具 |
| cloakd（守护进程） | 常驻后台，持有解密后的密钥，执行实际请求 |
| cloak-mcp（MCP 服务） | AI 客户端连接的服务，提供工具调用接口 |
Agent 调用 cloak-mcp 上的工具时，cloakd 检查策略是否允许该密钥访问目标域名。允许的话，它只附加密钥到请求并返回结果。密钥值从不返回给 Agent。
Cloak 提供这几种 MCP 工具：
proxy_authenticated_http_request——用已授权的密钥发 HTTP 请求，Agent 无法读取密钥list_secrets——列出已添加的密钥名称（不显示值）sign_jwt——用密钥签名 JWT，不暴露密钥原文mint_token——基于授权密钥生成临时令牌
注意这里缺了什么？没有 read_secret 工具。Agent 没法从 Cloak 里读出一个密钥的完整值——这是设计上的硬约束，不是配置选项。
安全性不只是密钥隔离
除了基本的密钥隔离，Cloak 还在供应链安全上做了不少工作：
- Cosign 签名——每个 Release 都有 cosign 签名验证
- SLSA L3 认证——发布流程达到 SLSA Level 3，能抵御构建环节的篡改
- macOS 公证——macOS 版本通过了 Apple 的公证流程
- 威胁模型透明——项目有一份坦诚的
THREAT_MODEL.md，明确说明它保护什么、不保护什么
Cloak 不防什么？它不防御已经被 hijack 的 Agent——如果 Agent 本身被控制了，mint_token 或 proxy 的响应依然会回到 Agent 手里。它也不防御 Root 级别的攻击者。它针对的是单用户机器上的长期凭证泄露风险。
Cloak 适合谁用
- 用 Claude Code、Cursor、Codex 等 AI 编程工具管理多个 API 密钥的开发者
- 不想在
.env里明文存放支付或云服务凭据的团队 - 需要让 AI Agent 访问 GitHub Token、AWS Key 但又怕泄露的场景
- 对 Supply Chain Security 有要求、关注 SLSA 标准的技术团队
如果你是 Solo Developer，Cloak 让你的开发环境安全提升一个台阶。如果你是团队 Lead，推 Cloak 到团队可以用 policy.toml 统一管理策略，让密钥安全成为共识而非个人觉悟。
总结
Cloak 解决了一个很具体但也越来越普遍的痛点：AI Agent 需要调用 API，但密钥不应该裸奔在模型的上下文里。它不要求你改变工作流——装好、导入、授权，然后正常用 Agent 就行。密钥安全从「靠自觉」变成了「靠架构」。
项目地址：https://github.com/cloakward/cloak
许可证：Apache-2.0
Stars：14（刚起步，但理念和实现质量都很扎实）