AI 产品 API 密钥管理最佳实践（2026 年检查清单）

AI 产品 API 密钥管理最佳实践（2026 年检查清单）

API 密钥管理最佳实践可以归纳为五点：将密钥保留在服务端，不写入代码；为每个环境和工作负载分配权限范围严格受限的独立密钥；使用密钥管理服务存储密钥；按经过验证的计划轮换和撤销密钥；监控使用情况，但绝不记录密钥本身。 对 AI 产品而言，风险比大多数 API 更高，因为模型密钥一旦泄露，可能在数小时内产生高额账单，还可能授予对提示词、文件和工具调用的访问权限。

本指南将这些原则整理为平台、安全和 AI 产品团队可以落实的检查清单，涵盖密钥生命周期、密钥资产清单模板、无停机轮换、CI/CD 防护措施、事件处置手册，以及生成、存储和验证密钥的代码。参考资料包括 OWASP 敏感凭据管理速查表、Google Cloud API 密钥最佳实践和 GitHub 敏感凭据扫描文档，均于 2026 年 10 月 27 日核查。

API 密钥管理最佳实践：快速检查清单

#	最佳实践	防范的问题
1	绝不在源代码、笔记本或客户端应用中硬编码密钥	密钥通过 Git 历史记录、浏览器代码包和移动应用二进制文件泄露
2	将提供商密钥保留在服务端；向客户端发放短期会话令牌	用户或恶意软件从设备中提取密钥
3	为每个环境、应用和团队成员分配独立密钥	一处泄露后，撤销密钥导致所有系统中断
4	应用尽可能严格的限制：API、模型、IP、配额	被盗密钥可被用于任意用途
5	将密钥存储在密钥管理服务中，而非工单、聊天或 Wiki 中	密钥副本无法查找或轮换
6	维护密钥资产清单，记录负责人、工作负载和轮换日期	轮换导致未知的使用方中断
7	按计划轮换，设置新旧密钥并行有效期，然后撤销旧密钥	密钥在员工离职、供应商合作结束后仍长期有效
8	删除不再使用的密钥	被遗忘的密钥仍保留有效权限
9	启用敏感凭据扫描和推送保护	密钥进入公开或共享代码仓库
10	绝不记录密钥或授权标头；仅记录密钥 ID 或版本	敏感凭据通过日志、调用链和错误报告泄露
11	设置支出限额，并对异常使用情况告警	密钥被盗或调用失控产生意外账单
12	制定以撤销密钥为优先的事件处置手册	团队争论泄露密钥是否被使用，导致暴露时间延长

本指南其余部分将说明如何在 AI 工作负载中落实各项实践。在这类场景中，密钥不仅用于身份验证，还会授权提示词、文档和模型输出的数据流转路径。

API 密钥的生命周期

OWASP 建议管理敏感凭据的完整生命周期，包括创建、轮换、撤销和过期，并在每个环节进行审计（OWASP 敏感凭据管理速查表）。AI API 密钥的生命周期如下：

阶段	负责人操作	应保留的证据
申请	说明工作负载、环境及所需模型的必要性	工单或资产清单条目
创建	在提供商控制台或通过 API 生成密钥，并使用有明确含义的名称	密钥 ID、创建时间、创建人
限制	限定模型、API、网络和预算	限制配置
存储	直接存入密钥管理服务；绝不粘贴到其他地方	密钥存储路径和访问策略
分发	在运行时注入唯一需要它的工作负载	部署绑定关系
监控	跟踪请求、词元、支出和最近使用时间	使用情况仪表板和告警
轮换	创建替代密钥、切换并验证	轮换记录
撤销	在提供商处使密钥失效，确认返回 401	撤销时间戳和测试结果

AI 密钥可能跨越的五道边界

首先梳理敏感凭据及其授权访问的数据可能流经哪些位置。大多数问题源于团队保护了提供商密钥，却忽略了以下某道相邻边界。

边界	典型问题	必要控制措施
客户端到应用	提供商密钥被嵌入浏览器代码包、移动应用二进制文件、桌面应用或扩展程序	将提供商密钥保留在服务端；向客户端发放短期用户或会话凭据
应用到网关	所有服务共用一个不受限制的密钥	使用工作负载身份、限定权限范围的网关令牌、配额和明确的路由策略
网关到提供商	一个凭据可以访问所有模型、项目或环境	在支持的情况下，按提供商、环境、工作负载和风险等级分配独立密钥
请求到日志	授权标头、提示词、文件或输出出现在调用链记录中	将敏感凭据字段列入禁止记录清单，尽量减少载荷日志，对标识符进行令牌化处理，并测试脱敏效果
人员操作	密钥被粘贴到工单、聊天、操作手册或支持工具中	采用受控访问流程、带审计的读取机制、应急访问流程和自动过期机制

