浏览器实时转录很快，但把 API Key 放前端等于公开权限。本文给出三种保护方案，并按合规与工作流落地给出选型建议。
浏览器实时转录：API 密钥保护的三种做法
把语音转录直接做进浏览器，开发速度确实快：点一下按钮，麦克风音频就能通过 WebSocket 变成实时文字。但现实也很残酷——如果你把语音识别服务的 API Key 放在前端代码里，你不是“方便集成”，而是在“公开账号权限”。对小企业来说，这类事故往往不是技术问题，而是管理问题：谁来保管密钥？谁来审计用量？出事怎么追责？
在“人工智能在法律科技与合规”这条主线里，语音转录通常是 AI 语音助手与自动化工作流的入口：客服通话纪要、销售跟进记录、法务访谈笔录、合规热线录音……一旦把实时转录接入 CRM、工单系统、合同管理或知识库，密钥泄露就不再只是“多扣点费用”，而是可能引发数据滥用、越权访问、合规风险与客户信任危机。
这篇文章把 Deepgram 提到的三种前端实时转录密钥保护方式做一次“落地改写”，并补上小企业在安全分工、合规控制、以及自动化工作流集成时最容易漏掉的细节。你会看到：何时用临时 key、何时必须上代理、以及如何把它们变成可审计、可追责的工程实践。
先把底层风险说透：为什么浏览器里不能放 API Key
**答案很直接：浏览器是用户可控环境，任何发到前端的密钥都等于“已泄露”。**哪怕你把 key 写在混淆后的 JS 里、放在 localStorage、或塞进环境变量再打包，用户都能在 DevTools、网络请求、源码映射、甚至浏览器插件里把它扒出来。
对于语音转录这类服务，泄露的后果通常分三层：
- 费用与资源被滥用：攻击者可以用你的 key 持续发起转录会话，账单飙升，而且很难第一时间定位来源。
- 权限扩大化：如果你误把“控制台创建的通用 key”暴露出去，它往往带有更多 scope（例如管理项目、团队、密钥等）。这就不是“用量”问题，是“账号接管”的起点。
- 合规与证据链断裂（法律科技场景最要命）：当转录结果进入案件材料、合同谈判记录或合规留痕系统，你需要能回答：
- 这段转录是谁触发的？
- 用的是哪把 key？有效期多久？
- 是否只允许特定模型与参数？
- 事后能否导出审计日志？
一句话：密钥管理就是责任划分的技术载体。自动化工作流做得越深，密钥越应该“可控、可撤销、可审计”。
权限最小化：先学会用 Scope/Role 把钥匙切小
**第一步不是写代码，而是把权限切到最小。**在 Deepgram 这类平台里，一个项目可以有多把 key，每把 key 对应不同 scope。平台往往也提供 role（把一组常用 scope 打包）。
建议你在团队里形成两个等级的密钥：
- 管理密钥（只在后端/CI 使用）：具备
keys:write这类“创建/删除 key”的权限，用于发临时凭证、轮换密钥、应急封禁。它必须放在服务器环境变量或密钥管理服务里。 - 会话密钥（短期/低权限）：只给转录所需的最小 scope（例如
usage:write），并且最好有有效期。
这和合规体系里的职责分离很像：
- 业务系统“只负责使用”，
- 安全/平台侧“负责发放与回收”。
下面三种做法，都是围绕这个原则展开。
做法 1：按需创建 + 用完删除（最容易落地）
结论：如果你需要最快上线、又不想改动架构，按需创建临时 key 然后删除，是性价比最高的过渡方案。
流程很清晰：
- 浏览器点击“开始转录” → 请求你的后端
/key。 - 后端用管理密钥调用平台 API 创建一把“仅转录可用”的临时 key（scope 最小化）。
- 把这把临时 key 发回浏览器，浏览器用它直接连转录 WebSocket。
- 用户点击“结束” → 浏览器通知后端
/key/:id删除临时 key。
你得到的好处：
- 泄露窗口变短：即使被用户拿到 key，也只能用到你没删除之前。
- 权限可控：临时 key 只有转录所需的 scope。
- 容易做审计：每次创建 key 都能记录用户、时间、会话 ID、工单/客户编号。
你需要接受的代价：
- 前端仍会“短暂看到 key”。严格意义上，仍然可能被窃取。
- 依赖“用户正常结束”。如果用户直接关页、断网，删除动作可能没发生。
我建议你补两条工程化细节
- 后端兜底回收：给临时 key 加标签（比如
session:xxxxx），并设置定时任务扫描“超过 N 分钟未结束”的会话，批量删除。 - 按组织策略限流：对
/key接口做登录校验、IP 限制、频率限制（例如每用户每分钟最多 2 次），防止被刷。
做法 2：自动过期的临时 Key（更适合“用户可能不点结束”的产品）
**结论：如果你的转录是“随时开始、随时断开”的轻量功能，自动过期 key 比“用完删除”更靠谱。**因为它不依赖用户行为。
平台允许你在创建 key 时带上过期策略：
expiration_date：指定到期时间time_to_live_in_seconds：指定 TTL（例如 10 秒、60 秒）
关键点在于：很多实时转录服务只在“建立连接时”校验 key。也就是说，你可以把 TTL 设得很短（例如 10–60 秒），只要用户在 TTL 内完成连接建立，会话就能继续跑。
这对小企业尤其友好：
- 你不用担心“用户没点结束”导致 key 长期可用。
- 你可以把 TTL 作为风控参数：高风险租户更短、内部员工更长。
合规视角下的建议：把 TTL 写进制度
如果语音转录用于合规留痕或法律流程（例如客户投诉、合同谈判纪要），建议把策略明确成内部标准：
- 临时 key TTL：30 秒
- 单次会话最长：60 分钟（超时强制重连）
- 会话结束后 5 分钟内完成日志入库
这些数字不需要“完美”，但需要“可执行、可审计”。
做法 3：服务器代理转录（最推荐，也是最像“合规架构”的做法）
结论：只要你的语音转录进入了自动化工作流（CRM/工单/知识库/合同系统），就该用代理方案：浏览器永远不接触第三方 API Key。
架构是这样的：
- 浏览器只连你自己的 WebSocket（或 WebRTC 网关）。
- 你的服务器持有真正的转录服务 key，与第三方建立连接。
- 服务器把音频流转发给第三方，把转录结果再转发给浏览器。
这带来的变化非常实在：
- 密钥不出后端：前端抓包也拿不到。
- 可插入合规控制点：你可以在服务器上做脱敏、分级存储、DLP 检测、内容过滤、以及“只允许某些模型/地区节点”。
- 天然可审计：所有会话都经过你的服务端，你能记录谁、何时、对哪个客户、转录了多久、花了多少钱。
代理方案的“隐藏价值”：把转录变成工作流的可靠事件源
小企业做 AI 语音助手，最怕的是“Demo 很顺，落地一堆坑”。代理层让你把实时转录变成稳定的事件流：
- 识别到“客户要发合同” → 自动创建合同审查任务
- 识别到“退款/投诉关键词” → 自动打上合规标签并升级工单
- 识别到“报价与条款” → 自动生成谈判纪要并推送法务确认
这些自动化一旦发生，你就必须能解释系统如何做决策、如何追溯输入输出。代理层是最合适的“证据链入口”。
代理方案要注意的两点现实成本
- 延迟与扩展性：音频转发会增加一点延迟。通常可以接受，但要做压测与连接数规划。
- 安全边界变清晰：你需要维护 WebSocket 服务、鉴权、以及防止任意用户把你代理当“免费转录通道”。做法包括：JWT 会话令牌、一次性会话 ID、以及按租户计费/限额。
小企业落地清单：把“密钥保护”变成可操作的责任分工
答案先给出来：密钥保护做得好不好，不看你用了哪种方案，而看你是否能在 30 分钟内完成“封禁、定位、止损、复盘”。
你可以用下面这张清单做一次内部自查（也适用于法律科技与合规团队的供应商评估）：
- 权限最小化：前端使用的任何凭证都只有转录所需 scope。
- 密钥轮换机制：管理 key 有固定轮换周期（例如 60–90 天）或具备应急轮换流程。
- 会话级审计日志：记录用户 ID、时间戳、会话 ID、客户/工单/案件编号、用量与错误。
- 额度与风控：按用户/租户限流；设置日预算或用量告警。
- 数据合规处理：明确转录文本是否落库、保留多久、谁可访问；必要时做脱敏（手机号、身份证、银行卡）。
- 事故预案：一键禁用某类 key；一键终止正在进行的会话；有对外沟通模板。
我见过不少团队在“集成速度”上赢得很快，但在“密钥与日志”上欠账太久。等到要上自动化工作流、要做合规审计、要对接法律科技系统时，就得返工。
常见问题（团队里通常会吵起来的那几个）
Q1：我们只是做个浏览器端小工具，真的需要代理吗？
如果只是内部使用、且不接入业务数据与自动化流程，可以先用“自动过期临时 key”。但只要涉及客户数据、合同谈判、投诉处理，代理方案基本是必选项。
Q2：临时 key TTL 设多短合适？
以“足够建立连接”为目标，通常 10–60 秒是合理区间。网络不稳定或移动端场景可适当加长，并配合限流和预算告警。
Q3：为什么密钥管理在合规里这么关键？
因为它决定了你能不能证明：系统只在授权范围内处理数据，并且每次处理都有记录可追溯。合规审计最怕“说不清”。
你的下一步：选一条路线，然后把它产品化
如果你正在做 AI 语音助手与自动化工作流，我的建议很明确：
- 先用最小权限 + 临时 key（带 TTL）快速上线，把密钥从“长期暴露”变成“短期可控”。
- 一旦转录结果进入 CRM/工单/合同/知识库，就尽快切到代理架构，把审计、风控、合规控制点放在服务器侧。
当语音转录从“功能点”变成“业务入口”，密钥保护就从工程细节变成治理能力。你更愿意在上线前多花两天把门锁装好，还是在账单爆炸、客户质疑、合规抽查时补课？