Gemini Live Voice Session Flaw Lets Attackers Inject Tools Through Unconstrained Ephemeral Tokens

A Gemini Live API security misconfiguration can let attackers take control of browser-based AI voice sessions when developers issue ephemeral tokens without server-side constraints. The issue allows a client to override the intended system prompt, select tools, and enable code execution in a Gemini Live session, according to Alvin Ferdiansyah’s research.

The flaw does not appear to be a traditional API key leak. It affects implementations that correctly avoid exposing the API key to the browser, but fail to lock what the browser can do after receiving a short-lived token. Google’s ephemeral tokens documentation says these tokens are designed for direct client-to-server Live API connections and can be restricted to reduce production risk.

The main risk is that authentication and authorization can split apart. A token can prove that a client may connect, while still leaving the model, system instruction, and tools under client control if the backend omits the right constraints.

How the Gemini Live token flaw works

Gemini Live API supports real-time voice, audio, video, and text interactions over WebSockets. In a browser-facing design, the backend keeps the real API key private and gives the client an ephemeral token. The browser then connects directly to Gemini Live through the constrained WebSocket flow.

Every Live API session starts with a setup message. Google’s Live API reference says the initial configuration can include the model, generation parameters, system instructions, and tools. Those values matter because they decide what the assistant is, what it can do, and which capabilities it may call during the session.

Ferdiansyah found that when an ephemeral token lacks live_connect_constraints or an equivalent locked setup, the client can send its own setup frame. In the tested case, the server accepted a setup frame that replaced the system instruction and enabled codeExecution.

Component	Expected role	Risk when unconstrained
Ephemeral token	Allows a short-lived browser connection	May authenticate access without limiting session behavior
Setup frame	Defines model, prompt, tools, and session settings	Can become attacker-controlled
System instruction	Sets assistant behavior and guardrails	Can be replaced by an injected instruction
Tools	Enable features such as code execution or search	Can be added by the client if not locked

Why the constrained endpoint was not enough

The name of the constrained WebSocket endpoint can give developers the impression that the session is automatically locked down. The research shows that the endpoint only enforces what the token tells it to enforce.

Google’s Live API reference explains that if the token has no bidiGenerateContentSetup and the field mask is empty, the effective setup is taken from the Live API connection. In practical terms, this means the browser’s setup message can become the source of truth.

That design creates a dangerous default for browser-based voice assistants. The backend may issue a token with a short lifetime and one allowed use, yet still leave the most sensitive parts of the session open to the client.

Official example code also omitted the constraints

The issue gained extra attention because Google’s own sample repository for Gemini Live examples includes an ephemeral token WebSocket demo. The Gemini Live API examples repository presents a browser and Python backend pattern for using short-lived tokens with Gemini Live.

In the checked server.py file, the token creation call includes uses, expire_time, new_session_expire_time, and http_options, but does not include live_connect_constraints. The raw server.py example therefore shows a token provisioning pattern that does not lock the setup fields.

This does not mean every Gemini Live integration is exposed. It means products that copied the pattern without adding constraints may allow the browser to define the session instead of the backend.

• The backend still protects the long-lived API key.
• The browser still receives only a short-lived token.
• The token may still have a short session window.
• The session can still remain unsafe if tools and instructions are not locked server-side.

What the researcher demonstrated

Ferdiansyah tested a consumer-facing AI voice assistant that allowed self-registration with an email address and one-time password. After registration, the application returned a WebSocket URL, token, model name, and timing values, but no visible locked setup fields.

The researcher then connected directly to the WebSocket endpoint with the issued token and sent a custom setup frame. That frame replaced the intended system instruction and enabled Python code execution. The service responded with setupComplete, which indicated that the injected configuration had been accepted.

To confirm that the output came from real execution rather than a model-generated guess, the test used nonce-bound SHA-256 values and runtime data from the sandbox. The proof showed code running inside a Google-managed gVisor environment, as described in Ferdiansyah’s write-up.

Impact is serious, but not a full cloud compromise

The reported code execution happened inside a sandbox, not on the application’s own servers. Google’s code execution documentation says Gemini API can run Python code through a code execution tool so models can use results while answering.

That distinction matters. The flaw can allow unauthorized tool use, prompt override, and billed compute abuse. It does not automatically give attackers access to the developer’s database, private backend, or cloud infrastructure.

The sandbox still limits the blast radius. However, in a production app, uncontrolled tool access can increase costs, expose unintended behavior, weaken product safety controls, and undermine trust in browser-based AI assistants.

Risk area	Likely effect
System prompt override	The assistant may ignore the intended persona, policy, or product limits
Tool injection	A client may enable tools the backend never intended to expose
Code execution	Python can run in the managed sandbox if the tool is enabled
Cost abuse	Attackers may repeatedly mint tokens and consume billed resources
Product abuse	A public voice assistant can become a general-purpose tool runner

How developers should fix the issue

The direct fix is to bind the ephemeral token to the intended Live API setup at token creation time. Google’s ephemeral tokens guide now shows examples using liveConnectConstraints to lock configuration values such as the model and response settings.

For sensitive browser-facing assistants, developers should lock the model, system instruction, generation settings, and tools on the backend. If no tools are required, the tools list should stay empty. If tools are required, each one should be explicitly allowed and tested.

• Add live_connect_constraints when minting Gemini Live ephemeral tokens.
• Lock the model and system instruction on the server.
• Set tools to an empty list unless the product truly needs tools.
• Do not let the browser decide which built-in tools are available.
• Rate-limit token creation endpoints by account, IP, and risk signal.
• Log setup values and reject unexpected client configuration changes.

Why this matters for AI voice apps

Real-time AI voice apps often need low latency, so developers prefer direct browser connections instead of routing every audio frame through their backend. Ephemeral tokens are useful for that model because they avoid placing the main API key in client-side code.

The security boundary still sits in the backend. If the backend only issues a token and does not define what that token can do, the browser may become the policy engine. That is a weak model for any public-facing AI assistant.

Teams that built from the official examples repository should review their implementation now. The key question is whether their token mint response locks the setup or leaves the client free to define it.

What to audit right now

Security teams should start by inspecting the backend endpoint that creates Gemini Live tokens. The presence of an ephemeral token alone is not enough. The token should include constraints that match the product’s intended behavior.

Developers should also review whether their implementation resembles the unconstrained server.py token creation pattern. If it does, the backend should be updated before the feature remains exposed to untrusted users.

For applications that enable code execution, teams should treat tool configuration as a privileged server-side decision. The Gemini code execution tool can be useful for legitimate workflows, but it should not become available because a browser client added it to a setup frame.

FAQ