核心用法
Keys 采用"代理隔离"架构解决 AI 助手场景下的密钥安全管理难题。用户通过 keys-broker call 命令发起预配置服务的 API 请求，密钥全程由独立的 keys-broker 进程保管，永不进入 agent 上下文或对话历史。
调用流程：
1. 用户安装 keys-broker.sh 至本地系统（需 macOS Keychain 或 Linux Secret Service）
2. 密钥存入系统级密钥管理器，agent 无读取权限
3. 通过 JSON-RPC 指令向 broker 发起代理请求
4. broker 完成鉴权、执行 HTTP 调用，仅返回响应体
预配置服务：OpenAI、Anthropic、Stripe、GitHub（硬编码白名单机制，禁止任意 URL 以防 SSRF/密钥外带）
显著优点
- 零信任架构：密钥与 agent 内存空间物理隔离，即使对话被提取也无法还原密钥
- 最小权限原则：broker 仅暴露
call动作，无查询、导出、枚举接口 - 平台原生集成：复用 macOS Keychain / Linux libsecret，无额外密码学实现风险
- 审计友好：所有调用通过 broker 日志集中记录，便于合规追踪
潜在缺点与局限性
- 环境硬限制：明确不支持 Docker、WSL、无图形界面的 Linux 服务器——本质是依赖宿主机的密钥管理服务（D-Bus Secret Service 或 macOS Keychain），容器化/远程场景无法挂载这些基础设施
- 服务扩展门槛：新增服务商需手动编辑
ALLOWED_URLS并重启 broker，无法动态配置 - 单点故障：broker 进程崩溃或权限配置错误将导致全部 API 调用失效
- 调试困难：密钥不可见使故障排查依赖 broker 日志，缺乏透明度
适合人群
- 在本地 macOS/Linux 工作站使用 AI 编码助手的开发者
- 对密钥泄露风险敏感、但拒绝频繁手动复制密钥的极客用户
- 需要符合 SOC2/ISO27001 最小权限审计要求的团队
常规风险
| 风险类型 | 说明 |
|---------|------|
| 运行环境限制 | 云服务器、CI/CD、容器化部署均不可行，适用场景大幅收窄 |
| broker 本身被攻破 | 若攻击者控制 broker 进程，可劫持全部 API 调用流量（但仍无法导出密钥） |
| 白名单绕过 | `ALLOWED_URLS` 配置不当可能允许向恶意域名外带数据 |
| 用户教育成本 | 新手易混淆"broker 调用"与"直接 curl"模式，可能误将密钥粘贴进聊天 |
> ⚠️ 重要：当前报告为占位生成，未执行实际安全扫描。生产使用前建议审计 keys-broker.sh 源码及依赖（curl/jq）的完整性。