梳理这些边界后，设计时要回答的问题就从“密钥存在哪里？”变成了“哪个身份可以携带哪些数据、通过哪条路由发起什么请求，事后又会留下什么证据？”

采用服务端密钥保管模式

不应将长期有效的提供商凭据分发给浏览器、移动端、桌面端或扩展程序客户端。凡是交付到终端用户设备上的内容，都应视为可被该用户或以同等权限运行的恶意软件提取。

更安全的模式是：

1. 客户端使用用户会话、设备凭据或短期应用令牌向后端进行身份验证。
2. 后端对请求使用的功能进行授权，并应用用户级或租户级限制。
3. 网关或服务端集成选择已获批准的提供商和模型。
4. 在运行时获取提供商密钥，或通过部署平台将其提供给受信任的工作负载。
5. 提供商响应通过同一道策略边界返回。

客户端无需持有提供商的敏感凭据，只需获得在你定义的限制内调用产品的权限。

对于编程智能体和本地开发工具，也应遵循同样的原则，并明确设计例外机制。开发者可能需要本地凭据，但它应当是可撤销、可追踪使用归属且权限范围有限的产品或网关凭据，而非复制到全公司各处点文件中的、组织范围共享的提供商密钥。

轮换任何密钥之前，先建立密钥资产清单

团队不了解哪些工作负载使用了某个密钥时，轮换项目就容易失败。在更改凭据前，应建立机器可读的资产清单并指定负责人。

至少记录以下信息：

字段	示例	重要性
密钥 ID	prod-support-chat-anthropic-01	提供稳定的内部引用，且不包含密钥值
提供商及项目	提供商账号 + 项目标识符	明确外部影响范围
环境	开发、预发布、生产	防止测试系统获得生产权限
工作负载	support-chat-api	支持追踪使用归属和定向撤销
负责人	团队和值班安排	明确事件处置责任
存储位置	密钥管理服务中的路径或部署绑定	标明权威数据源的位置
允许的模型/路由	已获批准的模型系列或网关策略	限制意外使用
支出和请求限制	工作负载预算、RPM、TPM 或并发控制	限制滥用和失控的自动化调用
创建及最近轮换时间	时间戳	便于识别陈旧凭据
轮换方式	双密钥、版本别名或维护窗口	避免临时拼凑变更方案
撤销依赖	必须先更新的服务	保障可用性
数据分类	公开、内部、机密、受监管	将密钥策略与提示词治理衔接起来

不要在资产清单中存放密钥值。只存储元数据和对受管密钥的引用。

按环境、工作负载和风险隔离身份

最常见的反模式是所有服务共用一个生产密钥。这种做法起初很方便，但只要一个代码仓库、测试运行器、承包商笔记本电脑或客服记录泄露了密钥，团队就无法在不影响其他产品的情况下将其撤销。

优先为以下场景分配独立身份：

• 生产、预发布、开发和本地测试。
• 面向客户的流量、内部工具、批处理作业和评估流水线。
• 可调用工具或处理机密数据的高风险工作流。
• 合同边界要求隔离的不同业务部门或租户。
• 紧急或应急访问，此类访问在正常运行期间应保持禁用或受到严格控制。

只要提供商支持限制，就应启用。限制项可能包括允许的 API、模型、来源网络、项目、来源页面、应用或配额。例如，Google Cloud 的 API 密钥指南建议限制和隔离密钥、删除不再需要的密钥、避免将密钥提交到代码仓库，并监控其使用情况。

如果提供商的控制粒度不够细，就在自己的网关中实施这些控制。集中式网关可以验证发起调用的工作负载，将其映射到获批路由，应用预算和速率限制，并将供应商凭据保留在统一且经过审查的服务端边界内。有关路由和故障切换设计，请参阅更全面的 AI API 网关架构指南。

将提示词和日志治理纳入密钥管理

API 密钥会授权一条数据流转路径。只保护密钥而不控制这条路径，仍然无法解决 AI 特有的主要风险。

