通过 API 网关实现浏览器安全的实时 AI：临时令牌、租户策略和语音会话控制

浏览器和移动应用程序不应接收长期存在的提供商 API 密钥。然而，对于实时语音 AI，通过网关发送每个音频数据包可能会增加延迟、运营成本和故障模式。更好的模式是将网关保留在控制平面中：验证用户身份、执行租户策略、预留预算、创建狭窄的短期实时凭证，并让对延迟敏感的媒体在适当的情况下使用提供商的实时传输。

本文介绍了一种团队通过AI API 网关构建语音代理、呼叫助理、移动辅导员、支持副驾驶或应用内语音接口的实现模式。目标是在不失去租户治理的情况下实现浏览器安全。

问题：直接实时连接绕过您的控件

普通的服务器端代理很有吸引力，因为它集中了密钥和可观察性。对于标准文本请求，这通常是正确的模型。实时音频是不同的。语音会话可能涉及连续麦克风输入、双向音频输出、中断、工具调用和严格的延迟预期。通过网关代理所有媒体可以将网关转变为带宽密集型媒体中继，而不是策略和计费服务。

浏览器到提供商的直接连接可以解决延迟问题，但会产生不同的问题：

• 浏览器无法安全地保存标准提供商 API 密钥。
• 如果应用直接连接，则可能会跳过租户预算检查。
• 模型、区域、语音、模式和工具限制成为客户端承诺。
• 使用归因变得不完整或延迟。
• 安全团队在会话开始前失去了一个可审核的决策点。

实际设计并不是“代理每个字节”。这是“每次交易都进行经纪”。

事实、建议和预测

事实：实时 AI 提供商越来越多地支持低延迟传输，例如 WebRTC、WebSocket 和 SIP。 OpenAI 实时 API 的公共文档描述了低延迟实时接口，包括 WebRTC。 Azure OpenAI 实时 WebRTC 指南描述了浏览器应用程序使用后端令牌服务在启动 WebRTC 连接之前检索临时令牌，并警告不要在客户端应用程序中使用标准 API 密钥。 OpenAI Agents SDK 实时指南还推荐了一种流程，其中后端创建短暂的临时客户端令牌，浏览器使用它来建立 WebRTC 连接。

建议：将网关视为会话权限。它应该决定是否存在实时会话、使用哪种模型、在哪个区域、针对哪个租户、在哪个预算下以及使用哪些工具。客户端应该只收到启动该批准会话所需的最低限度的短期凭据。

预测：实时提供商 API 将在一段时间内保持不平衡。令牌生命周期、会话配置字段、服务器端断开连接控制、使用事件和区域支持将会有所不同。网关应该明确地对提供者的能力进行建模，而不是假装所有实时 API 都是完美可移植的。

参考架构：网关作为实时控制平面

浏览器安全的实时流程有五个部分：

1. 客户端应用：请求语音会话的浏览器或移动应用。
2. 应用程序后端：对最终用户进行身份验证并调用网关，或者嵌入网关令牌铸造逻辑（如果网关是后端堆栈的一部分）。
3. AI API 网关：执行租户策略、解析模型配置文件、预留预算、记录会话并创建临时提供商客户端密钥。
4. 实时提供商：终止 WebRTC 或其他实时传输。
5. 账本和分析：一旦提供商事件、持续时间数据或最终使用报告可用，即可结算使用情况。

网关不需要中继每个音频帧来保持权威。它必须拥有会话创建决策和协调路径。

推荐的请求流程

1. 用户在客户端应用中打开语音功能。
2. 客户端调用您的后端：POST /voice/sessions。
3. 后端验证用户会话，并向网关转发包含租户 ID、用户 ID、预期功能、设备元数据和来源的 Mint 请求。
4. 网关评估政策和预算。
5. 网关在联系提供商之前会创建本地 realtime_session 记录。
6. 网关使用其受保护的运行时凭据调用提供程序，并创建一个范围狭窄的临时实时会话。
7. 网关仅将临时客户端密钥和批准的会话元数据返回给浏览器。
8. 浏览器直接与提供商建立 WebRTC 连接。
9. 网关接收提供商使用事件、回调、轮询结果或保守的基于持续时间的估计。
10. 账本结算预留预算并写入审计事件。

预铸政策检查

最重要的执行点是在临时代币被铸造之前。一旦浏览器拥有短期凭据，会话中执行可能会受到限制，除非提供程序支持会话更新、断开连接、观察者或回调控制。

网关至少应该检查：

