（2613期）Keys – 密钥零暴露的安全 API 调用代理

密钥零暴露的安全 API 调用代理 通过独立代理隔离API密钥，实现零暴露调用，阻断密钥窃取攻击链 使用说明 核心用法 Keys 采用"代理隔离"架构解决 AI 助手场景下的密钥安全管理难题。用户通过 keys-broker call 命令发起预配置服务的 API 请求，密钥全程由独立的 keys-broker 进程保管，永不进入 agent 上下文或对话历史。 调用流程： 用户安装 keys-broker.sh 至本地系统（需 macOS Keychain 或 Linux Secret Service） 密钥存入系统级密钥管理器，agent 无读取权限 通过 JSON-RPC 指令向 broker 发起代理请求 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）的完整性。 原始说明 Secure API key management with broker. Keys never exposed to agent context.