在路由请求前，先对载荷进行分类，并遵循最小必要原则：

• 移除凭据、令牌、Cookie、私钥和连接字符串。
• 排除模型不需要的字段。
• 如果任务无需直接身份标识符也能完成，就对其进行令牌化或假名化处理。
• 拒绝不支持处理的受监管数据或受合同限制的数据。
• 将系统指令与不可信的用户内容或检索内容分开。
• 在智能体调用外部系统之前验证工具参数。

日志需要明确的结构规范。不要指望开发者总能记住不能记录请求对象。应明确允许哪些字段，然后丢弃或转换其他所有内容。

一条有用的生产事件记录可以包含：

{
  "request_id": "req_01J...",
  "tenant_id_hash": "tnt_7f2...",
  "workload": "support-chat-api",
  "route_policy": "support-low-risk-v3",
  "provider": "selected-provider",
  "model": "selected-model",
  "input_tokens": 842,
  "output_tokens": 211,
  "latency_ms": 1370,
  "status": 200,
  "key_version": "v12",
  "redaction_policy": "customer-support-v4"
}

默认情况下，它不应包含授权标头、原始提供商密钥、完整提示词、上传的文档、未经脱敏的工具参数或完整模型输出。如果严格受控的评估或事件调查确实需要捕获载荷，应限定捕获时段、实施访问控制，并使这些数据与常规遥测数据有明显区分。

OWASP 日志记录速查表为从应用日志中排除访问令牌、密码、加密密钥和其他敏感数据提供了实用基线。

设计无停机 API 密钥轮换

只有能够安全执行，轮换才能成为有效的控制措施。会引发服务中断的操作手册，往往会被搁置到紧急情况发生时才使用。

如果提供商支持新旧凭据并行有效，可采用双密钥或带版本的密钥轮换流程：

1. 创建新的提供商密钥。 应用与旧密钥相同或更严格的限制。
2. 将其存储为新的密钥版本。 如果平台支持版本或别名，不要直接覆盖旧值。
3. 部署支持读取新版本的组件。 更新网关或工作负载，使其解析当前别名或版本。
4. 切换流量并观察。 确认使用新密钥版本的请求成功，并检查模型、支出、速率限制和错误率是否符合预期。
5. 清理旧密钥使用方。 检查部署清单、作业、工作进程和灾难恢复环境。
6. 撤销旧密钥。 不要只是停止使用；还要在提供商处使其失效。
7. 验证请求被拒绝。 通过受控测试确认旧凭据已无法使用。
8. 记录证据。 保存时间戳、负责人、受影响的工作负载、验证结果和下次审查日期。

对于支持选择密钥版本的系统，应用应引用稳定的别名，而非硬编码某个密钥版本：

type ProviderCredential = {
  value: string;
  version: string;
};

async function loadProviderCredential(): Promise<ProviderCredential> {
  const activeVersion = await secretStore.resolveAlias("ai/provider/active");
  const value = await secretStore.readVersion("ai/provider", activeVersion);

  return { value, version: activeVersion };
}

不要打印 value、序列化返回的对象，或将其附加到错误中。日志只记录不含敏感信息的版本标识符。

OWASP 敏感凭据管理速查表建议规划敏感凭据的完整生命周期，包括创建、轮换、撤销、过期、审计、备份和应急访问，并强调在可行时实现自动轮换。

防止敏感凭据进入代码仓库和 CI 日志

一旦凭据被复制进源代码、测试夹具、构建产物或 CI 日志记录中，密钥管理服务也无法提供保护。

在三个阶段实施控制：

提交前

• 提供包含占位符的 .env.example 文件，绝不放入有效凭据。
• 不将本地敏感凭据文件纳入版本控制。
• 在 pre-commit 钩子中运行快速敏感凭据扫描器，检测常见提供商格式和高熵值。
• 让开发者了解：在后续提交中删除敏感凭据，并不会将其从历史记录中移除。

推送和拉取请求阶段

• 在支持的情况下，启用代码仓库敏感凭据扫描和推送保护。
• 为公共扫描器无法识别的内部网关令牌添加自定义匹配模式。
• 要求记录绕过保护的原因，并将绕过行为提交安全审查。
• 扫描生成文件、笔记本、测试快照和基础设施计划，而不只是应用源代码。

