缺失的那个字段：live_connect_constraints

根据 Ferdiansyah 的分析报告，官方参考实现在铸造令牌时遗漏了 live_connect_constraints 字段 。这个字段本该包含一个 bidi_generate_content_setup 对象，用于将令牌绑定到特定的模型、系统指令和工具集。

如果 live_connect_constraints 为空或缺席，则不会强制任何约束。攻击者一旦获取了该临时令牌，就可以发送一个由客户端控制的设置帧（setup frame），自行指定任意模型、系统提示和工具。由于服务器没有令牌中绑定的值可供校验，便会直接接受攻击者的配置。

重要提示： 所提供的信息来源中未包含 Google 关于 live_connect_constraints 的官方文档、CVE 编号或 Google 安全公告。此指控来自 Ferdiansyah 的 Medium 文章，应视为尚未经官方证实但逻辑上合理的说法 。

影响：攻击者利用不受约束的令牌能做什么

如果该漏洞确实存在，对于任何在浏览器环境中使用 Gemini Live API 的应用而言，后果都相当严重：

• 通过工具实现沙箱代码执行 —— Gemini Live API 示例中包含客户端添加自定义工具的支持 。攻击者若注入恶意工具定义，理论上可在应用的沙箱中执行代码。
• 计算资源滥用 —— 被劫持的会话将消耗受害应用的配额和费用。由于临时令牌设计为一次性连接，攻击者还可以反复通过后端的铸造端点请求新令牌，从而推高成本 。
• 提示词篡改 —— 控制设置帧就意味着控制了系统指令。攻击者可借此窃取敏感信息、生成有害内容或冒充可信代理 。
• 重复会话滥用 —— Live API 会话的连接时长限制约为 10 分钟 。攻击者需要重新连接，但利用同样的无约束令牌流程，可以反复劫持会话。

Google AI 论坛上的开发者曾报告过临时令牌忽略系统指令、在受约束端点中无法正常工作等问题，这表明整个生态系统仍在成熟过程中 。

一个字段即可修复

Ferdiansyah 提出的修复方案非常直接：在铸造令牌时填入 live_connect_constraints.bidi_generate_content_setup 字段，并指定三个值：

1. model —— 要使用的具体 Gemini 模型（例如 models/gemini-2.5-flash-native-audio-latest）。
2. system_instruction —— 预期的系统提示，按包含 text 的 parts 结构来组织。
3. tools —— 设为空数组 [] 或仅包含显式允许的工具，防止客户端注入。

以下是来自 Ferdiansyah 文章的示意性 Python 代码 ：

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "你是一名客户支持助理..."}]
            },
            "tools": []
        }
    }
})

注意： 由于 live_connect_constraints 并非来自 Google 官方 API 参考文档，此示例仅基于 Ferdiansyah 的描述。在实际投入生产环境前，应先在真实 API 上进行测试 。

尚未确认的事项

根据现有来源，以下关键点仍无法得到验证：

• Google 官方文档中未确认 live_connect_constraints 的存在或其模式。
• 尚无 CVE 编号或安全公告发布。
• 来源中不包含对该漏洞的独立复现。
• 所引用的官方参考资料中，也未说明 BidiGenerateContentConstrained 端点在收到无约束令牌时的具体行为 。

开发者现在应做什么

在 Google 发布官方公告之前，最安全的做法是视该漏洞为合理风险，并主动应用修复：

1. 审计你的临时令牌铸造代码 —— 检查后端是否正确填充了 live_connect_constraints 或其等效字段。
2. 绝不要暴露原始 API 密钥 —— 对于面向浏览器的连接，始终使用临时令牌 。
3. 设置严格的令牌过期时间 —— Google 建议将 newSessionExpireTime 设为约 60 秒，以缩小令牌被窃取的时间窗口 。
4. 在服务端校验设置帧 —— 即使客户端发送了自己的配置，后端也应强制使用预期的模型、提示和工具。
5. 监控异常行为 —— 留意异常的会话模式，特别是同一令牌的重复连接或意外的工具调用。

Gemini Live API 是构建实时语音和视频体验的强大工具。令牌铸造过程中一个字段的缺失不应损害这一能力——但开发者必须确保其实现是完整的。

本文基于 27 个来源进行了事实核查，包括 Google 官方文档、社区论坛讨论以及原始研究员的分析报告。研究员的指控在发稿时尚未能从官方来源得到独立验证。

