【免费下载链接】litellm-agent-control-plane1 place to call all your agents - OpenCode, Hermes, Claude Managed Agents, Cursor Agents API, DeepAgents.项目地址https://gitcode.com/gh_mirrors/li/litellm-agent-control-plane点击查看免费下载LiteLLM Agent Control Plane一个地方调用所有 AgentOpenCode、Hermes、Claude Managed Agents、Cursor、DeepAgents内置了一个凭证保险库Vault你的模型 API 密钥存入保险库时先被 XChaCha20-Poly1305 算法加密数据库里只存密文每次创建 Agent 会话时网关才临时解密并注入到运行环境——密钥全程不落明文文件、不暴露给调用方。本文带你彻底看懂这套「加密存储 按请求注入」的完整链路。为什么需要凭证保险库想象一下你搭建了统一的 Agent 网关背后要接 Anthropic、OpenAI、Elastic 等多家模型服务。API 密钥放在哪里写在 YAML 配置文件里 → 容易随代码仓库一起泄露每个 Agent 配置里各写一份 → 改一次密钥要改 N 处明文存数据库 → 数据库一拖库密钥全曝光LiteLLM Agent Control Plane 的凭证保险库解决了这三个痛点痛点保险库的做法密钥易泄露入库前强制加密数据库里只有密文密钥散落在各处统一命名存储Agent 只引用密钥名明文存库不安全按请求解密用完即弃不落盘更关键的是「密钥分离」设计用来访问网关的 master key 和调用上游模型用的 provider key 是两套完全独立的密钥。团队成员用自己的虚拟 key 访问网关永远看不到任何模型凭证详见 docs/learn/auth.mdx。加密存储密钥入库前的三道锁加密逻辑集中在 src/proxy/credential_crypto.rs 这个文件里流程非常清晰第 1 步找到加密密钥Signing Key按优先级取两个来源之一src/proxy/credential_crypto.rs#L12-L26环境变量LITELLM_SALT_KEY推荐独立于网关认证密钥配置里的general_settings.master_key示例见 config.yaml.example两者都没配会直接报错LITELLM_SALT_KEY or general_settings.master_key is required。第 2 步加密算法用的是XChaCha20-Poly1305crypto_secretbox库一个既保密又防篡改的认证加密算法加密密钥由 signing key 先经SHA-256摘要派生每次加密都随机生成一个 24 字节 nonce拼在密文前保证同一密钥值两次加密结果完全不同最后整体做Base64 URL-safe编码得到一串像dF3xK9...的密文第 3 步落库密文写入 PostgreSQL 的LiteLLM_CredentialsTable表建表见 src/db/managed_agents/migrations/0002_litellm_credentials_table.sql读写逻辑见 src/db/vault_keys.rs。你直接查数据库看到的只是这样的密文credential_name | scope | credential_values anthropic_key | personal | dF3xK9mQ2...一长串密文personal 还是 global两种作用域作用域可见范围保存权限典型场景personal仅属主用户任意网关 key我个人的模型密钥global所有用户必须 master key团队共享的公共密钥解析时personal 优先于 globalsrc/db/vault_keys.rs#L143-L152如果你的个人密钥和全局密钥同名会用你个人的那份实现「个人覆盖全局」。对应 API 端点定义在 src/http/vault.rsGET /v1/vault/{user}/keys— 列出密钥只显示密钥名不返回值PUT /v1/vault/{user}/keys— 保存需指定personal或global作用域DELETE /v1/vault/{user}/keys/{key}— 删除个人密钥UI 端在Vault页面操作src/ui/src/app/vault/page.tsx有个细节体现了防泄露设计保存之后值永远不会再被显示出来只能编辑或删除。按请求注入密钥何时才被解密这是保险库最优雅的部分——解密只发生在一瞬间。当你在 UI 里创建 Agent 时可以在配置中勾选需要哪些 vault 密钥src/ui/src/app/agents/new/page.tsx。这些密钥名会存进 Agent 记录的vault_keys字段建表见 0001_lite_harness_tables.sqlAgent 里存的只是名字不是值。真正注入发生在会话启动的那一刻src/http/sessions/runtime.rs#L175-L186会话创建时src/http/sessions/runtime_vault.rs 里的resolve_agent_vault_keys开始工作按「个人密钥 → 回退 local 用户 → 回退全局密钥」的顺序逐个查出密文用 signing key 解密成明文明文直接写进本次会话的运行环境变量environment随会话传给运行时创建会话 → 查密文 → 解密 → 写入环境变量 → 交给运行时以 Elastic 运行时为例会话环境里会出现ELASTIC_API_KEY、ELASTIC_AGENT_ID这样的变量下图是实时 SDK 测试中注入环境变量后的完整会话事件流注入完成后明文只存在于内存中的会话环境里不会写回数据库、不会出现在 API 响应里、也不会被任何人再次查询到。对 LLM 代理转发请求也有一套类似机制src/http/credential_overrides.rs 在处理请求时按 provider 从凭证库加载密钥直接覆写到路由配置上调用方全程无感。安全实践建议看完实现原理几条落地建议密钥分离认证网关用LITELLM_MASTER_KEY加密凭证用独立的LITELLM_SALT_KEY两者用途不同、泄露影响面不同轮换无忧密钥值换一次所有引用该名称的 Agent 自动生效不用逐个改配置最小暴露能给团队的密钥就给personal作用域global留给真正需要共享的公共密钥保存 global 密钥必须持有 master key定期清理Vault 页面随时可以删除不再使用的密钥密文随即从数据库消失常见问题Q直接连数据库能看到我的模型密钥吗不能。数据库里存的是 XChaCha20-Poly1305 密文没有 signing key 无法还原。即使密文被人拿走只要LITELLM_SALT_KEY没泄露就解不开。Q保存的密钥还能查看吗不能。出于安全考虑值只在保存时提交一次之后任何 API包括 UI 的 Vault 页面都只返回密钥名和作用域。QAgent 配置里存的是密钥值还是密钥名只存密钥名vault_keys数组。这意味着 Agent 定义可以安全共享、导出而密钥本身留在保险库里。参考文件加密算法实现src/proxy/credential_crypto.rs保险库存储层src/db/vault_keys.rsVault REST APIsrc/http/vault.rs会话启动时的密钥注入src/http/sessions/runtime_vault.rs请求级凭证覆写src/http/credential_overrides.rs官方认证文档docs/learn/auth.mdx从「入库即加密」到「按请求才解密」LiteLLM Agent Control Plane 的凭证保险库用一套简洁的机制把模型密钥的生命周期管得明明白白——这也正是网关类产品处理敏感凭证应有的样子。赞分享【免费下载链接】litellm-agent-control-plane1 place to call all your agents - OpenCode, Hermes, Claude Managed Agents, Cursor Agents API, DeepAgents.项目地址https://gitcode.com/gh_mirrors/li/litellm-agent-control-plane点击查看免费下载相关推荐Data Formulator 凭证保险箱Credential Vault深度解析加密存储、安全模型与部署实践Data Formulator 凭证保险箱Credential Vault深度解析加密存储、安全模型与部署实践 适用版本Data Formulator数据可视化人工智能AI 应用数据分析前端后端AI AgentFirecrawl密钥管理安全凭证存储Firecrawl密钥管理安全凭证存储 引言为什么密钥管理至关重要 在AI驱动的Web数据提取时代API密钥API Key如同数字世界的通行证。Fir网页爬虫后端AI 应用TruffleHog工具中S3密钥检测机制的技术解析TruffleHog工具中S3密钥检测机制的技术解析 在安全扫描工具TruffleHog的使用过程中开发者们可能会遇到一个看似异常的现象当扫描包含S3密钥对应用安全安全与开源治理漏洞扫描创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考