GitHub 文档说明，推送保护会在推送过程中进行扫描，在检测到敏感凭据时阻止其进入代码仓库。被检测出来并不意味着可以继续保留该密钥：任何确认已提交的凭据都应视为已经暴露，并予以轮换。

CI/CD 期间

• 优先使用工作负载身份或短期联合身份验证，而非存储云凭据。
• 仅向需要敏感凭据的作业和步骤提供该凭据。
• 对已知敏感值进行遮蔽，但不要将遮蔽作为主要控制措施。
• 在获取敏感凭据的代码周围禁用 shell 跟踪。
• 防止来自分叉仓库的不可信代码访问部署凭据。
• 检查产物、缓存、崩溃转储和测试报告，排查意外记录的敏感信息。

监控使用情况，但不记录敏感凭据

良好的监控能够回答“谁使用了哪项权限？”，同时不记录授予该权限的凭据本身。

跟踪以下信息：

• 工作负载、环境、租户或项目，以及密钥版本。
• 提供商、模型、路由策略和回退路径。
• 请求数、词元用量、支出、延迟和错误类别。
• 在有帮助的情况下，记录来源网络或部署身份。
• 对密钥管理服务的访问，包括被拒绝的读取操作。
• 密钥的创建、限制变更、轮换、撤销和删除。
• 来自非预期环境、地理位置、模型或时间段的突然使用。

围绕行为设置告警，而不只是关注总支出。被盗的低预算密钥仍可能泄露提示词，或被用于探查内部工作流。反过来，合法的批处理作业也可能在凭据未失陷的情况下造成支出激增。应将提供商使用情况与应用请求 ID、网关策略决策、部署事件及密钥管理服务审计日志关联起来。

有关与凭据控制配合使用的流量控制措施，请参阅 LLM 速率限制指南和 LLM API 回退路由实战手册。

追踪从暴露到撤销的事件处置时间

当密钥可能已暴露时，首要目标是控制影响，而非证明攻击者是否使用过它。

按以下顺序执行：

1. 将凭据标记为疑似泄露。 记录其可能暴露的时间和位置。
2. 通过正常的受控流程创建替代凭据。 不要为了加快处置而将新密钥粘贴到聊天中。
3. 将合法工作负载切换到替代凭据。 使用预先准备好的轮换流程。
4. 撤销疑似泄露的密钥。 如果立即撤销会造成不可接受的损害，应在完成切换的同时隔离路由并降低限额。
5. 搜索所有可能存有副本的位置。 检查源代码历史、CI 日志、产物、容器镜像层、客服系统、仪表板、笔记本、本地配置和备份。
6. 审查获授权的数据路径。 确定该密钥可以访问哪些提示词、输出、文件、工具或模型，而不只是检查其计费范围。
7. 关联分析活动记录。 对比提供商使用情况、网关日志、部署、敏感凭据读取和用户活动。
8. 通知相应负责人。 根据涉及的数据和合同，让安全、平台、法务、隐私和客户团队参与。
9. 消除根因。 补齐缺失的扫描器、限制、身份边界或日志过滤器。
10. 记录各阶段耗时。 记录检测、替换、流量切换、撤销和验证的耗时。

最有助于推动改进的指标通常是暴露到撤销的时间：组织获得可信的暴露证据后，疑似泄露的凭据还能继续使用多久。缩短这段时间，需要事先明确责任归属、建立资产清单、实现自动化并验证轮换流程，而不是编写更长的策略文档。

如果你向自己的客户发放 API 密钥

许多 AI 产品也会发放密钥，例如让客户调用你的智能体或嵌入你的功能。同样的最佳实践也适用于你作为密钥签发方的场景：

• 使用密码学安全的随机数生成器生成密钥，熵至少为 32 字节。
• 添加易识别的前缀（例如 Flatkey 密钥的 sk-fk-），便于敏感凭据扫描器和支持团队识别泄露的密钥。GitHub 合作伙伴计划会根据已知令牌格式，在密钥被推送到公共代码仓库时通知签发方（GitHub 敏感凭据扫描）。
• 完整密钥只展示一次，之后仅存储哈希值。这样即使数据库泄露，密钥仍然安全。
• 在仪表板中仅显示经过遮蔽的前缀，以及创建日期和最近使用时间。
• 让撤销立即生效，对已撤销的密钥返回 401。
• 允许客户限定密钥范围，包括指定模型、项目或支出限额。