缺失的那个字段：live_connect_constraints

根据 Ferdiansyah 的分析报告，官方参考实现在铸造令牌时遗漏了 live_connect_constraints 字段 。这个字段本该包含一个 bidi_generate_content_setup 对象，用于将令牌绑定到特定的模型、系统指令和工具集。

如果 live_connect_constraints 为空或缺席，则不会强制任何约束。攻击者一旦获取了该临时令牌，就可以发送一个由客户端控制的设置帧（setup frame），自行指定任意模型、系统提示和工具。由于服务器没有令牌中绑定的值可供校验，便会直接接受攻击者的配置。

重要提示： 所提供的信息来源中未包含 Google 关于 live_connect_constraints 的官方文档、CVE 编号或 Google 安全公告。此指控来自 Ferdiansyah 的 Medium 文章，应视为尚未经官方证实但逻辑上合理的说法 。

影响：攻击者利用不受约束的令牌能做什么

如果该漏洞确实存在，对于任何在浏览器环境中使用 Gemini Live API 的应用而言，后果都相当严重：

• 通过工具实现沙箱代码执行 —— Gemini Live API 示例中包含客户端添加自定义工具的支持 。攻击者若注入恶意工具定义，理论上可在应用的沙箱中执行代码。
• 计算资源滥用 —— 被劫持的会话将消耗受害应用的配额和费用。由于临时令牌设计为一次性连接，攻击者还可以反复通过后端的铸造端点请求新令牌，从而推高成本 。
• 提示词篡改 —— 控制设置帧就意味着控制了系统指令。攻击者可借此窃取敏感信息、生成有害内容或冒充可信代理 。
• 重复会话滥用 —— Live API 会话的连接时长限制约为 10 分钟 。攻击者需要重新连接，但利用同样的无约束令牌流程，可以反复劫持会话。

Google AI 论坛上的开发者曾报告过临时令牌忽略系统指令、在受约束端点中无法正常工作等问题，这表明整个生态系统仍在成熟过程中 。

一个字段即可修复

Ferdiansyah 提出的修复方案非常直接：在铸造令牌时填入 live_connect_constraints.bidi_generate_content_setup 字段，并指定三个值：

1. model —— 要使用的具体 Gemini 模型（例如 models/gemini-2.5-flash-native-audio-latest）。
2. system_instruction —— 预期的系统提示，按包含 text 的 parts 结构来组织。
3. tools —— 设为空数组 [] 或仅包含显式允许的工具，防止客户端注入。

以下是来自 Ferdiansyah 文章的示意性 Python 代码 ：

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "你是一名客户支持助理..."}]
            },
            "tools": []
        }
    }
})

注意： 由于 live_connect_constraints 并非来自 Google 官方 API 参考文档，此示例仅基于 Ferdiansyah 的描述。在实际投入生产环境前，应先在真实 API 上进行测试 。

尚未确认的事项

根据现有来源，以下关键点仍无法得到验证：

• Google 官方文档中未确认 live_connect_constraints 的存在或其模式。
• 尚无 CVE 编号或安全公告发布。
• 来源中不包含对该漏洞的独立复现。
• 所引用的官方参考资料中，也未说明 BidiGenerateContentConstrained 端点在收到无约束令牌时的具体行为 。

开发者现在应做什么

在 Google 发布官方公告之前，最安全的做法是视该漏洞为合理风险，并主动应用修复：

1. 审计你的临时令牌铸造代码 —— 检查后端是否正确填充了 live_connect_constraints 或其等效字段。
2. 绝不要暴露原始 API 密钥 —— 对于面向浏览器的连接，始终使用临时令牌 。
3. 设置严格的令牌过期时间 —— Google 建议将 newSessionExpireTime 设为约 60 秒，以缩小令牌被窃取的时间窗口 。
4. 在服务端校验设置帧 —— 即使客户端发送了自己的配置，后端也应强制使用预期的模型、提示和工具。
5. 监控异常行为 —— 留意异常的会话模式，特别是同一令牌的重复连接或意外的工具调用。

Gemini Live API 是构建实时语音和视频体验的强大工具。令牌铸造过程中一个字段的缺失不应损害这一能力——但开发者必须确保其实现是完整的。

本文基于 27 个来源进行了事实核查，包括 Google 官方文档、社区论坛讨论以及原始研究员的分析报告。研究员的指控在发稿时尚未能从官方来源得到独立验证。