秘密金库
AiHummer 将每个凭证 —— 频道令牌、SMTP/IMAP 密码、OAuth 令牌、每个租户的 LLM 密钥（BYOK） —— 存储在一个 加密秘密仓库该保险库使用信封加密，因此静态数据的值仅通过数据库是无法读取的，并且它被设计成使秘密 从未被放入模型上下文或日志中.
信封加密
保险库使用两级密钥层次结构：
- A 主密钥 (KEK) —— 提供为
AIHUMMER_MASTER_KEY，一个 base64 编码的 32字节值——用于包装和解包数据密钥。它从不离开主机，并且 从未写入到数据库。 - A 每租户数据加密密钥（DEK） 加密实际的秘密值 与 AES-256-GCM (认证加密)。每个租户都有自己的数据加密密钥 (DEK)， 因此，一个租户的钥匙无法解密另一个租户的秘密。
机密值以密文形式存储；数据加密密钥（DEK）被密钥加密密钥（KEK）包装存储。解密在需要机密时（例如，当连接器进行身份验证时）在内存中发生，随后明文会被丢弃。
AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value[!NOTE] 该保险库依赖于 PostgreSQL 的
pgcrypto扩展。确保它是 在您的数据库中可用——它是标准系统要求的一部分。
万能钥匙
主密钥是一个引导值：它在启动时从环境中读取，并且是 不 可以从管理员界面进行配置。安装程序（以及首次启动时的网关） 总是创建 AIHUMMER_MASTER_KEY ——这是必需的，因为静态数据加密、凭证库和每租户自带密钥（BYOK）都依赖它。因此，标准安装总是会有一个。
# /home/.aihummer/etc/gateway.env
# 32 random bytes, base64-encoded
AIHUMMER_MASTER_KEY=Base64Of32RandomBytes==你可以用以下方式生成一个：
openssl rand -base64 32[!WARNING] 要解密保管库中的所有内容，必须使用主密钥。像对待它一样 你秘密的根源和 单独备份它 来自数据库——如果 如果你丢失它，加密的数值将无法恢复。见 操作 用于备份指导。
如果主钥匙丢失
因为密钥始终已配置，标准安装总是有一个可用的保险库。这里的行为是在不寻常情况下的故障关闭保护。 AIHUMMER_MASTER_KEY 以某种方式未设置（例如，手动编辑的环境文件）：保险库以及依赖它的所有内容都 残疾 — 静态秘密存储、凭据保管库以及每租户的 BYOK 密钥都已关闭。这是有意的 — 产品不会悄无声息地回退到以明文存储秘密。
秘密永远不会传达到模型
这是保险库最重要的特性，它是结构性的，而不是政策提醒。
[!DANGER] 秘密是 从不 注入到系统提示中，对话 历史，或任何模型可见的文本，并且它们是 从不 写入日志。 需要凭证的工具在调用时从保险库中解析它，在内部 网关，并使用它来验证出站请求——模型仅 永远只看到工具调用的结果，而不是秘密。
因为交互性是由调用工具驱动的（参见 防护栏与提示注入防御），没有任何途径可以让提示要求模型“读出”存储的秘密：模型没有它的副本可供读取。
共享和每用户凭据
保险库区分 共享的 （工作区级）凭证和 个人的 （每用户）凭证。通过连接流程获得的每用户OAuth2令牌存储在保险库中，并由操作用户解析，在适当情况下可使用工作区回退。这使得同一个工具可以代表不同用户执行操作，并拥有各自的授权，而不会将一个用户的令牌暴露给另一个用户。
接下来去哪儿
- 基于角色的访问控制（RBAC）和范围 API 密钥 — 谁可以阅读或更改 由 Vault 支持的配置。
- 行级安全 —— 每个租户隔离在 支持保险库的数据库。
- 防护栏与提示注入防御 ——为什么 该模型永远不会被欺骗而泄露秘密。