Python：生成、哈希和验证密钥

import hashlib
import hmac
import secrets

PREFIX = "sk-acme-"

def new_api_key() -> tuple[str, str]:
    """Return (plaintext key shown to the user once, hash to store)."""
    key = PREFIX + secrets.token_urlsafe(32)  # 32 random bytes
    return key, hashlib.sha256(key.encode()).hexdigest()

def verify(presented: str, stored_hash: str) -> bool:
    candidate = hashlib.sha256(presented.encode()).hexdigest()
    return hmac.compare_digest(candidate, stored_hash)  # constant-time compare

key, digest = new_api_key()
print(key[:12] + "...")   # show the full key once in the UI, never log it
print(verify(key, digest))  # True

这里可以使用 SHA-256 这样的快速哈希算法，因为密钥足够长且随机，与人类设置的密码不同。存储哈希值、密钥 ID、所有者、权限范围和时间戳。

Node.js：从环境变量加载密钥，失败时拒绝运行

// Never fall back to a hardcoded default key.
const apiKey = process.env.FLATKEY_API_KEY;
if (!apiKey || !apiKey.startsWith("sk-fk-")) {
  throw new Error("FLATKEY_API_KEY is missing or malformed");
}

const res = await fetch("https://router.flatkey.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-haiku-5-5",
    messages: [{ role: "user", content: "ping" }],
    max_tokens: 5,
  }),
});
console.log(res.status); // log the status, never the header

验证已撤销的密钥确实失效

只有旧密钥无法使用，才能证明撤销成功。每次轮换或事件处置后，都应从受信任的机器上运行类似下面的检查：

# Expect 401 for the revoked key; do not echo the key itself
OLD_KEY="$(cat /run/secrets/old_flatkey_key)"
status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://router.flatkey.ai/v1/models \
  -H "Authorization: Bearer $OLD_KEY")
if [ "$status" = "401" ]; then echo "revoked OK"; else echo "STILL ACTIVE: $status"; fi

在轮换日志中记录结果和时间。Flatkey 文档说明，撤销会立即生效，任何使用已撤销密钥的请求都会收到 401 Unauthorized，没有宽限期（Flatkey API 密钥文档）。

Flatkey 如何支持这些最佳实践

Flatkey 提供一个兼容 OpenAI 的端点（https://router.flatkey.ai/v1），可访问多家模型提供商，从而减少分散在各项服务中的提供商密钥。根据 Flatkey API 密钥文档（于 2026 年 10 月 27 日核查）：

• 你可以创建多个密钥，为每个环境、应用或团队成员分配一个，并使用 prod-customer-chatbot 这样含义明确的名称。
• 完整的 sk-fk- 密钥只显示一次。之后，密钥页面会列出名称、创建日期、最近使用时间戳和经过遮蔽的前缀。
• 撤销立即生效，因此应先部署替代密钥，再撤销旧密钥。
• 所有密钥共享账号余额，默认可访问所有模型。使用控制台中的 Groups（分组），可将密钥限制为仅访问指定模型，或设置支出配额。

使用情况文档介绍了逐请求日志，其中包含模型、词元、费用和密钥信息，还提供每月支出上限和余额不足邮件告警，覆盖了实践 10 和 11。对于较大的组织，Flatkey 企业文档介绍了树状结构的子密钥，每个子密钥都有独立预算和模型允许列表。网关无法替代你自己的客户端身份验证、数据分类和日志规范，因此仍需落实本清单的其余部分。要开始集成，请参阅 Flatkey 集成入门指南。

多提供商 AI 产品参考架构

安全的多提供商架构可以分为五层：

1. 客户端身份层： 验证用户、设备、智能体或应用的身份，同时不暴露提供商凭据。
2. 应用授权层： 验证产品使用权益、租户边界、功能访问权限和预算。
3. 数据策略层： 对提示词、文件、检索上下文和工具参数进行分类和脱敏。
4. 网关与路由层： 选择获批模型、应用配额、记录不含敏感凭据的使用归属信息，并处理故障切换。
5. 提供商凭据层： 存储相互隔离的供应商凭据、轮换版本，并仅向受信任的路由工作负载提供凭据。

这种设计可以限制影响范围。客户端令牌失陷不会自动导致提供商密钥暴露。工作负载身份失陷不应使攻击者获得对所有提供商的访问权限。泄露的提供商凭据不应能授权访问所有环境。日志机制失效不应同时暴露敏感凭据和完整载荷。