• 租户状态：活跃、暂停、试用、预付费、已开具发票或隔离。
• 用户权利：该用户是否可以使用实时语音，而不仅仅是文字聊天。
• 允许的模型配置文件：批准的实时模型或部署，而不是任意客户提供的模型 ID。
• 区域和保留政策：所选提供商区域和功能集是否与租户的数据规则匹配。
• 最长会话持续时间：例如，根据计划为 5、15 或 30 分钟。
• 允许的模式：音频输入、音频输出、文本、图像或工具调用。
• 语音和指令模板：由政策固定或限制。
• 可用预算：预付余额、预留的每月津贴或每项功能的支出上限。
• 并发：租户级和用户级主动语音会话。
• 滥用控制：用户风险标记、来源声誉、异常呼叫速度或租户终止开关。

安全的默认设置是拒绝不明确的请求。如果客户端请求的模型、工具、语音或区域不在租户的实时策略中，网关应返回明确的策略错误，而不是默默地扩大访问范围。

会话记录设计

在创建提供商凭据之前创建网关端会话记录。即使提供程序创建成功但浏览器从未连接，这也会为您提供审核锚点。

<前><代码>{ "session_id": "rt_01j...", “tenant_id”：“tenant_123”， "end_user_id": "user_hash_456", “提供商”：“provider_a”， “provider_session_id”：空， "model_profile": "语音支持标准", "upstream_model_or_deployment": "实时模型-x", “地区”：“伊斯特斯”， "session_config_hash": "sha256:...", “允许的模式”：[“音频输入”，“音频输出”]， “allowed_tools”：[“lookup_order_status”]， "tool_approval_policy": "approve_side_effects", "budget_reservation_id": "resv_789", “最大持续时间秒”：900， “发布时间”：“2026-08-21T10:00:00Z”， “expires_at”：“2026-08-21T10:01:00Z”， "client_origin": "https://app.example.com", "device_id_hash": "sha256:...", “状态”：“铸造” }

默认情况下不存储原始麦克风音频或完整提示。存储足以用于审计、支持和计费的配置哈希、ID、策略决策和最少的元数据。如果需要记录，请使其明确、同意并由租户策略驱动。

临时代币铸造端点

面向网关的端点可能如下所示：

POST /v1/realtime/sessions
授权：持有者
内容类型：application/json
{
  “tenant_id”：“tenant_123”，
  "end_user_id": "user_hash_456",
  “功能”：“support_voice_agent”，
  “来源”：“https://app.example.com”，
  "device_nonce": "8f3b...",
  "requested_profile": "语音支持标准"
}

响应不应暴露您的上游运行时密钥：

<前><代码>{ "session_id": "rt_01j...", “提供商”：“provider_a”， “运输”：“webrtc”， "client_secret": "ephemeral_secret_here", “expires_at”：“2026-08-21T10:01:00Z”， “已批准”：{ "model_profile": "语音支持标准", “最大持续时间秒”：900， “模式”：[“音频输入”，“音频输出”]， “工具”：[“lookup_order_status”] } }

将发行绑定到源、经过身份验证的用户会话、租户和随机数。提供商可能无法原生支持所有这些绑定，因此请在网关上强制执行您可以执行的操作：限制铸造尝试的速率、拒绝意外来源、记录设备元数据并保持较短的令牌生命周期。

会话模板：默认缩小

实时会话模板应该比一般聊天完成请求更具限制性。语音会话是交互式的，难以实时检查，并且运行时间可能比预期长。

推荐的模板字段包括：

• 固定模型或部署：由网关端模型配置文件选择。
• 说明：服务器控制的提示模板，其中包含租户批准的变量。
• 声音：从白名单中选择。
• 模式：禁用文本、图像或工具模式，除非产品需要它们。
• 输入音频设置：转动检测、转录行为或静音处理（如果支持）。
• 输出约束：支持的最大响应长度或响应行为。
• 工具白名单：仅限该功能所需的工具。
• 会话生命周期：较短的凭证到期时间加上最长的通话持续时间。

严格的模板会降低灵活性，但它们会使成本、合规性和支持变得更加容易。如果产品团队需要动态语音或指令，请公开受控的配置文件变体，而不是将任意客户端配置传递给提供商。

实时语音的预算控制

在最终提供商使用量到来之前，实时使用量可能更难定价。一个会话可能持续五秒或二十分钟。它可能包括音频输入、音频输出、转录、工具调用和文本标记。因此，网关应该结合预留、上限和协调。

铸造前

• 根据最长持续时间、模型、方式和租户计划估算最坏情况或保守的会话成本。
• 在发布客户端密钥之前预留预算。
• 如果租户余额不足或已达到每日语音限制，则拒绝新会话。

会议期间

• 跟踪活跃会话和预期消耗率。
• 应用租户和用户并发上限。
• 使用提供商支持的终止或会话更新功能（如果有）。
• 针对异常会话持续时间、重复重新连接或异常语音使用情况触发警报。

会议结束后

• 提取提供商使用事件或最终使用报告（如果有）。
• 将预留预算结算为实际成本。
• 如果确切的使用情况出现延迟或不完整，请保守保留直至协调。
• 将使用情况归因于租户、用户、功能、模型配置文件和会话 ID。

