核心用法
Keychains 是一种凭证代理服务，解决 AI 代理调用 API 时的凭证安全问题。核心模式是占位符替换：用户在请求中使用 {{OAUTH2_ACCESS_TOKEN}} 等模板变量，Keychains 服务端注入真实凭证，代理全程不接触敏感信息。
使用流程（4 步）：
1. 用 npx -y keychains@latest curl 替代 curl，在请求头中放置占位符
2. 首次请求返回审批链接
3. 用户通过 FaceID/Passkey 完成授权
4. 后续请求自动生效，凭证永久托管于服务端
多 SDK 支持：
- CLI：零安装，即插即用的
curl替代方案 - Machine SDK (
@keychains/machine-sdk)：持久化凭证到~/.keychains/ - Client SDK (
@keychains/client-sdk)：无状态令牌模式，适合云函数/沙箱 - Python SDK：
requests风格的keychains.get()封装
---
显著优点
| 维度 | 优势 |
|------|------|
| **安全性** | 零凭证暴露，从根本上阻断提示注入窃取 |
| **用户体验** | 生物识别授权（FaceID/Passkey），无需复制粘贴密钥 |
| **兼容性** | 5500+ 预集成服务商，覆盖 GitHub、Slack、Stripe、Gmail 等主流平台 |
| **开发效率** | 模板变量即插即用，无需改造现有 API 调用逻辑 |
| **权限管控** | 用户保留完全控制权，可随时在 dashboard 撤销授权 |
| **审计能力** | 完整审批链路记录，满足合规要求 |
---
潜在缺点与局限性
- 首次冷启动成本：新服务首次调用需用户交互授权，无法完全无人值守
- 网络依赖：所有请求需经过 Keychains 服务器，存在单点故障和延迟引入风险
- 供应商锁定：凭证托管于第三方服务，迁移成本较高
- 调试复杂度：服务端注入使本地抓包调试困难，错误信息可能抽象化
- 定价不透明：文档未提及商业模式，企业级 SLA 未知
---
适合人群
- AI 产品团队：构建 Agent 产品，需向终端用户提供安全、可控的第三方集成
- 企业 IT 部门：实施零信任架构，限制 AI 系统对敏感凭证的访问
- SaaS 平台：为客户的 AI 工作流提供托管集成能力
- 安全敏感场景：金融、医疗、法律等合规要求严格的行业
不适合： 纯内部工具、完全公开的 API、对端到端延迟极度敏感的场景
---
常规风险
| 风险类型 | 说明 | 缓解建议 |
|----------|------|----------|
| 供应商可用性 | Keychains 服务中断将导致所有依赖集成失效 | 关键路径保留备用凭证机制 |
| 凭证泄露（服务端） | 尽管代理不可见，Keychains 本身成为高价值攻击目标 | 监控 dashboard 异常活动，启用 MFA |
| 授权范围滥用 | 用户可能过度授权，AI 获得不必要权限 | 引导用户最小权限原则，定期审计 |
| 模板变量误用 | 混淆 `OAUTH2_` 与自定义 API key 前缀导致注入失败 | 严格遵循文档前缀规范 |
---
技术评估
该方案在凭证安全架构上具有创新性，将 OAuth 的授权分离模式（用户授权 → 服务端代持 → 代理无感使用）产品化。相比传统方案（环境变量、密钥管理服务），其差异化在于代理层完全无状态，即使 AI 环境被完全攻破，攻击者也只能获得无意义的占位符。
然而，信任模型从"信任 AI 环境"转移至"信任 Keychains 服务端"，需评估其安全审计、SOC2 认证、数据驻留等合规资质。建议生产环境分阶段灰度，并保留应急凭证通道。