Never put an LLM API key in browser code – anyone can read it in the network tab or bundled JS. Run a small backend (serverless function or lightweight server) that holds the key, validates and rate-limits requests from the game, then forwards them to the LLM provider and returns only the response.
At a glance
| Fact | Value | Source |
|---|---|---|
| Never ship provider API keys in client JS | server-side only | github.com |
| Cloud auth alternative to long-lived keys | workload identity, short-lived tokens | github.com |
| In-browser LLM inference avoids a backend entirely | WebGPU required | llm.mlc.ai |
Put your LLM API key on a server, never in the game’s client code. A browser game’s JS, network requests and even bundled assets are fully visible to players, so any key embedded there can be extracted and abused. The standard pattern: the game client sends a request to your own backend endpoint (a serverless function or a small Node/Express server), that backend holds the API key as a server-side environment variable, calls the LLM provider, and returns only the text/response the game needs – never the raw provider response with any embedded credentials.
If you are developing your browser game with an AI coding agent, Playgama MCP connects environments like Cursor, Codex, Claude Code, or VS Code to your developer cabinet to upload builds and publish sandboxes.
What the proxy needs to do
- Validate the request (origin check, expected shape, session or anonymous token) before calling the LLM.
- Rate-limit per player/session to cap cost from abuse or runaway loops.
- Some providers support short-lived workload-identity tokens instead of long-lived keys for server environments – check if your provider offers this over a static API key, per openai-node.
- Log enough to debug without logging full prompts/keys.
An alternative that removes the backend entirely: run the model in the browser itself with WebLLM or similar WebGPU-based runtimes – no server, no key, but the player’s device does the inference and needs a WebGPU-capable browser.
Sources
- openai-node – official JS/TS library
- WebLLM Javascript SDK docs
- BrowserAI – run local LLMs in the browser
- WebGPU API – MDN
- Playgama Bridge SDK getting started
Related questions
Can I call OpenAI’s API directly from browser JS with dangerouslyAllowBrowser?
Technically yes, but that exposes your key to every player. It’s meant for prototyping, not shipping – route production traffic through your own server-side proxy instead.
Does running an in-browser model like WebLLM remove the need for a backend?
Yes for inference itself – no key or server call needed – but it requires a WebGPU-capable browser and the player’s device does the compute, which varies by hardware.
How do I stop players from spamming my proxy and running up API costs?
Add rate-limiting and session validation in the backend before it calls the LLM provider; never rely on client-side checks since those can be bypassed.
Last updated: 30 September 2026