这比响应时的同步文本计费不太准确，但它在操作上比无保留地直接颁发凭据更安全。

实时会话内的工具调用

实时语音代理在可以调用工具时通常会变得更加有用：搜索帐户、预约、更新票证或触发工作流程。将工具执行与音频传输分开处理。

浏览器的媒体连接不应暗示允许执行副作用。网关或后端应强制执行：

• 工具注册表：每个工具都有所有者、架构、范围和风险级别。
• 允许列表：会话模板准确列出了可用的工具。
• 审批门：副作用操作需要用户确认、人工批准或策略批准。
• 单独的凭据：工具凭据绝不会嵌入到浏览器会话中。
• 联合审计跟踪：每个工具调用都会引用实时会话 ID。

例如，支持语音代理可以自动调用lookup_order_status，但refund_ payment可能需要显式确认和后端批准事件。实时提供商可以编排对话，但您的网关应控制权限边界。

无需代理每个字节的可见性

直接 WebRTC 媒体流可减少网关延迟和带宽负载，但可见性变得更加依赖于提供商事件和您自己的会话元数据。围绕多个证据源设计分析：

• 来自网关的会话创建记录。
• 客户端生命周期事件，例如连接、断开连接、尝试重新连接、麦克风被拒绝或呼叫结束。
• 提供商会话 ID、使用事件或最终使用记录。
• 提供程序使用延迟时基于持续时间的估计。
• 按会话 ID 连接的工具调用日志。
• 预算预留和结算记录。

不要等到供应商遥测完美后才启动控件。从保守的预订和明确的归因开始，然后随着提供商使用情况报告的成熟提高结算准确性。

安全清单

• 切勿将标准提供商 API 密钥发送到浏览器或移动客户端。
• 使用短暂的客户端密钥进行实时会话启动。
• 在铸造令牌之前对最终用户进行身份验证。
• 尽可能将铸造决策与租户、用户、来源、随机数和设备元数据绑定。
• 将提供程序运行时凭据保存在后端保管库或网关秘密存储中。
• 在提供商铸造之前记录会话审核行。
• 使用租户批准的会话模板，而不是任意客户端配置。
• 应用并发数、每日使用量和最长持续时间限制。
• 使用工具许可名单和审批门来消除副作用。
• 默认情况下最大限度地减少原始提示和音频保留。
• 维护令牌生命周期、区域、工具、使用事件和终止控制的提供商能力矩阵。

提供商能力矩阵

由于实时 API 有所不同，因此请围绕功能而不是假设来建模网关适配器。一个简单的矩阵可以驱动路由和策略决策：

<前><代码>{ “provider_a”：{ “运输”：[“webrtc”，“websocket”]， “ephemeral_client_tokens”：true， “token_ttl_秒”：60， “server_side_disconnect”：true， “会话更新”：正确， "usage_events": "final_and_incremental", “地区”：[“美国”，“欧盟”]， “tool_approval_supported”：true }, “provider_b”：{ “运输”：[“websocket”]， “ephemeral_client_tokens”：true， “token_ttl_秒”：120， “server_side_disconnect”：假， “会话更新”：假， "usage_events": "final_only", “地区”：[“我们”]， “tool_approval_supported”：假 } }

如果租户需要欧盟驻留和服务器端终止，则网关应仅路由到满足这两者的提供商和部署。如果没有提供者满足该策略，则关闭失败。

迁移路径

您不需要在第一天就构建每个控件。实际的部署是：

1. 仅创建代理会话：保持媒体直接，但要求后端或网关创建所有实时会话。
2. 添加政策模板：用批准的配置文件替换客户提供的模型和说明字段。
3. 添加预算预留：在令牌发行之前预留保守的会话成本。
4. 添加生命周期分析：收集会话开始、连接、断开连接、持续时间、提供商会话 ID 和结算状态。
5. 添加工具治理：实时工具调用需要许可名单和批准。
6. 添加提供商能力路由：按区域、模式、事件支持和终止控制选择提供商。
7. 添加可选的观察者或记录工作流程：仅在合规、同意且租户批准的情况下。

可行的结论

对于实时语音 AI，AI API 网关不应自动成为媒体中继。更安全、更低延迟的架构是让网关负责控制平面：对用户进行身份验证、执行租户策略、保留预算、创建审核记录、创建范围狭窄的临时凭证以及在会话后协调使用情况。

核心实现规则很简单：浏览器可能会收到短期会话机密，而不是长期提供者密钥。其他一切都遵循该边界：严格的模板、起源感知铸币、并发会话上限、工具批准、使用结算和提供商能力矩阵。这为产品团队提供了实时语音体验，而无需放弃 API 密钥管理、AI API 成本控制、团队 API 治理或 AI 使用情况分析。

相关阅读

• 运行时的提供商凭证库键
• 预算预留和结算账本