生产环境检查清单

在上线前和每季度控制措施审查时使用本清单。

保管与身份

• [ ] 浏览器、移动端、桌面端或扩展程序代码中不包含任何长期有效的提供商密钥。
• [ ] 每个生产工作负载都有明确的负责人和凭据获取路径。
• [ ] 生产、预发布、开发、评估和本地访问已隔离。
• [ ] 在可行的情况下，已将人员共用的密钥替换为工作负载或网关身份。
• [ ] 提供商和网关限制已设置为实际可行的最小范围。

存储与分发

• [ ] 权威数据源是受管的敏感凭据存储服务或受控的部署绑定。
• [ ] 应用仅在运行时获取敏感凭据，且不打印或序列化这些凭据。
• [ ] CI 作业仅在必要步骤中获得所需的敏感凭据。
• [ ] 敏感凭据访问和管理变更均有审计记录。
• [ ] 应急访问有文档说明、限定有效时间，并经过测试。

数据与可观测性

• [ ] 日志、调用链、错误信息和客服导出内容中均不包含授权标头和密钥值。
• [ ] 提示词、输出、文件和工具参数的日志记录遵循允许列表规范。
• [ ] 在多提供商路由之前完成脱敏。
• [ ] 可以将使用情况归属到工作负载、环境、路由、提供商、模型和密钥版本。
• [ ] 告警覆盖异常路由和身份，以及支出情况。

轮换与响应

• [ ] 已有经过测试的双密钥或带版本密钥轮换手册。
• [ ] 旧密钥已在提供商处撤销，并验证无法使用。
• [ ] 敏感凭据扫描和推送保护覆盖代码仓库及生成产物。
• [ ] 疑似泄露会立即触发影响控制，无需等待滥用证据。
• [ ] 演练和事件处置后均衡量从暴露到撤销的时间。

常见问题

API 密钥管理有哪些最佳实践？

不要将密钥放入源代码和客户端应用；为每个环境和工作负载使用独立密钥；将每个密钥限制为只能使用所需的 API、模型和预算；使用密钥管理服务存储密钥；按经过测试的计划轮换；删除未使用的密钥；启用敏感凭据扫描；绝不记录密钥；一旦怀疑泄露，立即撤销。

应该将 API 密钥存储在环境变量中吗？

环境变量是向进程传递密钥的合理方式，但它并不是管理系统。密钥值应来自密钥管理服务或平台的敏感凭据注入机制，并配备访问控制、轮换和审计。绝不要提交 .env 文件。

API 密钥应该多久轮换一次？

根据风险和提供商的控制能力选择间隔；许多团队每 90 天轮换一次生产 AI 密钥，并在人员变动或疑似暴露后立即轮换。最重要的是演练过轮换流程、撤销旧密钥，并验证撤销结果。

浏览器或移动应用可以使用 API 密钥直接调用 AI 提供商吗？

应避免这样做。任何交付到设备上的内容都可能被提取。让客户端向你的后端进行身份验证，再由后端或网关使用服务端密钥调用模型，并应用用户级限制。

如果 API 密钥在 GitHub 上泄露，我应该怎么做？

将其视为已失陷。创建替代密钥，将工作负载迁移过去，撤销泄露的密钥，确认其返回 401，审查暴露期间的使用情况，并添加扫描或推送保护以防再次发生。删除提交并不能让密钥恢复安全。

一个网关密钥比多个提供商密钥更安全吗？

它减少了代码中的敏感凭据数量，但也集中了权限。为每个环境和工作负载使用独立的网关密钥，通过模型和支出限制限定其权限范围，并继续同样严格地保护网关背后的提供商密钥。

我应该如何存储发放给自己用户的 API 密钥？

仅存储每个密钥的哈希值，在创建时展示一次完整密钥，之后只显示经过遮蔽的前缀，并支持立即撤销。

参考资料与延伸阅读

• OWASP 敏感凭据管理速查表
• OWASP 日志记录速查表
• GitHub：关于敏感凭据扫描
• GitHub：关于推送保护
• Google Cloud：API 密钥管理最佳实践
• Flatkey：创建和管理 API 密钥

相关 Flatkey 指南：AI API 脱敏策略、AI API 网关架构和 LLM 速率限制详解。